Op 16-3-2012 17:42, Junio C Hamano schreef:
Junio C Hamano<gitster@xxxxxxxxx> writes:
Vincent van Ravesteijn<vfr@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html