[phobos] [D-Programming-Language/phobos] db5b27: Merge branch 'jmdavis-red-black'

[Jonathan M Davis]

On Saturday 26 February 2011 18:43:49 Jonathan M Davis wrote:
> On Saturday 26 February 2011 18:23:50 Andrei Alexandrescu wrote:
> > On 2/26/11 7:59 PM, Jonathan M Davis wrote:
> > > Well, that's mean of it. It treated those changes like std.array had
> > > been completed removed and re-added. That makes it rather hard to see
> > > any changes.
> > 
> > Trying to merge your changes I had two weird merge errors on apparently
> > identical lines (probably trailing whitespace or line terminators). I
> > didn't know what the heck to do and ended up doing a booboo. Is it
> > possible to somehow undo that crap?
> 
> It would require rebasing, which you should only do on your local box with
> changes that haven't been merged into the main tree yet. There was probably
> a better way to handle it while merging, but dealing with merge conflicts
> in git is not something that I have much experience with, so I don't know
> the best way to do it. There are definitely commands and tools for getting
> it to do what you want, but it would probably take a bit of research and
> playing around with them on actual merge conflicts to figure out exactly
> the best way to deal with them.

This is probably a good place to look for info on how to deal with merge 
conflicts:

http://stackoverflow.com/questions/161813/how-do-i-fix-merge-conflicts-in-git

Essentially, what it seems to como down to is that git-merge merges the files, 
putting the conflicts _in_ the file. Then you edit the file to whatever it should 
be, git-add it, and then git-commit all of the changes. You can use git-
mergetool to use a tool to deal with merging the changes (the man page for git-
mergetool lists several tools; kdiff3 seems to work fairly well for me) if you 
don't want to do it by hand. I believe that you can also select one of the two 
versions (throwing away the other) by using git-checkout on MERGE_HEAD or 
ORIG_HEAD on the file in question.

Trying to merge in you recent (large) pull request in order to better review it, 
I'm a bit surprised at how many small things that git complains about and claims 
that they're conflicting. If a file was changed on only one branch, you're fine, 
but it seems that as soon as something has been changed in two branches, it 
generally wants you to look at the _entire_ file rather than just whatever pieces 
it couldn't figure out. That's not necessarily a bad thing, but it _does_ mean 
that when you merge two branches where one has a small change or two and the 
other has many, you're likely to have to look at every single change and verify 
it.

In any case, hopefully we don't have too many problems with merge conflicts, and 
hopefully it won't take much for us to figure out how to deal with them 
optimally.

- Jonathan M Davis