Re: git stash takes excessively long when many untracked files present
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:58:24
Anders Darander [off-list ref] writes:
quoted hunk
diff --git a/git-stash.sh b/git-stash.sh index 85c9e2c..e5a2043 100755 --- a/git-stash.sh +++ b/git-stash.sh@@ -263,7 +263,7 @@ save_stash () { exit 0 fi if test -z "$untracked$force" && - test -n "$(git ls-files --killed | head -n 1)" + test -n "$(git ls-files --killed --directory | head -n 1)" then say "$(gettext "The following untracked files would NOT besaved test -n "$GIT_QUIET" || git ls-files --killed | sed 's/^/\t/' ------------------------------------------- It seems to work in my extremely limited testing. Though, I'm pretty sure that there'll be quite a few error cases... (Especially, as I just made a naive attempt at patching git-stash, so I could go on with a few other things).
I am not sure adding "--directory" there is safe. Aren't there cases where saving a stash and going back to the committed state will involve killing no directories, but some files? If your local change is to remove a directory and files in it from your working tree and then deposit a newly created file at the path where the directory was in the HEAD, stashing that local change and then going back to the HEAD will involve removing the new file from the working tree, and unless you have "git add"ed the new file, it will be lost.
Do anyone have any better idea on how to approach this?
Teaching "ls-files" to leave early once it seens even a single output is probably a possibility.
quoted
I see a lot of room for optimization here. Most importantly, git ls-files --killed really doesn't need to look at any directory entry unless something in the index would conflict with it.
This observation probably is correct, even though I didn't think about it long enough. Thanks.