Re: Edit a rerere conflict resolution

From: Vincent van Ravesteijn <vfr@lyx.org>
Date: Mar 17, 2012, 11:03 UTC
Message-ID: <4F646F79.9090408@lyx.org>
In-Reply-To: <7vobrwh4zc.fsf@alter.siamese.dyndns.org>

Op 16-3-2012 17:42, Junio C Hamano schreef:

Show 17 quoted lines

> 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