threads / discuss / 29926
Subject: Edit a rerere conflict resolution
Vincent van RavesteijnHi all,
Would it be a useful addition to have a command 'git rerere edit <path> <commit>' ?
This would allow the user to edit the conflict resolution which was used in a certain commit (merge, rebase.. ).
Now I tend to grep in the .git/rr-cache directory, because I don't want to do 'git rerere forget' as this would require me to refix more resolution than needed.
Vincent
Junio C HamanoRe: Edit a rerere conflict resolution
Vincent van Ravesteijn <vfr@lyx.org> writes:
> Would it be a useful addition to have a command 'git rerere edit > <path> <commit>' ? > > This would allow the user to edit the conflict resolution which was > used in a certain commit (merge, rebase.. ). > > Now I tend to grep in the .git/rr-cache directory, because I don't > want to do 'git rerere forget' as this would require me to refix more > resolution than needed.
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 resolutionWhat scenario do you have in mind that you would need to re-fix more resolution than you need?
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 12-3-2012 21:01, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> writes: > >> Would it be a useful addition to have a command 'git rerere edit >> <path> <commit>' ? >> >> This would allow the user to edit the conflict resolution which was >> used in a certain commit (merge, rebase.. ). >> >> Now I tend to grep in the .git/rr-cache directory, because I don't >> want to do 'git rerere forget' as this would require me to refix more >> resolution than needed. > 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), there are a lot of annoying merge conflicts in these two files. From one of your scripts I took some code to automatically commit the merge resolution (here I go wrong, I probably neglected the reason that git doesn't allow to autocommit (yet)).
I can of course disable the autocommit, run the merge sequence again, commit the correct merge resolutions, and modify the merge resolution that went wrong.
But somehow I felt I was missing the 'git rerere edit' command. Aren't the recorded merge resolutions essentially part of the codebase, though in practice they remain rather anonymous temporary thingies.
But well, if the experts don't feel the need, I will search further to implement something that you do think is useful ;).
Vincent
Junio C HamanoRe: Edit a rerere conflict resolution
Vincent van Ravesteijn <vfr@lyx.org> 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".
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 12-3-2012 21:34, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> 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?
Here I was mistaken. I assumed that you could run 'git rerere forget' always and thus removing all conflict resolutions for a certain path. Now I see that the documentation clearly says "current conflict in <pathspec>"
> 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".
This last part probably makes the difference indeed. In my case the merge resolution was very very easy (the conflicting hunks have fileformat version numbers), but it is a bit annoying and it requires some 'vim'-skills to redo the merge conflict just to correct a newline somewhere, or a missing ','.
As I wrote, the merge resolutions in my case were very easy (logically), but just annoying (motorically). These could even be resolved by some merge-conflict hook.
Examples: - for this file we know the conflict always has to be resolved by adding the oldest hunk before the newest hunk. For example, new file formats will be added sequentially to a file. - for this file we can resolve it anyway we want. For example, a release notes file which just enumerates all changes in random order.
Anyway, has anyone thought about such a hook ?
Vincent
Junio C HamanoRe: Edit a rerere conflict resolution
Vincent van Ravesteijn <vfr@lyx.org> writes:
>> 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". > > This last part probably makes the difference indeed. In my case the > merge resolution was very very easy (the conflicting hunks have > fileformat version numbers), but it is a bit annoying and it requires > some 'vim'-skills to redo the merge conflict just to correct a newline > somewhere, or a missing ','.
Now you confused me. How do you envision your "rerere edit" not to require "vim-skills" that is needed to navigate to the problematic line to correct a newline or comma? To put it another way, how much more "vim-skills" is needed to fix the conflict in the real file, than "rerere edit"?
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 12-3-2012 22:34, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> writes: > >>> 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". >> This last part probably makes the difference indeed. In my case the >> merge resolution was very very easy (the conflicting hunks have >> fileformat version numbers), but it is a bit annoying and it requires >> some 'vim'-skills to redo the merge conflict just to correct a newline >> somewhere, or a missing ','. > Now you confused me. How do you envision your "rerere edit" not to > require "vim-skills" that is needed to navigate to the problematic > line to correct a newline or comma? To put it another way, how much > more "vim-skills" is needed to fix the conflict in the real file, > than "rerere edit"?
Well, I often paste lines in the line below the line I wanted to paste to, in python files I often get whitespace errors, when cutting line I always have to guess how many lines there are... anyway, I don't feel very comfortable.
Editing the postimage by just inserting an enter seems easier.
Vincent
Jakub NarebskiRe: Edit a rerere conflict resolution
Vincent van Ravesteijn <vfr@lyx.org> writes:
> As I wrote, the merge resolutions in my case were very easy > (logically), but just annoying (motorically). > These could even be resolved by some merge-conflict hook. > > Examples: > - for this file we know the conflict always has to be resolved by > adding the oldest hunk before the newest hunk. For example, new file > formats will be added sequentially to a file. > - for this file we can resolve it anyway we want. For example, a > release notes file which just enumerates all changes in random order. > > Anyway, has anyone thought about such a hook ?
Isn't it what custom merge drivers (for file-level merge) are for? I think there can be found somewhere merge driver for changelog...
You can also use custom merge strategies, but that is probably overkill, and I am not sure that it would work (adding new strategy) without modifying git.
-- Jakub Narebski
Junio C HamanoRe: Edit a rerere conflict resolution
Jakub Narebski <jnareb@gmail.com> writes:
> You can also use custom merge strategies, but that is probably > overkill, and I am not sure that it would work (adding new strategy) > without modifying git.
Merge strategies are primarily for people who want to customize the way how the final shape of the resulting tree is determined. Even if you go that route, you would need to write and use your own merge driver anyway in order to tweak the way how the file-level three-way merge is performed.
So it is not just an overkill, but it is entirely pointless, as it buys nothing to use a custom merge strategy in this case.
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 12-3-2012 21:01, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> writes: > >> Would it be a useful addition to have a command 'git rerere edit >> <path> <commit>' ? >> >> This would allow the user to edit the conflict resolution which was >> used in a certain commit (merge, rebase.. ). >> >> Now I tend to grep in the .git/rr-cache directory, because I don't >> want to do 'git rerere forget' as this would require me to refix more >> resolution than needed. > 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 >
This doesn't really work for me:
$ git merge other-branch
Auto-merging <path>
CONFLICT (content): Merge conflicts in <path>
Resolved '<path>' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result. $ git rerere status
$ git rerere forget <path>
error: no remembered resolution for <path> $ edit <path>
$ git commit -a -m "fix"
... no sign of rerere doing something.Why is this different from what you describe above, and how can I modify the recorded resolution ?
Vincent
Junio C HamanoRe: Edit a rerere conflict resolution
Vincent van Ravesteijn <vfr@lyx.org> 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 >> > This doesn't really work for me: > > $ git merge other-branch > Auto-merging <path> > CONFLICT (content): Merge conflicts in <path> > Resolved '<path>' using previous resolution. > Automatic merge failed; fix conflicts and then commit the result. > > $ git rerere status > $ git rerere forget <path> > error: no remembered resolution for <path> > > $ edit <path> > $ git commit -a -m "fix" > ... no sign of rerere doing something. > > Why is this different from what you describe above, and how can I > modify the recorded resolution ?
Do you have rerere.autoupdate set by any chance? If so, don't. At least when you are trying to purge the broken rerere entry.
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 16-3-2012 17:01, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> 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 >>> >> This doesn't really work for me: >> >> $ git merge other-branch >> Auto-merging<path> >> CONFLICT (content): Merge conflicts in<path> >> Resolved '<path>' using previous resolution. >> Automatic merge failed; fix conflicts and then commit the result. >> >> $ git rerere status >> $ git rerere forget<path> >> error: no remembered resolution for<path> >> >> $ edit<path> >> $ git commit -a -m "fix" >> ... no sign of rerere doing something. >> >> Why is this different from what you describe above, and how can I >> modify the recorded resolution ? > Do you have rerere.autoupdate set by any chance? If so, don't. At least > when you are trying to purge the broken rerere entry.
No, I turned rerere.autoupdate off. Proven in the above by the line "Resolved... " instead of "Staged...".
Vincent
Junio C HamanoRe: Edit a rerere conflict resolution
Vincent van Ravesteijn <vfr@lyx.org> writes:
> No, I turned rerere.autoupdate off. Proven in the above by the line > "Resolved... " instead of "Staged...".
Yeah, actually I just tried and the procedure works with or without autoupdate for me.
So there is something different between our setup (or the nature of the conflict), but I do not know what it is offhand.
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 16-3-2012 17:20, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> writes: > >> No, I turned rerere.autoupdate off. Proven in the above by the line >> "Resolved... " instead of "Staged...". > Yeah, actually I just tried and the procedure works with or without > autoupdate for me. > > So there is something different between our setup (or the nature of the > conflict), but I do not know what it is offhand.
Hmm.. The behaviour seems to be different for the "official Git for Windows 1.7.9" as for the version I compiled myself with MSVC.
First, the sha1s in the rerere cache differ. Second, when using the MSVC version to generate the preimages and resolutions, I can use both version to forget the resolution again.
Maybe another EOL-style problem ?
Vincent
Junio C HamanoRe: Edit a rerere conflict resolution
Junio C Hamano <gitster@pobox.com> writes:
> Vincent van Ravesteijn <vfr@lyx.org> writes: > >> No, I turned rerere.autoupdate off. Proven in the above by the line >> "Resolved... " instead of "Staged...". > > Yeah, actually I just tried and the procedure works with or without > autoupdate for me. > > So there is something different between our setup (or the nature of the > conflict), but I do not know what it is offhand.
The last message from me on this topic for now as I'll be a bit too busy, but a wild guess/hunch: grep NEEDSWORK near rerere.c::handle_cache()?
I suspect that we might need to also update this function to handle "both sides added, but differently" case, as we do so in check_one_conflict() these days, but for Vincent's particular case that shouldn't be the cause.
Vincent van RavesteijnRe: Edit a rerere conflict resolution
Op 16-3-2012 17:42, Junio C Hamano schreef:
> Junio C Hamano<gitster@pobox.com> writes: > >> Vincent van Ravesteijn<vfr@lyx.org> writes: >> >>> No, I turned rerere.autoupdate off. Proven in the above by the line >>> "Resolved... " instead of "Staged...". >> Yeah, actually I just tried and the procedure works with or without >> autoupdate for me. >> >> So there is something different between our setup (or the nature of the >> conflict), but I do not know what it is offhand. > The last message from me on this topic for now as I'll be a bit too busy, > but a wild guess/hunch: grep NEEDSWORK near rerere.c::handle_cache()? > > I suspect that we might need to also update this function to handle "both > sides added, but differently" case, as we do so in check_one_conflict() > these days, but for Vincent's particular case that shouldn't be the cause.
Yes, the problem is with the renormalization (of eol style) in handle_cache.
When I've set 'core.autocrlf = true', 'git rerere forget' fails because it does not renormalize. The sha1 of the merge conflict is computed with 'crlf' line-ending in handle_file, but with 'lf' line-ending in handle_cache.
Even if I change the code to do the renormalization, it fails. In 'renormalize_buffer; , the buffer is converted to 'crlf' by 'convert_to_working_tree_internal', but at the end it is converted back to 'lf' by 'convert_to_git'
I don't understand the logic of 'convert_to_git' and 'crlf_to_git' well enough to pinpoint what is going wrong exactly.
Vincent