Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help