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.
...
> 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.
> 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 don't think we should let is_git_repository look for a valid(ish) HEAD.
Andreas
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).
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
