(I'm resending this as Gmail added some html parts...)
Junio C Hamano <gitster@xxxxxxxxx> wrote:
>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.
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.
Cheers,
Anders
.
--
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