From: David Aguilar Date: Sun, 15 Aug 2010 02:24:43 GMT Subject: Re: Status of conflicted files resolved with rerere Message-ID: In-Reply-To: On Aug 12, 2010, at 2:36 PM, Avery Pennarun wrote: > On Thu, Aug 12, 2010 at 5:28 PM, Magnus Bäck > 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. > [...] > 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 Right, that would be a great enhancement. The problem is that mergetool always uses local, remote, and base. It uses the unmerged flag in the index when deciding which files to consider. Here's what we'd need in order to improve rerere and mergetool interaction: the ability to answer the question, "has this file been rerere merged?" Once we have that then we can make mergetool skip these files by default. We would also need a command line flag to override the behaviour. Perhaps a naive grep for merge markers in the worktree file would suffice? Heuristics have gone a long way in git so doing something like that wouldn't seem too atrocious. It'd also have the benefit that mergetool would skip files merged by $EDITOR. If anyone has any tips I'm all ears. Does this seem reasonable, and if so, what would be a good name for the command line flag to get the existing behavior? My gut feeling is that it shouldn't have a corresponding config variable. Cheers, -- David