Re: git-commit: if run with <file> arguments, include files removed through git rm

[Junio C Hamano <gitster@pobox.com>]

Gerrit Pape <pape@smarden.org> writes:

> This patch lets it additionally use git ls-tree to look for the files in
> the HEAD tree, but I guess there's a smarter way to fix this.

You raised a good issue, but this also needs other parts of the
system to be adjusted.

>  		commit_only=`git ls-files --error-unmatch -- "$@"` || exit
> +		commit_only="$commit_only "`git ls-tree -r --name-only HEAD -- "$@"` || exit

The arguments to git-commit are *NOT* "<file> arguments".  They
are file patterns and 'ls-files --error-unmatch -- "$@"' is
there to allow you to say something like:

	$ git commit 'p*/*.c'

Alas, ls-tree does not grok globbing yet.  Try this in git.git
repository (surrounding quotes are essential):

	$ git ls-files 'p*/*.c'
        $ git ls-tree -r HEAD 'p*/*.c'

Currently we have two semantics of "pathspec", and unifying
these semantics is one of the items with somewhat higher
priority on my TODO list for the 1.5.4 cycle (I started looking
at diff-tree and log last night):

 * ls-files, diff-files, diff-index and grep understand both
   "leading directory prefix" and "glob pattern"; you can say:

	$ git ls-files -- arm/ 'p*/*.c'
	$ git grep int -- arm/ 'p*/*.c'

   and they do what you would expect them to do.

 * diff-tree, log family and ls-tree understand only "leading
   directory prefix" and not "glob pattern"; you cannot say:

	$ git log -- 'p*/*.c'

So your patch is a definite improvement for normal ("non
pattern" but "exact pathname") case, but needs the updates to
pathspec semantics to be the correct fix.