"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 msysgit#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 msysgit#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 msysgit#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 msysgit#1 and msysgit#3 entries be left behind,
but it was codifying the buggy behaviour.

Signed-off-by: Junio C Hamano <[email protected]>

While identifying the commit merged to our history as "parent msysgit#2" is
technically correct, we will never say "parent msysgit#1" (as that is the tip of
our history before the merge is made), and we rarely would say "parent msysgit#3"
(which would mean the merge is an octopus), especially when responding to
a request to pull a signed tag.

Treat the most common case to merge a single commit specially, and just
say "merged tag '<tagname>'" instead.

Signed-off-by: Junio C Hamano <[email protected]>