Edit a rerere conflict resolution

Edit a rerere conflict resolution

[Vincent van Ravesteijn]

Hi 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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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?

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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".

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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"?

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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

Re: Edit a rerere conflict resolution

[Jakub Narebski]

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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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.

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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.

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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.

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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

Re: Edit a rerere conflict resolution

[Junio C Hamano]

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.

Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn]

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