git and bzr

[James Westby]

On (28/11/06 22:26), Nicholas Allen wrote:
> > 
> > Just out of curiosity: How does git handle the case where one file is
> > renamed differently in 2 branches and then the branches are repeatably
> > merged? I know that bzr handles this very well and in various tests I
> > did there were absolutely no repeated conflicts. Would git behave as
> > well in this scenario?
> > 
> 
> Ok - I got curious and decided to install git and try this myself.
> 
> In this test I had a file hello.txt that got renamed to hello1.txt in
> one branch and hello2.txt in another. Then I merged the changes between
> the 2 branches.
> 

> 
> and here's how it looked in git:
> git status
> #
> # Changed but not updated:
> #   (use git-update-index to mark for commit)
> #
> #       unmerged: hello.txt
> #       unmerged: hello1.txt
> #       unmerged: hello2.txt
> #       modified: hello2.txt

This is git's version of the bzr output that I trimmed above. The
unmerged entries are the conflicts. (Please correct the next bit if I am
wrong) Git will merge files "in the index" if there are no conflicts,
and you don't need to worry about those files. The unmerged ones have
conflicts that need the user to sort out, these are left as unresolved
in the index.

> #
> nothing to commit

This is because the only file that changed here had the conflict and so
the index hasn't been updated and so there was nothing to commit. Above
git is telling you to update the index above, which will involve
resolving the conflict and then you will have something to commit. 

So what the whole text is saying is 

  "I tried to do the merge you requested in the index, but there were
  conflicts in the files listed as unmerged. Please fix these conflicts,
  and then tell me you have done so by updating the index. Then you are
  free to commit the merge."

> 
> So git is not telling me that I have a conflict due to the same file
> being renamed differently in 2 branches - well at least not in a way I
> can comprehend anyway! Whereas bzr made this very clear. Also, in git I
> ended up with 2 files:
> 
>  ls
> hello1.txt  hello2.txt

So in this case if you want the first do

  $ rm hello2.txt
  $ git update-index hello1.txt
  $ git commit

> 
> I'm not sure how I should resolve the conflict in git but that's
> probably just because I am not familiar with it yet and the message it
> gave was not comprehensible or helpful to me in the slightest. In bzr it
> was very easy and repeatably merging caused no trouble at all - the name
> conflict had to be resolved only once.
> 
> While it was good that git detected my file rename (although this was
> not hard as the contents did not change at all) the process in bzr was
> *much* smoother and more user friendly than it was it git. When you have
> conflicts I think it's especially important that the RCS inform you of
> what is really happening so you do not make mistakes. Bzr was much more
> informative than git was and told me exactly why there was a conflict
> and made it easy to resolve it.

Its unfortuanate that you chose the case that would be the most
difficult for someone not used to git to comprehend. I did something
very similar to this in my first play attempts with git, and it took me
ages to work out how to actually fix it. The solution is actually quite
simple, but it does force the user to confront the index, and so other
people doing the same as Nicholas will probably have the same trouble.

>From when I hit this case I spent some time looking for git-resolve, and
then searching for guides on merging and handling conflicts, but I
didn't find one that dealt with this case for a while.

> 
> This situation is a pretty common one and it seems to me that git's
> content based approach is not as useful in this case as the file
> identity approach that bzr uses.
> 

I don't think the problems that you have given here are to do with the
content based approach, but your main trouble was with git's merging
strategy. 

I'm not sure that your example tells us much about the relative merits
of each approach, but I can't come up with a simple example that does
right now.

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256