Re: Composing git repositories

From: Phil Hord <phil.hord@gmail.com>
Date: Mar 31, 2013, 23:50 UTC
Message-ID: <CABURp0q9mV+-tEtHGpE4mh9cdbhkA8fr4i7XpBtK0fpfSYg-+A@mail.gmail.com>
In-Reply-To: <CALkWK0k=g3iFjmpUQA1VkuH2kZsVX1_Hpo=LZ7CuotwHz_1++g@mail.gmail.com>

On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 38 quoted lines

> Thanks for taking the time and effort to review my thoughts.
>
> Jens Lehmann wrote:
>> A
>> commit is the thing to record here because it *is* the perfect fit
>
> Might be, but saying that doesn't help one bit.  I want to know why.
>
>> I want to improve the user experience
>> of submodules and don't care much in what language we achieve that.
>
> You missed the point entirely.  If git didn't have a commit object,
> would you use a special kind of blob and code around everything to
> avoid fixing a more fundamental issue?
>
>> What happens when you rename "magit" to "foo" in that branch and want
>> to check out an older commit of the same branch? That is one of the
>> reasons why that belongs in to a checked in .gitmodules and not
>> someplace untracked.
>
> Good point.  I learnt something new.
>
>> Are you aware that current Git code already stats all files across
>> all submodules recursive by default? So (again) no problem here, we
>> do that already (unless configured otherwise).
>
> I didn't know that.  Why does it do this?
>
>> 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.

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.

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.

> To summarize, everyone seems to be elated with the current state of
> submodules and is vehemently defending it.

That's a gross overstatement. Everyone understands that is complicated and dangerous tweak a machine in operation. Such tweaks should be safe, prudent and justifiable, in roughly that order.

Phil