Re: [PATCH] builtin-commit: add --cached to operate only on index

"Alex Riesen" <raa.lkml@gmail.com> writes:

I am sympathetic to the _cause_, but I do not think the option --cached is a good match for this change. As Hannes points out, as-is commit is the default, and --cached to other commands mean "work only with index not work tree", not "short-circuit for systems with slow lstat(3)".

Obviously we cannot short-circuit checking for modified or removed paths when "git-commit -a" is run, but it is plausible that people may still want to trade run_status output with interactive speed even when doing "git-commit -a".

On the other hand, when we know we do not have to _show_ the list of staged/modified/untracked files (i.e. we already have the commit log message via -m, -F, or -C and we were told not to invoke editor), we do not have to call run_status(), only to discard its output. In such a case, we are calling it only to see if we have something committable, and we should be able to optimize THAT without being told by the user with this new option. Incidentally I just checked the scripted version; it does not do this optimization (git-commit.sh, ll. 514-517). The C rewrite in 'next' does not have it in either (builtin-commit.c, ll. 387-390). When no_edit is in effect, I think these two places can be replaced with an equivalent of "diff-index --cached HEAD --" (which should not hit the work tree at all) to see if there is anything to be committed. For initial commit the check would obviously be "is the index empty?" instead.

So in short:

 * The option "--cached" is a wrong thing to have the user say and is
   not what you want anyway. You want "no status list in the commit log
   template";

 * Skip run_status() and replace with "diff-index --cached HEAD" (or "is
   the index empty?") when the user instructs so;

 * In addition, the same optimization should apply when we know we do
   not use the exact run_status() output.