Re: [RFC] Add --index to git-commit: just commit current index

From: Junio C Hamano <junkio@cox.net>
Date: Mar 16, 2007, 00:23 UTC
Message-ID: <7vird2yr1w.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <81b0412b0703150243h6a5f036aye8f115d82e11e883@mail.gmail.com>

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

> First use of new --quiet :)

You do not need to say --exit-code if you use --quiet.

Show 5 quoted lines

> Refreshing index takes a long time on big repositories with
> many files, especially if the developer was unlucky enough to
> stick to a slow filesystem or a broken OS. In this situation
> explicit git-update-index with git-commit --index will speedup
> the workflow.

Does it?

A typical workflow would go something like this:

	- repeat from here
	- "edit foo"
        - "edit bar"
        - "git diff" to help me see what I changed
        - "git add foo" as the change is sane
        - test and see breakage
        - "git diff HEAD" to help me see what I broke
        - go back to 'here' to fix it up
        - "git diff HEAD" to help me see what I changed
        - "git add foo bar" to include what I changed
        - "git commit"

If I have a large project on a filesystem with slow lstat(2), I would imagine your development is slowed anyway because you would use diff far more often than commit. I wonder if it may be a better idea to use (and extend if needed) existing 'assume unchanged' on such a system, exactly because "diff" side would take more time than final "commit", and if you do use 'assume unchanged', then it also makes --refresh a no-op.

In any case, I think your --index is a misnomer, as we do commit the current index. If the sole purpose of your patch is to omit refreshing it, then it should be named as such.