Re: Edit a rerere conflict resolution

[Vincent van Ravesteijn <vfr@lyx.org>]

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