Vincent van Ravesteijn <vfr@xxxxxxx> writes: > Op 12-3-2012 21:01, Junio C Hamano schreef: > ... >> I haven't find it necessary in practice, as the re-fix for me >> typically would go like this: >> >> $ git merge other-branch >> ... rerere kicks in; eyeball the results >> ... ah, my earlier resolution is no longer correct >> $ edit $the_path >> ... test the result of manual edit in the context of the merged whole >> ... and be satisified >> $ git rerere forget $the_path >> $ git add $the_path >> $ git commit >> ... rerere records the updated resolution >> >> What scenario do you have in mind that you would need to re-fix more >> resolution than you need? > > Context: > I have a number of topic branches that modify the fileformat version > and also the fileformat conversion routines. When merging all those > branches into an integration branch (like you regenerate pu),... > ... > But well, if the experts don't feel the need, I will search further to > implement something that you do think is useful ;). "It is not useful for experts" is not a reason to reject a feature. As long as it is useful for general audience, it is OK to have it; the experts can just choose not to use it. I have experienced the same "Ah, no longer that earlier resolution is a good one" or "Oops, that earlier resolution was busted" when reintegrating 'pu', just like you do in your integration branch, and the way I illustrated above is only a small part of the larger workflow. I run the automated integration the usual way, rewind the HEAD to the problematic commit, run the above procedure to update the rerere database, and then re-run the automated integration. That way, I have a chance to _test_ the updated entry in the rerere databae in isolation, without the other noise that comes on top of the problematic merge in 'pu'. The problem I have with "rerere edit" is it is an offline process, and to validate that the update is correct, I would have to have the problematic merge in my working tree once _anyway_. And at that point, updating the target file in the working tree and recording the updated resolution using the usual "git rerere" feels a more natural way to do so, and more importantly, it is a more convenient way to do the "update and validate". On the other hand, "rerere edit" is a more convenient way to "update but not validate the result". So I do not think the distinction is "expert" vs "others". -- 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