From: Alex Riesen Date: Tue, 27 Nov 2007 18:12:30 GMT Subject: Re: [PATCH] builtin-commit: add --cached to operate only on index Message-ID: <81b0412b0711271012v67f1058fj8c0de8e511543d4e@mail.gmail.com> In-Reply-To: <7vfxyrd2x2.fsf@gitster.siamese.dyndns.org> On 27/11/2007, Junio C Hamano 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?