Re: [RFC/PATCH 0/7] Rework git core for native submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2013, 09:00 UTC
Message-ID: <7vr4im7m1y.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0n64BW8zQXweR38T6DjT+iYBbsZDPCLZ-4igqGJHoFwKw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 9 quoted lines

> Junio C Hamano wrote:
>> I think it is too premature to discuss _your_ code.  The patches do
>> not even tell us anything about how much more work is needed to
>> merely make Git with your patches work properly again.  For one
>> thing, I suspect that you won't even be able to repack a repository
>> that has OBJ_LINK only with the patches you posted.
>
> ...
> You're asking me to submit a perfect 40 or 50 part series...

Not at all.  And please do not start _coding_.

When the design is not clear enough that a 7-patch series is not ready to be reviewed, certainly 50-patch series will not be. Not until you can explain what you are trying to solve and convince others why other less disruptive approaches are fundamentally unworkable, and why we need to change the object layer.

Show 7 quoted lines

> To reiterate: link does not make possible something that is not
> fundamentally _possible_ with a .githack and a 100k-line Perl script.
>
> At its core, every variant of submodules does this.  What I'm
> essentially proposing: break up the information in .githack into
> smaller bits and create a new object type so it can be parsed by
> git-core easily.

The .gitmodules file is designed to be easily parsable by the config infrastructure and implemented as such already, thank-you-very-much.

Why do you keep calling an already working solution with derogatory misspelling? That only gives others an impression that you do not understand how the current system works, and pursuade them not to waste time responding to you. Stop it.

> When the series matures, we can investigate the other implementations
> in greater detail so we can pick out more optional fields to add to
> the link object before getting it merged.

Sorry, but that is not how open source works in general, and certainly not how this project works.

We do not add disruptive change just for the sake of changing it to break a working system, make an extra work to clean up the fallout for ourselves (i.e. your "40 to 50 patch series", but honestly speaking I expect it would be more like a 4 months work for a full time engineer or two), for unproven design (that has not yet to be illustrated) to solve problems (that has not yet to be explained), without knowing that

 (1) the problems are worth solving;

 (2) the design will solve the problems; and

 (3) solving the same problems without such a disruptive change is
     impossible, or so cumbersome that it will be far larger than
     the work needed to clean-up the fallout of the disruptive
     change.

So what are your X, Y, Z?  You still haven't answered that question.

For that matter, you didn't answer the same question that was more tersely phrased by Linus in the very first response in the thread:

Show 9 quoted lines

> Linus Torvalds wrote:
>> I don't dispute that a new link object might be a good idea, but
>> there's no explanation of the actual format of this thing anywhere,
>> and what the real advantages would be. A clearer "this is the design,
>> this is the format of the link object, and this is what it buys us"
>> would be a good idea.
>
> Yeah, I need help with that.  I've just stuffed in whatever fields
> popped into my mind first.  The current ones are:

And what you listed were your back-then-current thinking on "actual format".

What are the real advantages? How are they used? What do they allow us to do what we cannot do with .gitmodules (or repo or gitslave for that matter)? What do they buy us?

What problem are you trying to solve?

I have this suspicion that you do not have to change anything in the object layer to make Git behave very differently from the current submodule implementation. For example, if your gripe were (I am just speculating without any input from you in this thread) that each submodule working tree has ".git" at their top and there is no unified view from the top-level [*1*], we certainly can solve it without any change to the object layer.

We currently add a cache entry that has the commit object name to the index from the tree object when we check out the superproject, and create a separate repository with a working tree when we instantiate a submodule.

This arrangement does not have to be fundamental. It is a design choice of one particular working tree layout, which is totally local to individual superproject working tree.

You could arrange a single index (the one in the superproject) to hold the tree contents from the commit in the submodule, while noting the original commit object name in a new mandatory extension section in the index. The index will have a unified view of the whole tree, and we do not have to have a .git at the root of each submodule working tree (be it a directory or a gitfile).

I think the message where I talked about the "bind" idea in the list archive URLs I gave you earlier would give you such a layout, and you should go read it again to understand how the flow from object database to index to working tree back to index back to object database was envisioned to work. I think the only thing we need to do differently from that "bind" proposal in the current world order is not to record the new submodule state in the commit object of the superproject, but actually create a new commit for the submodule part and store it in the tree object for the commit in the superproject (the "bind lines in the superproject commit" was a hack, only because we didn't have a way to write the submodule commit object name in the index and in the trees).

[Footnote]

*1* I am not saying that keeping everything down to the leaves of submodules is necessarily a good idea. This is only meant as an illustration of what kind of a system that looks drastically different from the end-user's point of view you could build, without breaking the object layer and having to redo everything.