Re: git and bzr

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 28 Nov 2006, Shawn Pearce wrote:
> 
> Except when you are doing a large merge, your terminal scrollback
> is really short, and there's a lot of conflicts.  Then you can't
> see what merge said about any given file.  :-(

Heh. Which is partly why I just do "git diff", which usually tells me what 
is up, or "git log --stat --merge", which is usually even better. I've 
never actually had to scroll up.

[ But I'll also admit that I used to have a "xterm*savedlines=5000" in my 
  .Xdefaults, and it might be worth it for some people. I haven't actually 
  needed it with git, because the _real_ reason for it used to be applying 
  patch-sets, and I've made sure that the git patch-application is so 
  robust that I never need to go back and look for reasons for conflicts - 
  if something conflicts, it just _stops_ and undoes the whole patch 
  instead of continuing to apply the rest or leave the already-applied 
  part applied. ]

Although I agree that we could probably also improve "git status" output, 
especially as I doubt it has been tested much.

People don't tend to use "git status" very much, I suspect - the most 
common usage is not in "git status" itself, but simply as the commit 
message template, and that one obviously cannot have any unmerged stuff at 
all (since then we'd refuse to even go as far as asking for a commit 
message in the first place).

Figuring out that the reason for a conflict is a name clash is not 
necessarily possible after the merge, though: it's really up to the merge 
policy to decide to merge a file cleanly or not, and the "Why" part of why 
some particular merge policy decided not the resolve a file is really 
internal to the policy, and not externally visible in the tree itself.

(But we can certainly see whether it was a pure content conflict or 
whether it had some component of a name clash by just looking at what 
stages we have for a name: so we could at least separate out the causes 
for merge failures at least _partially_ in "git status")

> Fortunately its easy to back out of the merge and redo it with
> large enough scrollback, or redirecting it to a file for later
> review, but its annoying that we don't save that information off
> for later review.

I personally find "git log --merge" to be a huge timesaver. But I have to 
say, I don't think I've seen more than one or two name conflicts ever, and 
almost all of the true issues tend to be just regular data conflicts. So 
that's what I personally care about most.

[ For the non-git users, "git log --merge" is just shorthand for a much 
  more complicated git revision parsing expression which boils down to: 
  "show all commits as they pertain to any remaining unmerged pathnames, 
  and only within the symmetrical set difference between the two branches 
  you merged". You could write it out as

	git log ORIG_HEAD...MERGE_HEAD -- $(git ls-files --unmerged)

  but that "git log --merge" is a much simpler shorthand for that thing. 

  It's not that merge conflicts are necessarily common, but when they do 
  happen, that's where you _really_ want the SCM to support you in 
  figuring out what happened ]

So with "git diff" showing a three-way diff for anything unmerged, and 
"git log --merge" showing the commits that caused the problems, I don't 
think I've ever really needed to go back and say "ok, so why did that 
fail". 

It's just that "git status" was never what I'd have used in the first 
place. I guess it's been long enough since I used CVS that "git status" 
doesn't even enter my mind all that much on a merge failure.