Re: [RFC/PATCH 1/2] Documentation: suggest "reset --merge" more often
- From
Stephen Boyd <bebarino@gmail.com>
- Date
- Nov 3, 2010, 09:32 UTC
- Message-ID
- <4CD12C1C.2020507@gmail.com>
- In-Reply-To
- <20101029083836.GB26290@burratino>
On 10/29/10 01:38, Jonathan Nieder wrote:
Show 26 quoted lines
> 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?