Branch: refs/heads/master
Home:   https://github.com/D-Programming-Language/phobos

Commit: db5b27dcd20a367e89b36cf912ea0dd96c739b82
    https://github.com/D-Programming-Language/phobos/commit/db5b27dcd20a367e89b36cf912ea0dd96c739b82
Author: Andrei Alexandrescu <andrei at erdani.com>
Date:   2011-02-26 (Sat, 26 Feb 2011)

Changed paths:
  R std/array.d
  M std/container.d
  M win32.mak

Log Message:
-----------
Merge branch 'jmdavis-red-black'

Conflicts:
	std/array.d


Commit: f6c8566517054acdd246df0d67ab51e9b1fb3780
    https://github.com/D-Programming-Language/phobos/commit/f6c8566517054acdd246df0d67ab51e9b1fb3780
Author: Andrei Alexandrescu <andrei at erdani.com>
Date:   2011-02-26 (Sat, 26 Feb 2011)

Log Message:
-----------
Merge branch 'red-black' of https://github.com/jmdavis/phobos


Commit: 31d47df17fc77a5a16e4e51267eaa6952ba01213
    https://github.com/D-Programming-Language/phobos/commit/31d47df17fc77a5a16e4e51267eaa6952ba01213
Author: Andrei Alexandrescu <andrei at erdani.com>
Date:   2011-02-26 (Sat, 26 Feb 2011)

Changed paths:
  A std/array.d

Log Message:
-----------
readded std/array.d

On Saturday 26 February 2011 17:22:47 noreply at github.com wrote:
> Branch: refs/heads/master
> Home:   https://github.com/D-Programming-Language/phobos
> 
> Commit: db5b27dcd20a367e89b36cf912ea0dd96c739b82
> 
> https://github.com/D-Programming-Language/phobos/commit/db5b27dcd20a367e89
> b36cf912ea0dd96c739b82 Author: Andrei Alexandrescu <andrei at erdani.com>
> Date:   2011-02-26 (Sat, 26 Feb 2011)
> 
> Changed paths:
>   R std/array.d
>   M std/container.d
>   M win32.mak
> 
> Log Message:
> -----------
> Merge branch 'jmdavis-red-black'
> 
> Conflicts:
> 	std/array.d
> 
> 
> Commit: f6c8566517054acdd246df0d67ab51e9b1fb3780
> 
> https://github.com/D-Programming-Language/phobos/commit/f6c8566517054acdd2
> 46df0d67ab51e9b1fb3780 Author: Andrei Alexandrescu <andrei at erdani.com>
> Date:   2011-02-26 (Sat, 26 Feb 2011)
> 
> Log Message:
> -----------
> Merge branch 'red-black' of https://github.com/jmdavis/phobos
> 
> 
> Commit: 31d47df17fc77a5a16e4e51267eaa6952ba01213
> 
> https://github.com/D-Programming-Language/phobos/commit/31d47df17fc77a5a16
> e4e51267eaa6952ba01213 Author: Andrei Alexandrescu <andrei at erdani.com>
> Date:   2011-02-26 (Sat, 26 Feb 2011)
> 
> Changed paths:
>   A std/array.d
> 
> Log Message:
> -----------
> readded std/array.d

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.

- Jonathan M Davis

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?

Andrei

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.

- 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

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