When doing a git rebase
, I often have difficulty working out what is happening with the 'local' and 'remote' when resolving conflicts. I sometimes have the impression that they swap sides from one commit to the next.
This is probably (definitely) because I still don't properly understand the paradigm.
When rebasing, who is 'local' and who is 'remote'?
(I use P4Merge for resolving conflicts.)
To summarize (As Benubird comments):
When resolving conflicts during:
git checkout A
git rebase B # rebase A onto B
LOCAL
= B
(the branch you are rebasing onto)REMOTE
= A
(your original branch being rebased)When resolving conflicts during:
git checkout A
git merge B # merge B into A
LOCAL
= A
(the branch you are merging into)REMOTE
= B
(the branch you are merging from)In short:
LOCAL always means "the branch that stays where it is"
REMOTE always means "the branch that is being moved or merged in"
kutschkem points out that, in a GUI mergetool context:
ours
" (the upstream branch)theirs
" - the current branch before the rebase.See illustrations in the last part of this answer.
The confusion might be related to the inversion of ours
and theirs
during a rebase.
(relevant extracts)
Note that a rebase merge works by replaying each commit from the working branch on top of the
<upstream>
branch.
Because of this, when a merge conflict happens:
ours
' is the so-far rebased series, starting with <upstream>
,theirs
' is the working branch.
In other words, the sides are swapped.x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
, we don't change the current branch 'B', so what we have is still what we were working on (and we merge from another branch)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
But on a rebase, we switch side because the first thing a rebase does is to checkout the upstream branch! (to replay the current commits on top of it)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
A git rebase upstream
will first change HEAD
of B to the upstream branch HEAD
(hence the switch of 'ours' and 'theirs' compared to the previous "current" working branch.)
x--x--x--x--x <- former "current" branch, new "theirs"
\
\
\--y--y--y(*) <- upstream branch with B reset on it,
new "ours", to replay x's on it
, and then the rebase will replay 'their' commits on the new 'our' B branch:
x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
\
\
\--y--y--y--x'--x'--x'(*) <- branch B with HEAD updated ("ours")
^
|
upstream branch
Note: the "upstream" notion is the referential set of data (a all repo or, like here, a branch, which can be a local branch) from which data are read or to which new data are added/created.
local
' and 'remote
' vs. 'mine
' and 'theirs
'Pandawood adds in the comments:
For me, the question still remains, which is "local" and who is "remote" (since the terms "ours" and "theirs" are not used when rebasing in git, referring to them just seems to make an answer more confusing).
kutschkem adds, and rightly so:
When resolving conflicts, git will say something like:
local: modified file and remote: modified file.
I am quite sure the question aims at the definition of local and remote at this point. At that point, it seems to me from my experience that:
ours
" (the upstream branch)theirs
" - the current branch before the rebase.git mergetool
does indeed mention 'local' and 'remote':
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
For instance, KDiff3 would display the merge resolution like so:
And meld would display it too:
Same for VimDiff, which displays:
Invoke Vimdiff as a mergetool with git mergetool -t gvimdiff. Recent versions of Git invoke Vimdiff with the following window layout:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL
:
A temporary file containing the contents of the file on the current branch.
BASE
:REMOTE
:MERGED
:Git has performed as much automatic conflict resolution as possible and the state of this file is a combination of both
LOCAL
andREMOTE
with conflict markers surrounding anything that Git could not resolve itself.
Themergetool
should write the result of the resolution to this file.