rerere: never renormalize
commitff8ba59e7b015ba96d6a3271000f16aa71dc4a6f
authorJonathan Nieder <jrnieder@gmail.com>
Thu, 5 Aug 2010 11:30:26 +0000 (5 06:30 -0500)
committerJunio C Hamano <gitster@pobox.com>
Fri, 6 Aug 2010 16:20:02 +0000 (6 09:20 -0700)
tree75ee23a0b6b1e59b38b79588354d4a80aea5bfd3
parent672d1b789bc041be6aa18dcce066e6b556d6b787
rerere: never renormalize

plain rerere performs three tasks; let us consider how the new
merge.renormalize option should apply to each.

After an unsuccessful merge, rerere records conflict hunks from the
work tree under .git/rr-cache.  If the merge was performed with
merge.renormalize enabled, both sides of the conflict hunk use the
current work tree’s end-of-line and smudge rules; there is not really
much of a choice.

After a successful manual resolution, rerere records the postimage.
Here, also, the file will be in the current work tree’s canonical
format and there is not much to do about it.

When encountering that conflict again, merge looks up the preimage
and postimage using the conflict hunk as a key and runs a three-way
merge to apply that resolution to the work tree.  Since the conflict
hunk used the current work tree’s canonical format, chances are the
version in the work tree, the preimage, and the postimage will, too.
In fact using the merge.renormalize machinery is exactly the wrong
thing to do, since its result has been run through convert_to_git
and therefore is not suitable for writing to the work tree.

The only affected caller is "git merge".

NEEDSWORK: lacks test

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere.c