Re: [PATCH] update-index: allow overwriting existing submodule index entries

[Jens Lehmann <Jens.Lehmann@web.de>]

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