merge-recursive: When we detect we can skip an update, actually skip it
commitb2c8c0a762745768e8fb249949801c1aed8f7c1d
authorElijah Newren <newren@gmail.com>
Tue, 1 Mar 2011 01:08:52 +0000 (28 18:08 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 2 Mar 2011 19:55:06 +0000 (2 11:55 -0800)
treefad1ea93798593bab3350b09ff2ae3ce7aaebaed
parenteeba0d1760d6922e7d6ee838b8684e87a6c0c273
merge-recursive: When we detect we can skip an update, actually skip it

In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20),
there was code that checked for whether we could skip updating a file in
the working directory, based on whether the merged version matched the
current working copy.  Due to the desire to handle directory/file conflicts
that were resolvable, that commit deferred content merging by first
updating the index with the unmerged entries and then moving the actual
merging (along with the skip-the-content-update check) to another function
that ran later in the merge process.  As part moving the content merging
code, a bug was introduced such that although the message about skipping
the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently
high), the file would be unconditionally updated in the working copy
anyway.

When we detect that the file does not need to be updated in the working
copy, update the index appropriately and then return early before updating
the working copy.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive.c
t/t6022-merge-rename.sh