Re: git stash takes excessively long when many untracked files present

Anders Darander [off-list ref] writes:

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.

(I'm resending this as Gmail added some html parts...) 

Junio C Hamano [off-list ref] wrote:

Anders Darander [off-list ref] writes:

quoted

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 be 

quoted

saved
                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 

quoted

that there'll be quite a few error cases... (Especially, as I just

made

quoted

a naive attempt at patching git-stash, so I could go on with a few

other 

quoted

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.

Yes, it's more than likely that there are some real issues with adding - -directory here. I just realised that in the specific case I needed to run stash, I could do that by adding either of -u or -f as options. Obviously, 

quoted

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.

Would that mean that we're able to fail early? That's certainly an improvement, but not a working situation.

In my case, running stash in an OpenEmbedded checkout (including untracked directories for builds and caches), I gave up waiting on stash running ls-files after running at 100% for more than 12 minutes. Git status returned after a couple of seconds.

quoted

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.

I'd think that something like this is needed. As the index should be rather small, compared to e.g. some large untracked directory.

Cheers, 
Anders 


.