]> git.ipfire.org Git - thirdparty/git.git/commit - builtin/add.c
Fix "add -u" that sometimes fails to resolve unmerged paths
authorJunio C Hamano <gitster@pobox.com>
Thu, 21 Apr 2011 01:11:19 +0000 (18:11 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sun, 24 Apr 2011 06:13:28 +0000 (23:13 -0700)
commit75973b2cb58bf2b3038c5c214fc0a1b96d6868fe
tree0e87eaf82131220184af67f945738157d706c58d
parent095ce9538b738db28d5e9a6e05d94c7e3f55f39d
Fix "add -u" that sometimes fails to resolve unmerged paths

"git add -u" updates the index with the updated contents from the working
tree by internally running "diff-files" to grab the set of paths that are
different from the index. Then it updates the index entries for the paths
that are modified in the working tree, and deletes the index entries for
the paths that are deleted in the working tree.

It ignored the output from the diff-files that indicated that a path is
unmerged.  For these paths, it instead relied on the fact that an unmerged
path is followed by the result of comparison between stage #2 (ours) and
the working tree, and used that to update or delete such a path when it is
used to record the resolution of a conflict.

As the result, when a path did not have stage #2 (e.g. "we deleted while
the other side added"), these unmerged stages were left behind, instead of
recording what the user resolved in the working tree.

Since we recently fixed "diff-files" to indicate if the corresponding path
exists on the working tree for an unmerged path, we do not have to rely on
the comparison with stage #2 anymore. We can instead tell the diff-files
not to compare with higher stages, and use the unmerged output to update
the index to reflect the state of the working tree.

The changes to the test vector in t2200 illustrates the nature of the bug
and the fix.  The test expected stage #1 and #3 entries be left behind,
but it was codifying the buggy behaviour.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/add.c
t/t2200-add-update.sh