On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann <jens.lehm...@web.de> wrote:
> Am 01.04.2013 01:50, schrieb Phil Hord:
>> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
>> <artag...@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).

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to