Jeff King <peff@xxxxxxxx> writes:
> It might also be that the bug is earlier in list_paths(), where we
> should notice that "d" is gone and now we have entries under "d/".
We had a related discussion on "commit -i/-o tests" review thread,
where we noticed that "git commit -i foobar", when "foobar" does not
match any path in the index, silently ignore that unmatching
pathspec (but "commit -o foobar" does error out, saying "did not
match any file(s) known to git"). The important design decision we
made long time ago when we introduced partial commit ("commit -o
pathspec") is that we do not _add_ paths (that match the pathspec)
that are not tracked. We require explicit "git add" for them before
you run "git commit".
So, I suspect that list_paths() that gives "d" as a thing to add is
broken. "commit -m + ." at that point is saying "we should get the
latest contents from the working tree for all the paths in the real
index, add[*] them to the temporary index freshly read from HEAD,
and the resulting temporary index should be written out as a tree"
to create a commit, and then "the same set of contents for the paths
then should be added to the real index, so that the differences
between the tree we wrote out of the temporary index to update the
HEAD and the real index would still be the changes already in the
index before this partial commit".
Side note: here, "add" would include removing (if the working
tree file for the path is gone) or killing 'd' while adding
'd/b.txt'.
So I would understand if 'd/b.txt' is listed (because in the real
index there already is d/b.txt known), but if the directory 'd'
itself is listed, that does sound like a bug.
