Junio C Hamano <junkio@xxxxxxx> wrote: > $ git merge jc/merge-base > 1 Trying really trivial in-index merge... > 2 fatal: Merge requires file-level merging > 3 Nope. > 4 Merging HEAD with jc/merge-base > 5 Merging: > 6 b60daf0 Make git-prune-packed a bit more chatty. > 7 5b75a55 Teach "git-merge-base --check-ancestry" about refs. > 8 found 1 common ancestor(s): > 9 1c23d79 Don't die in git-http-fetch when fetching packs. > 10 Auto-merging Makefile > 11 Auto-merging builtin-branch.c > 12 Auto-merging builtin-reflog.c > 13 CONFLICT (content): Merge conflict in builtin-reflog.c > 14 Auto-merging builtin.h > 15 Auto-merging git.c > 16 Removing merge-base.c > 17 Resolved 'builtin-reflog.c' using previous resolution. > 18 Automatic merge failed; fix conflicts and then commit the result. > > Among these, I think lines 2..3 are somewhat confusing but I am > used to seeing them and do not mind them too much. In my experience these lines scare new users. And then they start to ignore other "fatal:" messages from Git because they can safely ignore this particular one. Not good. One reason I like my patch that's in next. > Lines 4..9 do not have any real information that helps the end > user (even though it would be a very good debugging aid for > merge-recursive developers). I agree. I've grown used to seeing them and read it for entertainment. Clearly I need to get out more. They probably should be relegated to a GIT_MERGE_OPTIONS environment variable flag or to a command line parameter, as they are probably only useful when debugging the application itself. > Lines 10..16 are useful, but I think we probably should show > them only for outermost merges. Actually I think that only 13 is useful. 10-12,14-17 are pretty useless messages in my mind. I really don't care that merge-recursive automatically merged these files, as in all cases but the one reported by line 13 the merge was successful. The diffstat that is normally displayed by git-merge after a successful merge shows you what files were modified by the other branch. It also often causes the output of merge-recursive to scroll off the screen, making those messages even less useful. > An multi-base example: > 16 Auto-merging gitweb/gitweb.perl > 17 Merge made by recursive. > 18 gitweb/gitweb.css | 2 + > 19 gitweb/gitweb.perl | 165 ++++++++++++++++++++++++++++++++... > 20 2 files changed, 117 insertions(+), 50 deletions(-) > > I do not think we need to show 1..15 at all, perhaps without > "export GIT_MERGE_BASE_DEBUG=YesPlease". Yes, I agree. Except I'd say 1..16, for the reason stated above. But then I would like a progress meter, showing % of files resolved, to keep the user entertained. Alex has 1 min+ merges. 1 minute of absolutely no feedback is not very nice to a new user. Maybe when I'm done hacking on git-describe performance improvements I'll look at merge-recursive. -- Shawn. - 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