Git confuses local and remote, or do I?

Question

I don't understand what LOCAL and REMOTE mean in this context, and I have the feeling that git is buggy on this regard.

I did changes to x.py. A colleague also changed the same file and committed and pushed before me. Before doing any operation, I copied my version of the file in x.py.mine. I tried to commit and push but it got rejected and I had a conflict. The situation is now the following

Size  Date         File

57795 May  7 15:59 x.py.BACKUP.16533.py
54921 May  7 15:59 x.py.BASE.16533.py
54812 May  7 15:59 x.py.LOCAL.16533.py
57151 May  7 16:08 x.py.mine
57151 May  7 15:59 x.py.REMOTE.16533.py

Note how git marks my file as the "REMOTE" and the colleague's file as "LOCAL". To me, it should be the exact opposite. I have a local file and the colleague put the remote one, which I got from the remote server.

Is it a bug of git or is it me?

[This answer](http://stackoverflow.com/a/3052118/126042) might help. — Mark Rushakoff, May 07 '13 at 14:28
Git would not produce these files : are you using TortoiseGit or something like that? — cexbrayat, May 07 '13 at 14:34
@cexbrayat: plain git, so apparently it does. Probably it was git mergetool ? I use vimdiff — Stefano Borini, May 07 '13 at 14:39
based on Mark's comment (and on my knowledge of `git rebase`), how may ask: how did you try to push? which command you run exactly? I check [vimdiff](http://vim.wikia.com/wiki/A_better_Vimdiff_Git_mergetool) and it states that: `LOCAL` is "A temporary file containing the contents of the file on the current branch" and `REMOTE` "A temporary file containing the contents of the file to be merged", so it clearly depends on how git resolved the local branch and how the the file to be merged, so to me it depends on how you tried to push — ThanksForAllTheFish, May 07 '13 at 14:59
I imagine that. Then I confirm Mark's link explain why you have the impression git is confusing `LOCAL` and `REMOTE`. Take a look at http://git-scm.com/book/en/Git-Branching-Rebasing too, in particular the section `More Interesting Rebases`, I think it explains clearly the point. Notice that `--rebase` changes the behaviour of `git pull` since it will not `merge` the differences but it will `rebase` them — ThanksForAllTheFish, May 07 '13 at 15:17

score 3 · Accepted Answer · edited May 23 '17 at 10:25

3

Vimdiff, that you use as your mergetool, is producing these files (by default Git will just add <<<< and ==== in your file).

The answer to How to use vimdiff might help you to understand how vimdiff works with Git.

edited May 23 '17 at 10:25

Community

1
1

answered May 07 '13 at 14:51

cexbrayat

17,772
4
27
22

score 0 · Answer 2 · answered May 07 '13 at 14:51

You could try double checking your .gitconfig mergetool options to make sure the local and remote references passed as paramaters to vimdiff are in the correct order. For example, my .gitconfig is as follows (I use p4merge).

[mergetool "p4merge"]
    cmd = p4merge.exe $BASE $LOCAL $REMOTE $MERGED

I could try changing it to the following but it shouldn't really matter what order the are specified in.

[mergetool "p4merge"]
    cmd = p4merge.exe $BASE $REMOTE $LOCAL $MERGED

Git confuses local and remote, or do I?

2 Answers2