On Sun, Dec 06, 2015 at 05:59:26PM +0100, Andreas Krey wrote: > On Sat, 05 Dec 2015 02:37:44 +0000, Jeff King wrote: > ... > > Hrm. Weird. You'd think it would break with the existing code if I do > > this, then: > > > ... > > - (cd a/b/c; git init) && > > + (cd a/b/c; git init && git commit --allow-empty -m foo) && > > git config remote.origin.url ../foo/bar.git && > > git submodule add ../bar/a/b/c ./a/b/c && > > I tried a -f here instead; did not work either. > > I guess I will first wade through the other failures my 'fix' > causes to see the total damage. The only other one I saw was in the completion tests. And it looked like `git add` failing in a way similar to what I dug into here. So I think it's "just" the one bug. > > We know it is a git dir, but there is no sha1 for us to actually add as > > the gitlink entry. > > > > If that is the case, then there is either some very tricky refactoring > > required, > > Yes, it looks like the return code delivered need to be slightly different > dependent on the user. Maybe. From your patch it looks like the "git-add" code will return it as "untracked". Which makes sense if we then want to add it. But if it has no HEAD commit we _cannot_ add it, as we have no sha1 to stick in the index. It should probably be ignored totally in that case. But that means you have to actually find out if HEAD is valid or not. Which is what the current code is doing. :-/ > > or what we are trying to do here is simply wrong. Maybe it > > would be simpler to just speed up resolve_gitlink_ref with a better data > > structure. > > Which is what I did on square one, but now we already have a real fix > for git clean, and now it's even less advantageous the fix the consequence > (the submodule cache blowing up) instead of the cause (asking for it > in the first place). I think "clean" is a much simpler case. It only wants to know "can I skip this entry as an untracked sub-repo?". And that is similar to what "git status" or "git ls-files" wants to know. But "git add" wants to know "can I _add_ this entry to the index", and that is a different question (but I think answered by the same code that powers ls-files). > PS: I seem to not quite have send-email under control, the envelope from > seems to made the patches not reach the mailing list (nor me in the CC). Hmm, yeah. Obviously they made it to me directly, but the list is a little bit picky. -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