Esiste una versione "loro" di "git merge -s our"?

Quando unisco il ramo argomento "B" in "A" usando git merge, ottengo alcuni conflitti. So che tutti i conflitti possono essere risolti usando la versione in "B".

Ne sono consapevole git merge -s ours. Ma quello che voglio è qualcosa di simile git merge -s theirs.

Perché non esiste? Come posso ottenere lo stesso risultato dopo l'unione in conflitto con i gitcomandi esistenti ? ( git checkoutogni file non unito da B)

AGGIORNAMENTO: La "soluzione" di scartare qualsiasi cosa dal ramo A (il punto di unione della fusione alla versione B dell'albero) non è ciò che sto cercando.

Aggiungi l' -Xopzione a theirs. Per esempio:

git checkout branchA
git merge -X theirs branchB

Tutto si fonderà nel modo desiderato.

L'unica cosa che ho visto causa problemi è se i file venivano eliminati da branchB. Si presentano come conflitti se qualcosa di diverso da Git ha fatto la rimozione.

La correzione è semplice. Basta eseguire git rmcon il nome di tutti i file che sono stati eliminati:

git rm {DELETED-FILE-NAME}

Successivamente, -X theirsdovrebbe funzionare come previsto.

Naturalmente, la rimozione effettiva con il git rmcomando impedirà in primo luogo che si verifichi il conflitto.

Nota : esiste anche un'opzione di forma più lunga.

Per usarlo, sostituire:

-X theirs

con:

--strategy-option=theirs

Una soluzione possibile e testata per la fusione della filiale B nella nostra filiale controllata A:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

Per automatizzarlo puoi avvolgerlo in uno script usando branchA e branchB come argomenti.

Questa soluzione conserva il primo e il secondo genitore del commit di unione, proprio come ci si aspetterebbe git merge -s theirs branchB.

Le versioni precedenti di git ti consentivano di utilizzare la strategia di unione "loro":

git pull --strategy=theirs remote_branch

Ma questo è stato rimosso, come spiegato in questo messaggio da Junio ​​Hamano (il manutentore di Git). Come notato nel link, invece faresti questo:

git fetch origin
git reset --hard origin

Attenzione, tuttavia, che questo è diverso da una fusione reale. La tua soluzione è probabilmente l'opzione che stai davvero cercando.

Non è del tutto chiaro quale sia il risultato desiderato, quindi c'è qualche confusione sul modo "corretto" di farlo nelle risposte e nei loro commenti. Provo a dare una panoramica e vedere le tre opzioni seguenti:

Prova a unire e usa B per i conflitti

Questa non è la "loro versione per git merge -s ours" ma la "loro versione per git merge -X ours" (che è l'abbreviazione di git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

Questo è ciò che fa ad esempio la risposta di Alan W. Smith .

Usa solo contenuti da B.

Ciò crea un commit di unione per entrambi i rami ma ignora tutte le modifiche branchAe ne impedisce solo il contenuto branchB.

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

Nota che l'unione commette il primo genitore ora è quello di branchBe solo il secondo è di branchA. Questo è ciò che fa ad esempio la risposta di Gandalf458 .

Usa il contenuto solo da B e mantieni l'ordine genitore corretto

Questa è la vera "loro versione per git merge -s ours". Ha lo stesso contenuto dell'opzione precedente (ovvero solo quella di branchB), ma l'ordine dei genitori è corretto, ovvero il primo genitore viene branchAe il secondo da branchB.

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

Questa è la risposta di Paul Pladijs (senza richiedere una branca temporanea).

Da allora ho usato la risposta di Paul Pladijs. Ho scoperto che puoi fare un'unione "normale", si verificano conflitti, quindi lo fai

git checkout --theirs <file>

per risolvere il conflitto usando la revisione dell'altro ramo. Se lo fai per ogni file, hai lo stesso comportamento che ti aspetteresti

git merge <branch> -s theirs

Comunque, lo sforzo è più di quanto sarebbe con la strategia di unione! (Questo è stato testato con la versione 1.8.0 di git)

Ho risolto il mio problema usando

git checkout -m old
git checkout -b new B
git merge -s ours old

Quando unisco il ramo argomento "B" in "A" usando git merge, ottengo alcuni conflitti. So che tutti i conflitti possono essere risolti usando la versione in "B".

Sono a conoscenza di git merge -s our. Ma quello che voglio è qualcosa come git merge> -s loro.

Suppongo che tu abbia creato un ramo fuori dal master e ora desideri ricollegarti al master, sovrascrivendo tutte le vecchie cose nel master. Questo è esattamente quello che volevo fare quando mi sono imbattuto in questo post.

Fai esattamente quello che vuoi fare, tranne unire prima un ramo nell'altro. L'ho appena fatto e ha funzionato alla grande.

git checkout Branch
git merge master -s ours

Quindi, controlla il master e unisci il tuo ramo (andrà liscio ora):

git checkout master
git merge Branch

Se sei nel ramo A fai:

git merge -s recursive -X theirs B

Testato su git versione 1.7.8

Per eseguire davvero un'unione che accetta solo input dal ramo che stai unendo, puoi farlo

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

Non ci saranno conflitti in nessuno scenario che conosco, non è necessario creare ulteriori rami e si comporta come un normale commit di unione.

Questo non funziona bene con i sottomoduli comunque.

Perché non esiste?

Mentre menziono in " comando git per creare un ramo come un altro " come simulare git merge -s theirs, nota che Git 2.15 (Q4 2017) è ora più chiaro:

La documentazione per " -X<option>" per le fusioni è stata scritta in modo fuorviante per suggerire che " -s theirs" esiste, il che non è il caso.

Vedi commit c25d98b (25 set 2017) di Junio ​​C Hamano ( gitster) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 4da3e23 , 28 set 2017)}

