From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 24 Feb 2009 02:01:56 GMT
Subject: Re: git merge --abort
Message-ID: <7vk57goanf.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200902240253.35470.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>> John Tapsell <johnflux@gmail.com> writes:
>> 
>> > It sounds like we have some sort of plan then.  Will Nana's patch be
>> > committed into mainline git?  Then we can add the --abort porcelain
>> 
>> I do not know what plan you are talking about, but that's not how the
>> development works.  If something is merged to 'pu', and you have a cool
>> feature you would want to take advantage of it, you can build your cool
>> feature on top of that particular topic.  If the result looks reasonable
>> they would cook for a while in 'next' for further polishing and then
>> finally go to 'mainline'.
>> 
>> I personally did not think "--keep" would need to be be part of a
>> reasonable "merge --abort" implementation, but I may have missed some
>> description of a viable design discussed on the list.
>
> My idea was that merge would do the following:
>
>   $ <save stash into MERGE_STASH or similar, no reset>
>   $ <do a merge>
>
> Then we have two possibilities:
>
>   # merge failed with conflicts
>   $ git merge --abort (would unstash MERGE_STASH and delete it)

Here "would unstash" needs to follow something else, namely, make your
work tree free of local changes.  How?  "reset --hard"?

>   # we created merge conflict
>   $ <MERGE_STASH is removed together with MERGE_HEAD>

You mean "created a merge without conflict", right?  That part is easy to
guess and understand.

In fact, when you run more than one strategies, something similar to this
already happens internally.  The C version may be harder to follow, but
you can check the last scripted version contrib/examples/git-merge.sh and
find two functions, savestate/restorestate pair, that does exactly that.

It way predates --keep patch, by the way.