On Fri, Jan 22, 2016 at 04:18:03PM -0500, Jeff King wrote: > 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 -- 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