Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Sun, 31 Aug 2008, Junio C Hamano wrote: >> ... >> My observation so far suggests that it would be best for me to leave the >> configuration "merge.conflictstyle" to the default "merge", and instead >> give an option to allow me to tell "git checkout -m -- $path" (which is >> also a new feature; it overwrites the $path by the result of a fresh merge >> to reproduce the conflicted state in the working tree, using the three >> stages recorded in the index) to use "diff3 -m" style, when I want to. > > Now *this* I think is a great idea! > > The reason I think it's a great idea is that it solves so many _different_ > issues (which is the mark of a really good solution): > ... > - it fixes another totally unrelated problem: incorrect merge > resolutions. I do not know if rerere often kicks in in your workflow, but occasionally I notice that I have a faulty merge recorded by it, which automatically is applied again when reproducing a merge. And it makes me deeply regret that I invented the rerere mechanism. The best solution for this issue I found so far is embarrasingly clumsy. Run "ls -tl .git/rr-cache" to find the newest one with "thisimage", make sure it is the right one, remove the directory and redo the merge. Actually, the feature of "git checkout -m -- $path" to reproduce the merge for the named path was conceived to address this "I cannot easily correct the faulty resolution that was re-applied" issue. -- 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
