git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git merge --abort

From
Jakub Narebski <jnareb@gmail.com>
Date
Feb 24, 2009, 09:51 UTC
Message-ID
<200902241051.42800.jnareb@gmail.com>
In-Reply-To
<7vk57goanf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote::
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>> 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.

First, a description of state: here we assume that you have changes to tracked files in working area that are neither in HEAD, nor in index, and that you can have changes in index which are neither in HEAD nor in working area.

If HEAD == index == working area then stashing is not necessary.
Show 12 quoted lines
>> 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"?
Yes. "git merge --abort" would be equivalent to
  $ git reset --hard ORIG_HEAD
  $ git stash pop --ref=MERGE_STASH
  $ rm $GIT_DIR/MERGE_STASH
Show 6 quoted lines
> 
>>   # 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.
Yes. I meant here: "created merge _commit_" (not "conflict").
Show 7 quoted lines
> 
> 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.

Well, we have "git reset --merge ORIG_HEAD" which from what I understand does at least part of "git merge --abort", but I am not sure if it covers all cases (like dirty index in addition to dirty tree).

-- 
Jakub Narebski
Poland
Previous: Junio C Hamano
Message 18 of 18 in “git merge --abort”
  1. John TapsellFeb 19, 2009
  2. Junio C HamanoFeb 19, 2009
  3. John TapsellFeb 19, 2009
  4. Jay SoffianFeb 19, 2009
  5. John TapsellFeb 20, 2009
  6. Junio C HamanoFeb 20, 2009
  7. John TapsellFeb 20, 2009
  8. Junio C HamanoFeb 20, 2009
  9. John TapsellFeb 20, 2009
  10. Bryan DonlanFeb 21, 2009
  11. Jakub NarebskiFeb 21, 2009
  12. Junio C HamanoFeb 21, 2009
  13. Jakub NarebskiFeb 21, 2009
  14. John TapsellFeb 23, 2009
  15. Junio C HamanoFeb 24, 2009
  16. Jakub NarebskiFeb 24, 2009
  17. Junio C HamanoFeb 24, 2009
  18. Jakub NarebskiFeb 24, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.