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. Would it make sense for git merge to add rerere'd files (where all hunks were recognized and resolved) to the index automatically? That would make it possible for the user to run git mergetool without reading every single line of output from previous commands just to figure out which files should be added to the index straight off and which files require merging. For users resolving conflicts by editing the file and fiddling with the <<<<<<<<< marks etc such a change wouldn't make that big difference, but for mergetool users it seems like a quite useful improvement. Or is there something I'm failing to grasp here? This is on Git 1.7.0.3 by the way. -- Magnus Bäck Opinions are my own and do not necessarily SW Configuration Manager represent the ones of my employer, etc. Sony Ericsson -- 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