Re: Composing git repositories

On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann [off-list ref] wrote:

Am 01.04.2013 01:50, schrieb Phil Hord:

quoted

On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
[off-list ref] wrote:

quoted

Jens Lehmann wrote:

quoted

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.

quoted

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