Subversion ha --record-only per unioni, come faccio a fare lo stesso in Git?

Question

Ho un repository in cui "master" sta andando in una certa direzione, e un secondo ramo "foo" sarà divergente per un paio di commit, quindi tracciare tutte le successive modifiche a "master". Questo è tutto per scelta, naturalmente.

In Subversion è possibile eseguire un'unione solo -regec per contrassegnare le cose come "l'unione è avvenuta" anche se non sono state apportate modifiche effettive. cioè questo modifica i numeri di tracciamento unione nelle proprietà allegate alle directory nel ramo di destinazione.

ho avuto un gioco con ..

git merge --no-commit maestro

.. come qualcosa che possa essere in grado di sperimentare con prima di fare l'impegno, ma sta facendo un casino del ramo di destinazione per parte della modifica in questione (rinomina seguita da eliminazione).

Ci deve essere un modo più semplice ..?

• Paul

Answer 1

E 'questo quello che stai cercando?

git merge --strategy=ours master 

nostra

Questo risolve qualsiasi numero di teste, ma l'albero risultante della fusione è sempre quella della testa ramo corrente, ignorando in modo efficace tutte le modifiche da tutte le altre branche. È pensato per essere utilizzato per sostituire la vecchia cronologia di sviluppo dei rami laterali.

Questo sembra essere quello che stai chiedendo - crea un merge commit che in realtà non introduce alcuna modifica.

Ma vuoi davvero farlo? C'è qualche ragione per cui non puoi semplicemente far divergere i rami (senza che si verifichi una fusione) e poi unirli più tardi?

Answer 2

Paul, git gestisce rinominare seguito da elimina con (relativamente a svn) facilità. Traccia il contenuto non il nome del file. In svn questo sarebbe doloroso, quali sono i tuoi problemi con git mentre lo fai?

Answer 3

jefromi l'ha inchiodato. Ecco la cosa reale: http://github.com/jbehave/jbehave-core/blob/master/examples/trader/src/main/java/org/jbehave/examples/trader/TraderStory.java (gioca con gli switch switch e guarda la riga 65).

Non si trattava tanto di "buttare via la storia", ma di più sull'uso di Git per gestire i cambiamenti divergenti da un'unica base. Per convincere la gente ad adottare JBehave (IMO), dobbiamo rendere gli esempi davvero facili da seguire. Prima di questo esempio di 'Trader' c'erano JBehave vanilla + una variante di Guice + una variante di SpringFramework + una variante di PicoContainer tutti nella stessa directory di origine. Ora, quattro rami possono illustrare le rappresentazioni più canoniche dell'esempio 'Trader'.