On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
> Am 01.04.2013 01:50, schrieb Phil Hord:
>> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
>> <artagnon@xxxxxxxxx> 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).
Thanks. I followed that thread closely, but I thought the patch had
stalled again. I'm glad to see it in master
> - 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.
Well, for that matter, the "tracked" floating tip was also a simple
script once a upon a time. To say we support both is nothing new.
You could say we supported both in 1.8.1, and now we support "Tracked"
a little bit better in 1.8.2.
I think the difference is that everyone's expectation for "Untracked"
is a little bit different; or maybe it is just dangerous enough that
it should not be a core feature.
But I ain't complainin'.
Phil
--
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