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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Nov 27, 2007, 18:12 UTC
Message-ID: <81b0412b0711271012v67f1058fj8c0de8e511543d4e@mail.gmail.com>
In-Reply-To: <7vfxyrd2x2.fsf@gitster.siamese.dyndns.org>

On 27/11/2007, Junio C Hamano <gitster@pobox.com> wrote:

> 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)".

I don't just mean to avoid lstat. I'm trying to avoid _any_ interaction with the thing unless absolutely needed.

>  * 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";

That is not what I meant to say. I do want status list in commit message. I don't want anything except git-diff-index --name-status --cached HEAD in it. No untracked files whatsoever.

And, as I said, I also just want to commit the index _exactly_ as it is. No checking for files changed after they were updated in the index intended. I think that whatever the index holds is perfect (except it's no different from HEAD) and I want commit it now.

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

Right. Is it not what happens with the patch?