From: Jens Lehmann Date: Mon, 11 Jun 2012 21:23:15 GMT Subject: Re: [PATCH] update-index: allow overwriting existing submodule index entries Message-ID: <4FD661C3.7000105@web.de> In-Reply-To: <7v3961ao1q.fsf@alter.siamese.dyndns.org> Am 11.06.2012 17:03, schrieb Junio C Hamano: > Heiko Voigt writes: > >> In commit e01105 Linus introduced gitlinks to update-index. He explains >> that he thinks it is not the right thing to replace a gitlink with >> something else. >> >> That commit is from the very first beginnings of submodule support. >> Since then we have gotten a lot closer to being able to remove a >> submodule without losing its history. This check prevents such a use >> case, so I think this assumption has changed. > > Yeah, I think we should remove it if only to make it consistent with > "add" (if anything, the Porcelain level "add" should be the one that > is more strict and the plumbing level should be able to let you > shoot in the foot, not the other way around), but we need to make > sure "closer to" becomes reality. Can we remove and the resurrect > automatically when checking out a branch with a submodule when you > are on a branch with a directory and vice versa? Even while I suspect most of the time a submodule <=> directory transition will occur (moving directory content into a submodule or vice versa; and then there will be no replacement of a gitlink with something else as only the files inside the directory will be recorded) there is no reason why submodule <=> file or submodule <=> link transitions shouldn't work just fine. So yes, we can ;-) (See the recursive_submodule_checkout branch in my GitHub repo for current state of affairs, even though not all transitions work yet some do just fine) If you want I can keep this patch in my GitHub repo until "closer to" becomes reality. Me too thinks that plumbing should not enforce this restriction, but I wouldn't mind to hold this patch back until then.