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

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

 



[administrivia: people on the original thread added back on CC]

Junio C Hamano <gitster@xxxxxxxxx> writes:

> Anders Darander <anders.darander@xxxxxxxxx> writes:
>
>>>> 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?
>
> Heh, good point.  "Leave once you find one path" does not help the
> most common "sane" case where you do not kill any path, so it does
> not help us at all.

In any case, this is a regression introduced in 'master' since the
last release, and the attempted fix was for an issue that has long
been with us, so I'll revert a7365313 (git stash: avoid data loss
when "git stash save" kills a directory, 2013-06-28) soon.  For
today's -rc3, I'm already deep into the integration cycle, so it is
too late to do the revert it and then redo everything.

Then we will plan to re-apply the patch once "ls-files --killed"
gets fixed not to waste too much cycles needlessly, after the coming
release.

Thanks for a report and discussion.
--
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]