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

Junio C Hamano <gits...@pobox.com> wrote:
>Anders Darander <anders.daran...@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
>> that there'll be quite a few error cases... (Especially, as I just
>> a naive attempt at patching git-stash, so I could go on with a few
>> 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.

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


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to