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. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html