Re: [PATCH] merge-recursive: do not report the resulting tree object name
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Jan 13, 2007, 05:14 UTC
- Message-ID
- <20070113051447.GA22063@spearce.org>
- In-Reply-To
- <7vbql3pxz8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
Show 22 quoted lines
> $ 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.
Show 9 quoted lines
> 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.