On Wed, Apr 15, 2015 at 7:56 PM, Junio C Hamano gits...@pobox.com wrote:
Erik Elfström erik.elfst...@gmail.com writes:
Before this change, clean used resolve_gitlink_ref to check for the
presence of nested git repositories. This had the drawback of creating
a ref_cache entry for every
Jeff King p...@peff.net writes:
Option 1:
Plug the hole in my new is_git_repository function. A quick and dirty
fix that passes the above test would be:
I think that makes sense. It would be nice if you could just call
read_gitfile, but that function is very anxious to die on error. So
On Fri, Apr 17, 2015 at 08:15:40PM +0200, erik elfström wrote:
Doesn't this implementation get confused by modern submodule
checkouts and descend into and clean their working tree, though?
Module M with path P would have a directory P in the working tree of
the top-level project, and
Erik Elfström erik.elfst...@gmail.com writes:
Before this change, clean used resolve_gitlink_ref to check for the
presence of nested git repositories. This had the drawback of creating
a ref_cache entry for every directory that should potentially be
cleaned. The linear search through the
Before this change, clean used resolve_gitlink_ref to check for the
presence of nested git repositories. This had the drawback of creating
a ref_cache entry for every directory that should potentially be
cleaned. The linear search through the ref_cache list caused a massive
performance hit for
5 matches
Mail list logo
