From: Junio C Hamano <gitster@pobox•com>
To: Jakub Narebski <jnareb@gmail•com>
Cc: John Tapsell <johnflux@gmail•com>,
Bryan Donlan <bdonlan@gmail•com>,
Jay Soffian <jaysoffian@gmail•com>,
Git Mailing List <git@vger•kernel.org>,
Nanako Shiraishi <nanako3@lavabit•com>
Subject: Re: git merge --abort
Date: Mon, 23 Feb 2009 18:01:56 -0800 [thread overview]
Message-ID: <7vk57goanf.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <200902240253.35470.jnareb@gmail.com> (Jakub Narebski's message of "Tue, 24 Feb 2009 02:53:34 +0100")
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.
next prev parent reply other threads:[~2009-02-24 2:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 10:05 git merge --abort John Tapsell
2009-02-19 10:58 ` Junio C Hamano
2009-02-19 13:34 ` John Tapsell
2009-02-19 20:26 ` Jay Soffian
2009-02-20 4:47 ` John Tapsell
2009-02-20 5:24 ` Junio C Hamano
2009-02-20 8:13 ` John Tapsell
2009-02-20 8:33 ` Junio C Hamano
2009-02-20 8:42 ` John Tapsell
2009-02-21 7:28 ` Bryan Donlan
2009-02-21 8:34 ` Jakub Narebski
2009-02-21 9:18 ` Junio C Hamano
2009-02-21 10:18 ` Jakub Narebski
2009-02-23 12:41 ` John Tapsell
2009-02-24 1:36 ` Junio C Hamano
2009-02-24 1:53 ` Jakub Narebski
2009-02-24 2:01 ` Junio C Hamano [this message]
2009-02-24 9:51 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vk57goanf.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=bdonlan@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jaysoffian@gmail$(echo .)com \
--cc=jnareb@gmail$(echo .)com \
--cc=johnflux@gmail$(echo .)com \
--cc=nanako3@lavabit$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox