Am 11.06.2012 17:03, schrieb Junio C Hamano: > Heiko Voigt <hvoigt@xxxxxxxxxx> 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. -- 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