Re: Composing git repositories

> Am 01.04.2013 01:50, schrieb Phil Hord:
>> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
>> <artagnon@gmail.com> wrote:
>>> Jens Lehmann wrote:
>>>> Guess what: submodules are the solution for a certain set of use
>>>> cases, and tools like subtree are a solution for another set of
>>>> use cases. There is no silver bullet.
>>>
>>> That's the core of your argument: submodules already solve what it
>>> was meant to, and we can't get it to solve a larger class of problems.
>>>  In other words, you're implying that it's impossible to build a tool
>>> that will be able to compose git repositories in a way that solves a
>>> very large class of problems.  I don't see conclusive proof for this,
>>> so I have to disagree.
>>
>> I think it is possible to solve larger classes of problems with
>> submodules, but it is a harder problem than you seem to think.  In any
>> case I do not think you need to re-engineer submodules to improve
>> them.
>>
>> Sumodules are good for preserving history.  When properly managed,
>> they answer the question git always answers, "Where was my code in the
>> past?"  I would like proper management to be easier, but I understand
>> why it is difficult; and I see it getting easier.
>
> Exactly.
>
>> Some users also want submodules to handle other tasks, like "Import
>> branch-tracked upstream changes (i.e. git pull origin master)."  This
>> too is useful, but it is a different problem than submodules'
>> primarily try to solve.  But they do already solve _part_ of that
>> problem ("Show me how these modules are related"), so it seems a
>> trivial thing to ask them also to handle the "floating branch" task.
>> The trick is to handle this task in a way that does not break the task
>> they are designed and used for already.
>
> But I think we recently learned to support that use case with
> submodules. I think there are two floating models:
>
> - Tracked:
>   Follow a branch in the submodule and let git help you to advance
>   the submodule to the tip of that branch at certain times, but
>   still record a certain SHA-1 in the superproject to maintain
>   reproducibility. We support this since 1.8.2 (see 06b1abb5 by
>   Trevor).

> - Untracked:
>   Some people just want "the newest" tip of a branch checked out in
>   the submodule and update that from time to time (I suspect this
>   is because they are used to SVN externals, which I believe work
>   that way). You throw away reproducibility, which I think is not
>   good and not the way I expect Git to work. But that use case is
>   achieved with a simple script and some config settings telling
>   Git to don't even look for changes in the submodule anymore, and
>   submodule infrastructure will set up everything for you after
>   cloning the superproject. You run your custom script from time
>   to time and have a truly floating submodule.
>
> So to me it looks we support both floating models with current Git's
> submodule infrastructure.