From: Stephen Boyd <bebarino@gmail.com>
Date: Wed, 03 Nov 2010 09:32:12 GMT
Subject: Re: [RFC/PATCH 1/2] Documentation: suggest "reset --merge" more often
Message-ID: <4CD12C1C.2020507@gmail.com>
In-Reply-To: <20101029083836.GB26290@burratino>

On 10/29/10 01:38, Jonathan Nieder wrote:
> With its new semantics, "git reset --merge" is more suitable for
> undoing a failed merge than "git reset --hard" is.  It is especially
> nice if you forget that you are in a merge and make a change or two:
> 
>   git merge something-complicated
>   ... notice conflicts, walk away ...
>   vi foo.c
>   git commit; # fails because the index has unmerged entries
>   git reset --merge
> 
> The modern (post-1.7.0) semantics of git reset --merge ensure that
> the changes to foo.c will be preserved by this sequence of commands,
> unless foo.c was one of the files with conflicts.
> 
> So in the spirit of ed4a6baa (Documentation: suggest `reset --merge`
> in How Merge Works section, 2010-01-23), recommend it in place of
> "reset --hard".
> 
> One caveat: for habitual adders-to-index, "git reset --merge" is
> no better than "git reset --hard" (though still no worse).
> 
>   vi foo.c
>   git add -u
>   git diff --cached --check; # fails because conflict markers are present
>   git reset --merge; # equivalent to git reset --hard
> 

Would it also be a good idea to fill in the hint in git status for the
in_merge case with similar information?