Quoting Johannes Sixt <j6t@xxxxxxxx> > On Sonntag, 22. November 2009, Junio C Hamano wrote: > [snip] >> * Then the user tells rerere that "this is the corrected resolution", >> perhaps >> >> $ git rerere update Documentation/git-commit.txt >> >> This will >> >> - Internally recompute the original conflicted state, i.e. run >> "checkout --conflict=merge Documentation/git-commit.txt" in-core; >> >> - feed it to rerere.c::handle_file() to learn the conflict hash; >> >> - read the user's updated resolution from the work tree, and update >> "postimage" with it. >> >> ... >> >> The "forget" subcommand may be useful, but the real implementation should >> be the first half of the "update", iow, recreate conflict in-core in order >> to compute the conflict hash, and drop existing "postimage", without >> replacing it from the work tree. We should leave it up to the user using >> "checkout --conflict" to reproduce the conflict in the work tree. > > Thank you for your elaborate feedback and the guidelines about how to move > forward. > > I actually think that 'forget' should be the primary subcommand. Because after > the postimage was purged, the next implicit or explicit 'git rerere' will > record the resolution anyway. I'll see what I can do. > > -- Hannes I think 'forget' should be the primary interface to this new feature too. If I mistakenly recorded an incorrect merge in the past and I'm trying to do a better job this time, I wouldn't be confident enough to be able to say 'update' to mark the attempt I made this time, and it may take more than one attempts for me to reach a good result. Running 'forget' once will let me retry until I run 'rerere' again. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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