[RFC/PATCH] fail pull/merge early in the middle of conflicted merge

[RFC/PATCH] fail pull/merge early in the middle of conflicted merge

[Junio C Hamano]

After a pull that results in a conflicted merge, a new user
often tries another "git pull" in desperation.  When the index
is unmerged, merge backends correctly bail out without touching
either index nor the working tree, so this does not make the
wound any worse.

The user will however see several lines of messsages during this
process, such as "filename: needs merge", "you need to resolve
your current index first", "Merging...", and "Entry ... would be
overwritten by merge. Cannot merge.".  They are unnecessarily
alarming, and makes useful conflict messages from the first pull
scroll off the top of the terminal.

This changes pull and merge to run "git-ls-files -u" upfront and
stop them much earlier than we currently do.

Old timers may know better and would not to try pulling again
before cleaning things up; this change adds extra overhead that
is unnecessary for them.  But this would be worth paying for to
save new people from needless confusion.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * I've seen some people on #git channel got totally confused
   after a conflicted merge at least three times, and they paste
   the diagnostics from the second and subsequent pull, assuming
   that the messages would help diagnosing the situation in any
   way (unfortunately they typically don't).  But it is not the
   user's fault not to know it.  With this what they can give us
   when asking for help will only be from the first pull.  In a
   sense, the real motivation of this patch is to make life
   easier for people who want to help these new people.

 git-merge.sh |    3 +++
 git-pull.sh  |    3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index ba42260..f43fa69 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -8,6 +8,9 @@ USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commi
 . git-sh-setup
 set_reflog_action "merge $*"
 
+test -z "$(git ls-files -u)" || 
+	die "You are in a middle of conflicted merge."
+
 LF='
 '
 
diff --git a/git-pull.sh b/git-pull.sh
index 28d0819..49130d5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -9,6 +9,9 @@ LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEA
 . git-sh-setup
 set_reflog_action "pull $*"
 
+test -z "$(git ls-files -u)" || 
+	die "You are in a middle of conflicted merge."
+
 strategy_args= no_summary= no_commit= squash=
 while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
 do

Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> After a pull that results in a conflicted merge, a new user
> often tries another "git pull" in desperation.  When the index
> is unmerged, merge backends correctly bail out without touching
> either index nor the working tree, so this does not make the
> wound any worse.

I've seen this many times too.  I don't understand why users cannot
read output messages and realize the current command failed, but
they don't.  *sigh*
 
> Old timers may know better and would not to try pulling again
> before cleaning things up; this change adds extra overhead that
> is unnecessary for them.  But this would be worth paying for to
> save new people from needless confusion.

This penalty isn't very high though; its just a single pass through
the index to look for an unmerged entry.  I think that small
penalty is worth the better error message here, and that's the guy
who just submitted patches to remove other penalties in pull and
merge talking.  :-)

-- 
Shawn.

Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> After a pull that results in a conflicted merge, a new user
>> often tries another "git pull" in desperation.  When the index
>> is unmerged, merge backends correctly bail out without touching
>> either index nor the working tree, so this does not make the
>> wound any worse.
>
> I've seen this many times too.  I don't understand why users cannot
> read output messages and realize the current command failed, but
> they don't.  *sigh*

That is not user's fault.  Tools should not make things worse
when run more than once after they failed, and we do not either,
so it is not a stupid behaviour on the user's part to do that.

We just need to make sure that it is more clear to the user that
pull after a conflicted pull is futile, which is what this patch
does.

Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge

[Andreas Ericsson]

Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
>> Junio C Hamano <junkio@cox.net> wrote:
>>> After a pull that results in a conflicted merge, a new user
>>> often tries another "git pull" in desperation.  When the index
>>> is unmerged, merge backends correctly bail out without touching
>>> either index nor the working tree, so this does not make the
>>> wound any worse.
>> I've seen this many times too.  I don't understand why users cannot
>> read output messages and realize the current command failed, but
>> they don't.  *sigh*
> 
> That is not user's fault.  Tools should not make things worse
> when run more than once after they failed, and we do not either,
> so it is not a stupid behaviour on the user's part to do that.
> 
> We just need to make sure that it is more clear to the user that
> pull after a conflicted pull is futile, which is what this patch
> does.
> 

"Pulling is futile. Nothing will be assimilated" ?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge

[Horst H. von Brand]

Andreas Ericsson <ae@op5.se> wrote:
> Junio C Hamano wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> >> Junio C Hamano <junkio@cox.net> wrote:
> >>> After a pull that results in a conflicted merge, a new user
> >>> often tries another "git pull" in desperation.  When the index
> >>> is unmerged, merge backends correctly bail out without touching
> >>> either index nor the working tree, so this does not make the
> >>> wound any worse.
> >> I've seen this many times too.  I don't understand why users cannot
> >> read output messages and realize the current command failed, but
> >> they don't.  *sigh*
> > That is not user's fault.  Tools should not make things worse
> > when run more than once after they failed, and we do not either,
> > so it is not a stupid behaviour on the user's part to do that.
> > We just need to make sure that it is more clear to the user that
> > pull after a conflicted pull is futile, which is what this patch
> > does.

> "Pulling is futile. Nothing will be assimilated" ?

:-)

Been there, done that. The messages git gives don't give a (at this point
probably panicked) newbie any clue what to try next, or how to go back.

Perhaps best would be to offer some way to undo all and then try again?

Also, if a manual fix of the merge is warranted, the message doesn't give
clear directions on what to do next. Sure, you edit the offending files to
your liking, then what? "git commit" shows a scary commit message, you
abort the edit and the merge is commited anyway.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513