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

Re: MERGE_RR droppings

From
Phil Hord <phil.hord@gmail.com>
Date
Jun 18, 2012, 22:41 UTC
Message-ID
<CABURp0os2no40BW0P-biG_fXyi7MHRcLLYWmCbLTdBv1o1OXcg@mail.gmail.com>
In-Reply-To
<CABURp0omkVoLrz29GeOjjoZOpN238Rm6Nu5aOKQyVxFVnPihsw@mail.gmail.com>

git mergetool decides to use rerere-remaining based on the existence of the .git/MERGE_RR file:

    if test -e "$GIT_DIR/MERGE_RR"
    then
        files=$(git rerere remaining)
    else
        files=$(git ls-files -u | sed -e 's/^[^ ]*      //' | sort -u)
    fi

But when I disabled rerere, I still had MERGE_RR files left over in my .git directory. This causes git-mergetool to do the wrong thing.

I do not know if the correct fix for this is to check rerere.enabled instead.

Is MERGE_RR leaking somewhere it should have been cleaned up? I often see leftover MERGE_RR files even though I am certain the project is not in the middle of a merge.

Is this a bad semaphore to check? I do not see it being used this way anywhere else.

Phil
Next: Junio C Hamano
Message 1 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.