strategie di unione: evitare di insinuare che " -s theirs" esiste

La descrizione -Xoursdell'opzione di unione ha una nota tra parentesi che dice ai lettori che è molto diversa da -s ours, che è corretta, ma la descrizione -Xtheirsche segue la segue con noncuranza "questo è l'opposto di ours", dando una falsa impressione che anche i lettori hanno bisogno essere avvertito che è molto diverso da quello -s theirsche in realtà non esiste nemmeno.

-Xtheirsè un'opzione di strategia applicata alla strategia ricorsiva. Ciò significa che la strategia ricorsiva unirà ancora tutto ciò che può e tornerà alla " theirs" logica in caso di conflitti.

Quel dibattito sulla pertinenza o meno di una theirsstrategia di fusione è stato riportato di recente in questo thread di settembre 2017 .
Riconosce le discussioni precedenti (2008)

In breve, la discussione precedente può essere riassunta in "non vogliamo -s theirs" poiché incoraggia il flusso di lavoro sbagliato ".

Menziona l'alias:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

Yaroslav Halchenko prova ancora una volta a sostenere questa strategia, ma Junio ​​C. Hamano aggiunge :

La ragione per cui la nostra e la loro non sono simmetriche è perché tu sei tu e non loro --- il controllo e la proprietà della nostra storia e della loro storia non sono simmetrici.

Una volta che decidi che la loro storia è la linea principale, preferiresti trattare la tua linea di sviluppo come un ramo laterale e fare una fusione in quella direzione, cioè il primo genitore della fusione risultante è un impegno sulla loro storia e il secondo genitore è l'ultimo cattivo della tua storia. Quindi finiresti per usare " checkout their-history && merge -s ours your-history" per mantenere sensibile la prima genitorialità.

E a quel punto, l'uso di " -s ours" non è più una soluzione alternativa per mancanza di " -s theirs".
È una parte propria della semantica desiderata, cioè dal punto di vista della linea di storia canonica sopravvissuta, vuoi preservare ciò che ha fatto, annullando ciò che ha fatto l'altra linea di storia .

