Re: Minor bug, git ls-files -o aborts because of broken submodules

From: Jeff King <peff@peff.net>
Date: Jan 22, 2016, 22:26 UTC
Message-ID: <20160122222650.GA14772@sigill.intra.peff.net>
In-Reply-To: <20160122211803.GA17071@sigill.intra.peff.net>

On Fri, Jan 22, 2016 at 04:18:03PM -0500, Jeff King wrote:

Show 23 quoted lines

> But I think this is another case of
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/265560/focus=281253
> 
> There the question was about performance (lots of these clog up the
> linear ref_cache list), but I think the root cause is the same: going
> too far into ref resolution without realizing we don't have a real
> submodule.
> 
> Andreas posted some patches, but they didn't make it to the list. Here
> are my replies, which did:
> 
>   http://article.gmane.org/gmane.comp.version-control.git/282028
> 
>   http://article.gmane.org/gmane.comp.version-control.git/282029
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/282030
> 
> However, from going over them, I think there was a problem in the series;
> we really do need to know the sha1 in some of these cases. So I think
> maybe the simplest thing would be to catch this case in
> resolve_gitlink_ref(), before we go deeper. Let me see if I can come up
> with something.

Here it is. I think this is the right fix, based on the previous attempt by Andreas and my comments. Sorry for stealing your topic, but I hope the perf numbers in the second patch will brighten your day. :)

  [1/2]: clean: make is_git_repository a public function
  [2/2]: resolve_gitlink_ref: ignore non-repository paths

-Peff