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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Anders Darander <anders.darander@xxxxxxxxx> 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.

> 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.

>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]