Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> 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.
> 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:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html