Re: Edit a rerere conflict resolution

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

Junio C Hamano[off-list ref]  writes:

quoted

Vincent van Ravesteijn[off-list ref]  writes:

quoted

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