Re: [PATCH] merge-recursive: do not report the resulting tree object name

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> 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.