git-commit: Allow partial commit of file removal.
commit64586e75af3c84844b80652575a8b63a9612b24a
authorJunio C Hamano <gitster@pobox.com>
Wed, 12 Sep 2007 23:04:22 +0000 (12 16:04 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 18 Sep 2007 06:57:35 +0000 (17 23:57 -0700)
treedf1f5a68f6390c4b69175e30abeb97d6bfd9970a
parenta017f27dcbe6b4f9c8760ccc8a7e248c680b6a23
git-commit: Allow partial commit of file removal.

When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns.  When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile").  This detection however does not work
well when the path has already been removed from the index.

If you drop a path from the index and try to commit that
partially, i.e.

$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING

the command complains because git does not know anything about
COPYING anymore.

This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.

When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.

Of course, there is no reason to use "git rm" and git-aware
people have long time done:

$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING

which works just fine.  But this caused a constant confusion.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-ls-files.c
git-commit.sh
t/t7501-commit.sh