Re: git stash takes excessively long when many untracked files present
- From
- Anders Darander <anders.darander@gmail.com>
- Date
- Aug 13, 2013, 17:36 UTC
- Message-ID
- <1fc732a7-6b63-4d75-960f-0b1c6cf9c70e@email.android.com>
- In-Reply-To
- <7v7gfpy0wy.fsf@alter.siamese.dyndns.org>
(I'm resending this as Gmail added some html parts...)
Junio C Hamano <gitster@pobox.com> wrote:
Show 36 quoted lines
>Anders Darander <anders.darander@gmail.com> writes:
>
>> 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
>> 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
>> 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.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,
>> 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.
Show 6 quoted lines
>>> 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
.