summaryrefslogtreecommitdiff
path: root/builtin/checkout.c
diff options
context:
space:
mode:
authorJonathan Nieder <jrnieder@gmail.com>2010-08-05 11:30:26 (GMT)
committerJunio C Hamano <gitster@pobox.com>2010-08-06 16:20:02 (GMT)
commitff8ba59e7b015ba96d6a3271000f16aa71dc4a6f (patch)
tree75ee23a0b6b1e59b38b79588354d4a80aea5bfd3 /builtin/checkout.c
parent672d1b789bc041be6aa18dcce066e6b556d6b787 (diff)
downloadgit-ff8ba59e7b015ba96d6a3271000f16aa71dc4a6f.zip
git-ff8ba59e7b015ba96d6a3271000f16aa71dc4a6f.tar.gz
git-ff8ba59e7b015ba96d6a3271000f16aa71dc4a6f.tar.bz2
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>
Diffstat (limited to 'builtin/checkout.c')
0 files changed, 0 insertions, 0 deletions