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

mergetool's test for rerere seems to be incorrect

From
ECErik Carstensen <mandolaerik@gmail.com>
Date
Nov 14, 2011, 20:26 UTC
Message-ID
<CALeBojRuZP3dbEs=rPX1E5p=oD43_yJO_Ec=Pe2SRpjG-rH2Vg@mail.gmail.com>
Hi,

Occasionally when I use mergetool in a conflicted state ('git status' says it's a conflict), nothing happens.

By bisection I found that bb0a484e985ef8d9bbbbeb172b1fcf4982634bef is the offending commit.

I have rerere.enabled unset, but I did find an empty file MERGE_RR in .git/, which explains my problem: mergetool chooses to use rerere because it finds the MERGE_RR file, but rerere just exits silently because it's not enabled.

Wouldn't it make sense to restrict mergetool's use of rerere to the case when rerere.enabled is set?

I'm also a little confused about why the MERGE_RR file appeared there in the first place. I can see that empty MERGE_RR files, with different timestamps, have ended up in various other of my git repositories as well. I never used rerere in these repos, and the only non-git tools I have used for version control are stgit and kdiff3.

Erik
Message 1 of 1 in “mergetool's test for rerere seems to be incorrect”
  1. Erik CarstensenNov 14, 2011

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.