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

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

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

>> Doesn't git-commit operate only on the index, unless you pass it extra
>> arguments?
>
> It doesn't
>
>> What am I missing?
>
> run_status and check for changed files

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.