Re: [PATCH] merge-recursive: do not report the resulting tree object name
From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:42:49
Junio C Hamano [off-list ref] 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.