Der Mergeprozesses von git stash apply
-einem verwendet wird, ist die erste Hälfte des git stash pop
-ist das gleiche wie jeder andere merge, in Bezug auf die Wirkung hinter sich gelassen:
$ git status
On branch master
nothing to commit, working tree clean
$ git log --all --decorate --oneline --graph
* f9a96c0 (HEAD -> master) conflicting changes for stash
| * 069a595 (refs/stash) WIP on master: 6fee57d add file "file"
| |\
|//
| * c466c42 index on master: 6fee57d add file "file"
|/
* 6fee57d add file "file"
* 2353af8 initial
an diesem Punkt, und zwar unabhängig davon, ob ich laufe git stash apply
oder git stash pop
, erhalte ich einen Merge-Konflikt und dann stoppt der Prozess (nicht die zweite Hälfte git stash pop
tun):
$ git stash apply
Auto-merging file
CONFLICT (content): Merge conflict in file
$ git reset --hard HEAD
HEAD is now at f9a96c0 conflicting changes for stash
$ git stash pop
Auto-merging file
CONFLICT (content): Merge conflict in file
$ git stash list
[email protected]{0}: WIP on master: 6fee57d add file "file"
Was jetzt in dem Index ist, ist der unmerged Zustand, mit allen drei Kopien der Datei file
vorhanden:
$ git ls-files --stage
100644 239c0dc4252320079890fff28cd408eb825776f5 0 README
100644 2983120c0897fea017d8398b5ffdc5e3ef0e17ad 1 file
100644 27b6da381575999c9ba975e9df9ba6caa45e3165 2 file
100644 080f90d42698e258e3efa8059c78ebfd5fdd7bd8 3 file
und git mergetool
glücklich genug ist, an dieser Stelle zu laufen:
$ git mergetool
[snip configuration complaint - I never use git mergetool
so it is not configured]
Merging:
file
Normal merge conflict for 'file':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (bc):
Also, ich frage mich, ob es eine Möglichkeit gibt, Git Stash nicht automatisch zusammenführen, aber die Konflikte an Ort und Stelle ...
Alle drei Versionen der Datei sind zu diesem Zeitpunkt im Index vorhanden. Nur zwei von ihnen, --ours
(in der Regel das gleiche wie die HEAD
Commit-Version) und --theirs
(die stashed-commit-Version, in diesem Fall), haben bequeme git checkout
Befehlssyntax, aber Sie können auch die Merge-Base-Version mit der :<number>:path
Syntax extrahieren . Running git mergetool
tut das für Sie-extrahiert die Basis, links/local/ours
und rechts/remote/theirs
Versionen-kurz vor dem Ausführen Ihrer konfigurierten Merge-Tool.
Daher bin ich nicht wirklich sicher, was Ihre Frage war.
Einverstanden. Dies ist ein ziemlich normales Revisionskontrollsystemverhalten. – Mort
Nun, wenn ich git fusioniere, sagen wir von revision_5 branch und entwickle Zweig, und nehme an, dass es einen Konflikt gibt. Es wird versucht, automatisch zusammenzuführen. Wenn es toll ist, aber wenn nicht, fügt es nicht diese lästigen Tags von ihnen und uns in der Datei hinzu, es lässt sie einfach beide und der aktive Zweig in der Befehlszeile wird (entwickeln | MERGING). Willst du damit sagen, dass git stash apply nicht funktioniert und beide Versionen einfach in die einzelne Datei zusammengeführt werden, funktioniert git mergetool trotzdem und erlaubt mir, die Zusammenführung zu reparieren? – JaedenRuiner
In * allen * Merge-Konfliktfällen soll Git die so markierte Arbeitsbaumdatei belassen. Die Originale werden alle im Index gespeichert, so dass Sie anstelle der üblichen drei aktiven Versionen einer Datei (HEAD, Indexstufe 0, Arbeitsbaum) * fünf * aktive Versionen (HEAD; Indexstufen 1, 2, 3; Arbeitsbaum). Wenn Sie 'git add' oder' git rm' auf einem der Pfade ausführen, werden die drei Kopien der Indexstufe höherer Ordnung auf die Indexindexkopie der Stufe 0 reduziert, indem die Arbeitsbaumversion genommen wird. Das 'git mergetool'-Skript führt das' git add' für Sie aus, wenn es glaubt, dass das Tool, das es ausgeführt hat, erfolgreich war. – torek