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.
Giving either --all, -o, or -i silently turns --index off (these have to
refresh index).
In case of unmodified index no status message is shown, for all
the same reasons: it takes too long.
---
First use of new --quiet :)
git-commit.sh | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
"Alex Riesen" [off-list ref] writes:
First use of new --quiet :)
You do not need to say --exit-code if you use --quiet.
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.
On 3/16/07, Junio C Hamano [off-list ref] wrote:
quoted
First use of new --quiet :)
You do not need to say --exit-code if you use --quiet.
Just forgot it in
quoted
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?
IFF you use git-update-index, yes
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"
- edit
- test
- edit
- test
- update-index (or add) file(s)
- git commit --index <--- this is faster than before
- repeat
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
I avoid using diff-files for the whole project. diff-index --cached is
fast always. It is ok even on windows
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.
Forgot about it too. It didn't seem to work properly, the last time
I tried (for a long time, I admit). Besides, sometimes I want to do a
refresh, and having to switch the option on and off is annoying.
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.
--no-refresh?