Re: Composing git repositories

From: Jens Lehmann <jens.lehmann@web.de>
Date: Apr 1, 2013, 12:14 UTC
Message-ID: <51597A37.1010301@web.de>
In-Reply-To: <CABURp0q9mV+-tEtHGpE4mh9cdbhkA8fr4i7XpBtK0fpfSYg-+A@mail.gmail.com>

Am 01.04.2013 01:50, schrieb Phil Hord:

Show 23 quoted lines

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

Show 8 quoted lines

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

Show 6 quoted lines

> Some other users want submodules to solve the problem of composition,
> like "Show me the combined log of all these submodules."  (Replace
> "show log" with "diff", "merge", "bisect" or even "rebase" if you
> like.)  I think this is where Jens is leaning when working to improve
> the user experience.  But this direction does not require
> re-architecting the fundamentals of submodules.

Correct. The only major change needed for that was to move the .git directories into the .git directory of the superproject to prepare for recursive update. But that is done under the hood and didn't touch the fundamentals of using gitlinks and .gitmodules, it is just a change in the layout of the local clone.