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

Re: MERGE_RR droppings

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 25, 2012, 19:04 UTC
Message-ID
<7vwr2vfc1c.fsf@alter.siamese.dyndns.org>
In-Reply-To
<7v8vfk2pby.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
> Phil Hord <phil.hord@gmail.com> writes:
>
>> git mergetool decides to use rerere-remaining based on the existence
>> of the .git/MERGE_RR file:
>>
>>     if test -e "$GIT_DIR/MERGE_RR"
>
> This is correct, I would probably write it with "test -f" if I were
> writing this line today, though.  After you commit to conclude the
> merge, the MERGE_RR marker should disappear.  Isn't it happening for
> you?

Oops. It actually does not happen for _me_. An empty MERGE_RR is left in the working tree after rerere has dealt with the conflicts. There seems to be only three codepaths that explicitly remove MERGE_RR that is stale:

 - (obviously) "rerere clear"
 - "git reset"
 - "git checkout otherbranch"

Perhaps mergetool should consider a missing MERGE_RR and an empty one the same way?

Previous: Phil HordNext: David Aguilar
Message 4 of 11 in “Re: MERGE_RR droppings”
  1. Phil HordJun 18, 2012
  2. Junio C HamanoJun 18, 2012
  3. Phil HordJun 25, 2012
  4. Junio C HamanoJun 25, 2012
  5. David AguilarJun 26, 2012
  6. Junio C HamanoJun 26, 2012
  7. Junio C HamanoJun 26, 2012
  8. Phil HordJun 26, 2012
  9. David AguilarJul 1, 2012
  10. Junio C HamanoJul 2, 2012
  11. Phil HordJul 2, 2012

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.