Junio ​​aggiunge, come commentato da Mike Beaton :

git merge -s ours <their-ref>dice in modo efficace "contrassegna i commit commessi <their-ref>nella propria succursale come commit da ignorare permanentemente";
e questo è importante perché, se successivamente si uniscono da stati successivi del loro ramo, le loro modifiche successive verranno apportate senza che le modifiche ignorate vengano mai apportate .

Vedi la risposta ampiamente citata di Junio ​​Hamano : se hai intenzione di scartare i contenuti impegnati, scarta semplicemente i commit o comunque mantienili fuori dalla storia principale. Perché disturbare tutti in futuro a leggere i messaggi di commit da commit che non hanno nulla da offrire?

Ma a volte ci sono requisiti amministrativi, o forse qualche altro motivo. Per quelle situazioni in cui devi davvero registrare commit che non contribuiscono a nulla, vuoi:

(modifica: wow, sono riuscito a sbagliare prima. Questo funziona.)

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Questo utilizza un albero di comando git plumbing read-tree, ma consente un flusso di lavoro complessivo più breve.

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Questo unirà il tuo nuovo Branch in base Branch esistente

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Penso che quello che vuoi davvero sia:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

Sembra goffo, ma dovrebbe funzionare. L'unica cosa che non mi piace di questa soluzione è che la cronologia git sarà confusa ... Ma almeno la cronologia sarà completamente preservata e non dovrai fare qualcosa di speciale per i file eliminati.

L'equivalente (che mantiene l'ordine genitore) a "git merge -s theirs branchB"

Prima di unire:

!!! Assicurati di essere in uno stato pulito !!!

Fai l'unione:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

Cosa abbiamo fatto ? Abbiamo creato un nuovo commit che due nostri genitori e loro e la contnet del commit è branchB - loro

Dopo l'unione:

Più precisamente:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Questa risposta è stata data da Paul Pladijs. Ho appena preso i suoi comandi e ho creato un alias git per comodità.

Modifica il tuo .gitconfig e aggiungi quanto segue:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

Quindi puoi "git merge -s theirs A" eseguendo:

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Di recente ho dovuto farlo per due repository separati che condividono una storia comune. Ho iniziato con:

• Org/repository1 master
• Org/repository2 master

Volevo che tutte le modifiche repository2 masterfossero applicate repository1 master, accettando tutte le modifiche che repository2 avrebbe apportato. In termini di git, questa dovrebbe essere una strategia chiamata -s theirsMA NON esiste. Fai attenzione perché il -X theirsnome è come sarebbe quello che vuoi, ma NON è lo stesso (lo dice anche nella pagina man).

Il modo in cui ho risolto questo è stato quello di andare repository2e creare un nuovo ramo repo1-merge. In quel ramo, ho corso git pull git@gitlab.com:Org/repository1 -s ourse si fonde bene senza problemi. Lo spingo poi sul telecomando.

Poi torno a repository1e faccio una nuova filiale repo2-merge. In quel ramo, corro, git pull git@gitlab.com:Org/repository2 repo1-mergeche completerà con problemi.

Infine, dovresti emettere una richiesta di unione repository1per renderla il nuovo master o semplicemente tenerla come una diramazione.

Un modo semplice e intuitivo (secondo me) in due passaggi per farlo è

git checkout branchB .
git commit -m "Picked up the content from branchB"

seguito da

git merge -s ours branchB

(che segna l'unione dei due rami)

L'unico svantaggio è che non rimuove i file che sono stati eliminati in branchB dal tuo ramo attuale. Una semplice differenza tra i due rami in seguito mostrerà se ci sono tali file.

Questo approccio chiarisce anche successivamente dal registro delle revisioni cosa è stato fatto e cosa è stato previsto.