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

Re: Status of conflicted files resolved with rerere

From
Avery Pennarun <apenwarr@gmail.com>
Date
Aug 12, 2010, 21:36 UTC
Message-ID
<AANLkTi=tVV5gL2b2LfXALXahzabJXzVjB5z9-OSztOMJ@mail.gmail.com>
In-Reply-To
<20100812212828.GA17825@jpl.local>

On Thu, Aug 12, 2010 at 5:28 PM, Magnus Bäck <magnus.back@sonyericsson.com> wrote:

Show 10 quoted lines
> I played around with git rerere today and was surprised by the results.
> When a conflict has been resolved automatically by rerere, the file
> isn't added to the index like other files are where Git just used one of
> the regular merge resolution algorithms. What's worse, if git mergetool
> is invoked -- which is what I normally do when git merge needs help --
> it has no idea that the file actually has been merged already, and
> launches the merge tool with the three files involved in the merge. If
> the user hasn't been paying attention to each line of the git merge
> output (stating the files who were automatically resolved) it's easy to
> trash rerere's work.

The motivation behind the current behaviour, as I understand it, is that rerere speeds things up, but you don't necessarily want to trust that it has resolved your merge conflicts correctly. After all, they were unarguably *conflicts*, not just normal merge results, so you can't quite trust them.

That said, I've never had a problem where rerere did the wrong thing for me. Maybe there could be an option to override it.

Anyway, I never use a mergetool, so like you suspected, this has never been a major problem for me.

It sounds like the real problem here though it the mergetool stuff. Why is it disregarding all the automated merging that git has done and starting over from scratch? If git, in its infinite cleverness, has resolved *some* parts of the file but not others, wouldn't we want it to keep those resolutions? It sounds like mergetool is actually making things *more* work instead of less.

Is there some way to teach the mergetool stuff to be smarter? At the very least, having it auto-skip files that have no *remaining* conflicts might be a good idea.

Have fun,
Avery
Previous: Magnus BäckNext: Jay Soffian
Message 2 of 16 in “Status of conflicted files resolved with rerere”
  1. Magnus BäckAug 12, 2010
  2. Avery PennarunAug 12, 2010
  3. Jay SoffianAug 13, 2010
  4. David AguilarAug 15, 2010
  5. Junio C HamanoAug 15, 2010
  6. Magnus BäckAug 15, 2010
  7. mergetool: Skip autoresolved pathsDavid Aguilar, Aug 17, 2010
  8. Thomas RastAug 19, 2010
  9. David AguilarAug 20, 2010
  10. Charles BaileyAug 20, 2010
  11. Jonathan NiederAug 20, 2010
  12. mergetool: Remove explicit references to /dev/ttyCharles Bailey, Aug 20, 2010
  13. Jonathan NiederAug 20, 2010
  14. Charles BaileyAug 20, 2010
  15. Jonathan NiederAug 20, 2010
  16. mergetool: Remove explicit references to /dev/ttyCharles Bailey, Aug 20, 2010

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.