Gitextensions: Conflict resolution window labels local as theirs and remote as ours during normal merge.

GitExtensions is actually correct. See the section on merging in this link: http://stackoverflow.com/questions/3051461/git-rebase-keeping-track-of-local-and-remote

"ours" is the current branch, while "theirs" is the branch we are merging in. Typical git workflow is to create a local topic branch, commit to it, and then merge into the "master" branch. So, "theirs" is also referred to as "local", and "ours" is referred to as "remote", since it typically follows the state of the remote repository.

I'm agree with dleinhaeuser, these names are really vague.

Beginners are always feel confused while selecting which version to select. I help my friends with git and most of them asked me which choice is correct in that window.

I'm not sure that git has one typical workflow, because everyone uses it with own preferences. For example, when I work on a topic branch for a few days or weeks, I prefer to merge master into my topic branch from time to time to prevent merge hell and to resolve conflicts as soon as possible. It helps to keep compatible ready-to-merge codebase and it is really helpful for long feature branches.

My suggestions is to just write actual branch names and rely that user know which branch contains actual code.
For example, "choose ours (master)" and "choose theirs (feature-branch-42)" are much more clear names.

yes, its very confusing. Ours and theirs do have actual meaning in git-land: you can use them to change the merge strategy, so you should use them in the same way that git uses them. And yes, mentioning the actual branch name would be best, but I am not sure if kdiff supports that.

Consider the following sequence of commands:

> mkdir test && cd test
> git init
> touch test.txt
> git add test.txt
> git commit -m "..."
> git branch test
> git checkout test
> echo "test" >test.txt
> git commit -a -m "..."
> git checkout master
> echo "master" >test.txt
> git add -a -m "..."
> git merge test

At this point there will be a merge conflict on test.txt.
If I now open up git gui, it will show the conflict in the commit window.
Right clicking on the diff window will offer "Use remote version" and "Use local version".

• If I choose "Use local version", the contents of test.txt will be "master" after the merge.
• If I choose "Use remote version", the contents of test.txt will be "test" after the merge.

So according to git gui's logic, the current branch is "local" and the branch that I am merging into it is "remote".

If I continue to use the command line instead of git gui to resolve the conflict, I can run the following commands:

> git checkout --ours test.txt
> cat test.txt
master
> git checkout --theirs test.txt
> cat test.txt
test

So on the CLI, "ours" refers to the current branch and "theirs" to the one I am merging in.
That's why I think the menu in Git Extensions is giving conflicting information.

Maybe ours and theirs switch places when merges are done differently. If so, then I am not aware of it.

Thanks, that makes sense. And, in fact, when you launch kdiff to resolve a conflict, then the current branch (--ours) is referred to as .LOCAL. So, yes, it looks like there is a problem with the menu.

Okay. Apparently "ours" and "theirs" switch places during a rebase.

Could it be, that git gui is set up such, that "local" and "remote" make sense for merge conflict during a pull operation?

In any case this certainly confuses people switching from git gui (like me).
Maybe it would be sufficient to point this out in the documentation.

Hmmmmmm, I guess if you do a "pull --rebase", (which I use by default) then the menu may be correct, due to ours and theirs switching. But yes, this is extremely confusing, and should be documented somewhere. Also, the local and remote
terminology is very confusing, since we already have local branches and remote repositories.

BTW, you can do this a little more efficiently:

mkdir test && cd test
git init
touch test.txt
git add test.txt
git commit -m "..."
git checkout -b test *
echo "test" >test.txt
git commit -am "..."
git checkout master
echo "master" >test.txt
git commit -am "..." **
git merge test

dleinhaeuser's original explanation of the issue is correct.
The correct words should be

Choose local (ours)
Choose remote (theirs)

You can see this by selecting "Open local with" and "Open remote with" and seeing "local" opens your file with your new changes and remote opens their version.

Rebase is trickier (I always look at that picture to make sure I'm doing it the right way, haha). "Ours" & "theirs" is incorrect, in my opinion.
Say you want to rebase "Branch A" onto "Master".
Although you must be checked out in "Branch A" in order to rebase Branch A onto Master, in the merge conflict you are considered to be in the Master branch (bear with me here...). You are considered to be in Master because you are attempting to "play" Branch A's commit AFTER Master's commits, so it's similar to being in Master's branch and doing a pull.

right. This posting explains things pretty well:

http://stackoverflow.com/questions/3051461/git-rebase-keeping-track-of-local-and-remote

So, local/remote should be ours/theirs for merge, and theirs/ours for rebase.

This is particularly confusing for post-pull conflicts, where theirs is clearly remote. Is anyone planning to fix it?

Ok, the labels should be fixed in the above commit.
Normal merge says

Choose local (ours)
Choose remote (theirs)

and rebase merge remains unchanged ie.

Choose local (theirs)
Choose remote (ours)

That would be muuuch easier to understand what is going on if instead of LOCAL/REMOTE or OURS/THEIRS it should simply display the branch names.

See #6582 for a more recent discussion