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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 11, 2012, 21:23 UTC
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:

Show 18 quoted lines

> 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.