Re: Edit a rerere conflict resolution
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 12, 2012, 20:34 UTC
- Message-ID
- <7vd38hr22e.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4F5E5A77.1070605@lyx.org>
Vincent van Ravesteijn <vfr@lyx.org> writes:
Show 26 quoted lines
> 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".