È possibile memorizzare file contenenti dati di conflitto. C'è un modo per contrassegnare questi file come nuovamente in conflitto, in modo che l'esecuzione di git mergetool genererà i file necessari ed eseguirà lo strumento di unione?C'è un modo per far sì che Git contrassegni un file come in conflitto?
È possibile ottenere il contenuto del file con indicatori di conflitto utilizzando git checkout --conflict=merge -- file, ma se è stato pulito l'indice utilizzando git add file (o se la GUI lo ha fatto per te) non funzionerebbe.
C'è git update-index --unresolve, ma è un hacker e non funziona in modo molto affidabile. Penso che lo stato che ripristina non sarebbe sufficiente per git-mergetool.
Probabilmente dovresti rifare unire o usare git update-index --cacheinfo per impostare manualmente la versione degli stage ... git-stash può aiutarti a mantenere i conflitti risolti correttamente.
Per quanto ne so, non sarà possibile eseguire il commit mentre un file contiene ancora segnalini di conflitto. ... che non è esattamente vero:
Il PO menziona il fatto che è possibile (I copiare qui his pastbin), ma questo non sarà sufficiente per il mergetool da innescare di nuovo:
Auto-merged README
CONFLICT (content): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.
lynx:~/test_clone$ ls
README
lynx:~/test_clone$ git add README
lynx:~/test_clone$ git commit -a
Created commit 46ee062: It works!
lynx:~/test_clone$ ls
README
lynx:~/test_clone$ cat README
<<<<<<< HEAD:README
testingtesting
=======
hmm
>>>>>>> 881d60f5f738bc5716f5c9a9384e262b535717fd:README
lynx:~/test_clone$
Come Charles Bailey commenti e illustra in questo SO answer, il mergetool viene interrogato perché ci sono 3 istanze dello stesso file nell'indice:
Per un file unmerged in un conflitto ma git kes disponibili nella versione comune, versioni locali e remote del file nell'indice. (Questo è dove vengono letti da per l'uso in uno strumento di diff 3 vie per
git mergetool.) È possibile utilizzare git show per vederle:
# common base:
git show :1:afile.txt
# 'ours'
git show :2:afile.txt
# 'theirs'
git show :3:afile.txt
git add (con qualsiasi contenuto, compresi i marcatori di conflitto) sarà rimuove automaticamente 2 di essi, assicurando che mergetoolnon sia chiamato di nuovo.
In effetti è possibile. Semplicemente facendo un git aggiungere
@Christian: interessante (ho modificato la risposta per rispecchiarlo), ma il 'git mergetool' lo rileverà e riattiverà un'unione? – VonC
git determina che un file è in conflitto se ha più voci nell'indice, piuttosto che solo il solito. git inserisce indicatori di conflitto nella versione ad albero di lavoro per aiutare l'utente a risolvere il conflitto, ma questi non sono il modo in cui Git conta il file come non sommerso. Chiamare git add dice a git di aggiungere la versione ad albero funzionante del file all'indice _removing tutte le altre voci_. Dopo aver aggiunto git, dato che ora c'è solo una singola voce di indice, il file non è più "irrisolto", quindi puoi impegnarlo. –
@VonC: Non ho creato un account all'inizio (ora ho), quindi non ho potuto postare un commento. Invocare git mergetool non lo rileva, a quanto pare:
Auto-merged README CONFLICT (content): Merge conflict in README Automatic merge failed; fix conflicts and then commit the result. lynx:~/test_clone$ ls README lynx:~/test_clone$ git add README lynx:~/test_clone$ git commit -a Created commit 46ee062: It works! lynx:~/test_clone$ ls README lynx:~/test_clone$ cat README >>>>>> 881d60f5f738bc5716f5c9a9384e262b535717fd:README lynx:~/test_clone$ git mergetool merge tool candidates: opendiff emerge vimdiff No files need merging lynx:~/test_clone$
git mergetool può accettare un nome di file, ma questo non funziona neanche:
Auto-merged README
CONFLICT (content): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.
caracal:~/test_clone2$ git mergetool
merge tool candidates: opendiff emerge vimdiff
Merging the files: README
Normal merge conflict for 'README':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (emerge):
caracal:~/test_clone2$ ls
#*merge*#145962bz# README README~ README.orig
caracal:~/test_clone2$ git mergetool
merge tool candidates: opendiff emerge vimdiff
No files need merging
caracal:~/test_clone2$ git mergetool README
merge tool candidates: opendiff emerge vimdiff
README: file does not need merging
caracal:~/test_clone2$ ls
#*merge*#145962bz# README README~ README.orig
caracal:~/test_clone2$
Nota anche qui che non ho commesso dopo uscendo da git mergetool.
Ho appena completato la mia risposta dopo il commento di Charles. – VonC
s/lynx:. * \ $/\ N #/g – user1133275
La soluzione più elegante sarebbe quella di evitare che questo problema fin dall'inizio:
git config --global mergetool.[tool].cmd [command-line call] git config --global mergetool.[tool].trustExitCode false
Cura da elaborare? – Tarrasch
Sì. Ciò farà sì che Git chieda ogni volta se il file è stato unito con successo invece di fare affidamento sullo strumento di unione stesso per segnalare il successo o l'errore in modo veritiero. –
quindi vuol dire che non 'aggiungerà' i file a meno che tu risponda di si? Ho anche "mergetool.prompt = false" che influenzerà questo? – Superole
Si prega di utilizzare git update-index --unresolve
Dal git 1.7 utilizza resol-end informazioni dall'indice per ripristinare tutte e 3 le fasi (1: base, 2: nostra, 3: loro): https://github.com/git/git/commit/8aa38563b22c84b06ea1fff9638cc1f44fda726f
Se l'indice è già in uno stato di conflitto, è sufficiente controllare il file con il --conflict=merge bandiera:
git checkout --conflict=merge file
Se l'indice è pulita perché il file irrisolto è stato [erroneamente] ha aggiunto, sarà sufficiente resettarlo prima del check-out:
git reset file
git checkout --conflict=merge file
Questo vi permetterà di riprendere la risoluzione dei conflitti normalmente (ad esempio, git mergetool).
NOTA: promozione di un commento alla risposta di @jakub-narębski nella propria risposta su richiesta da @fourpastmidnight. :)
Heh, stavo solo scrivendo questa risposta. ;-) – ebneter
cos'è hacky e inaffidabile al riguardo? –
'git update-index --unresolve' è stato creato in tempi" antichi "per consentire di ripristinare' git diff --ours' ecc. Dopo (accidentale) 'git add' a conferma della risoluzione del conflitto. Inserisce la versione HEAD (non la versione con conflitti risolvibili automaticamente risolti) nella fase n. 2, inserisce la versione MERGE_HEAD nella fase n. 3 e non inserisce nulla nella fase n. 1, la versione antenata. –