On Thu, Aug 12, 2010 at 5:28 PM, Magnus Bäck <magnus.back@xxxxxxxxxxxxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html