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

[Jonathan M Davis]

On Sunday 27 February 2011 01:02:27 Jonathan M Davis wrote:
> 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-g
> it
> 
> 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.

Actually, it looks like the bit about having to deal with every single change 
was simply because the merge tool that I was using showed the entirety of both 
versions and what they're differences are. The actual number of conflicts isn't 
any higher than it needs to be (and they were marked as conflicts in my merge 
tool - it's just that it was showing everything else as well). Still, it can be 
surprisingly easy to produce a merge conflict at times.

- Jonathan M Davis