Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk

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

Am 05.01.2010 10:46, schrieb Johannes Schindelin:
> But I have a use case here where the shared content is _not_ a library 
> that can live in a subdirectory naturally.

Yes, we had to reorganize a major part of one project too. Heiko could
tell more about that.


>> Having read up about svn externals in the meantime, what about something
>> like this:
>> - Add a command like "git submodule forward" (as update is already in
>>   use) that takes an optional -b <branchname>. It does a fetch in the
>>   submodule, then tries to fast forward (or rebase) to master or the
>>   branch given and stages this commit in the superproject. This should
>>   be the equivalent to doing an "svn update" in a repo with externals.
>>   Or am i missing something?
> 
> Yes.  It is not the decision of the fetcher, but of the guy who adds the 
> submodule to decide what it is.
>
>> - We could also add an option to "git submodule add" to specify the
>>   default branch name for forward.
> 
> That's an obvious precondition for proper always-tip-submodules.  But 
> Git's core data structure, the index, does not allow for it.  _That_ is 
> the difficulty, not what the user interface would look like.

I have never experienced (and never had the need for) such an always-tip
scenario and therefore still seem to have difficulties to grok it. I
assume you always want to have the newest tip at /checkout/ time, not at
/commit/ time? Then my proposal would really not help you.


> I start to wonder whether the insistence that .gitmodules' settings must 
> be overrideable makes any sense in practice.

I know of none, maybe someone else can speak up here?
(And even if it is overrideable, do the settings necessarily have to be
copied into .git/config when they aren't even overridden?)