Your overall hostility is unappreciated. The burden of proof is on
me, while you calmly sit back and criticize anything that breaks the
current working state, and refuse to look at the implementation.
Anyway, here we go again.
Junio C Hamano wrote:
> Not at all. And please do not start _coding_.
You've successfully killed all my enthusiasm. Congratulations.
> 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.
"So, my final question is: are you still not convinced that this
approach shows a lot of potential, and is worth exploring now?"
I don't know how many times to repeat this: No, Junio. A less
disruptive approach is _not_ fundamentally unworkable. You can spend
the next five years fixing submodule.c/ git-submodule.sh, or can take
a step back and think about why it's in such pathetic shape right now.
>> 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.
You're missing the point. Who parses .gitmodules? submodule.c and
git-submodule.sh, as opposed to a link being parsed by git-core. How
is it any different? That's what my series is trying to answer.
> 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.
I don't see why you have to get offended by my deliberate misspelling:
we're not emotionally attached to software, and I'm merely criticizing
what I think is a bad hack. I'm not pointing out the concrete
limitations of git-submodule precisely because they can be fixed
without any changes to the object layer: this thread will become a
discussion about how to fix submodule.c/ git-submodule.sh. You want
floating submodules? Fine, we'll write a helper script that
auto-commits to superproject everytime the SHA-1 changes. Everything
_can_ be done.
What exactly don't I "understand" about the current system, apart from
the fact that everybody is super-rigid and defensive about what
Let us take a moment to look at the current state of git-submodule
(note that this is after many years of hard work). This is just off
the top of my head:
1. To add a submodule, you can't git add. You need to git submodule
add. And only from the toplevel directory. You can't first clone and
then add either: a git submodule add clones, adds lines to
.gitmodules, AND stages everything.
2. There is currently no way to remove a submodule. You have to git
rm it, remove the lines in .gitmodules, and remove the GITDIR from
3. It is currently impossible to git mv a submodule, because of the
amount of gymnastics required to relocate the object store, rewrite
the .gitmodules and stage the correct changes.
4. It is currently impossible to do true floating submodules, because
we're using a commit object in-tree.
5. You have to execute all submodule commands from the toplevel of the worktree.
6. It is currently impossible to initialize a nested submodule without
initializing the container submodule. If I really want this, I have
to trade-off composability and use repo.
What is going on? Either the people working on git-submodule are
horribly incompetent, or there's some fundamental problem. I believe
the problem is the latter and have tried to show that the above quirks
can be fixed in a much simpler way with two days of work. What part
of this didn't you understand?
> 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
> So what are your X, Y, Z? You still haven't answered that question.
(1) The ones that are currently solved by various existing
implementations. repo, mr, gitslave, git-subtree and git-submodule.
(2) Currently, I'm targeting making the life of git-submodule.sh
simpler, fixing the UI/UX, and adding a few new features: floating
submodules, refs for submodules, and blocking statthrough. Isn't this
a definite improvement over the current design? Why are you asking me
to investigate and solve every problem exhaustively now?
(3) Nothing is impossible. It's cumbersome, and that's what I'm
trying to answer with my series: a little bit of code written in two
days can simplify a lot of things. How do I give a definite answer to
this question without submitting two different series: one fixing
submodule.c/ git-submodule.sh to do everything I want, and another to
fix everything using my approach?
> 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?
For the 100th time, there's nothing you _cannot_ do with .gitmodules.
I'm not solving any new problems. They're all solved by using a
combination of existing tools: each come with a specific set of
benefits and trade-offs. I'm trying to engineer an simple and elegant
solution that will solve many of those problems natively in git. They
buy us simplicity and elegance (I know you especially hate the word
"elegant", but I have no other way to put it).
> 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.
Yes, you can! For the 101th time.
> 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.
I don't know where you got that idea from (certainly not from reading
my series): that is not my gripe at all. As I've already stated, my
gripe is with how unnecessarily complicated, inelegant, and
featureless submodule.c/ git-submodule.sh is.
> 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.
Yes, I'm aware.
> 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 this is a very bad idea, because the toplevel index (and
combined object store) will blow up when we have lots of big
submodules. One of my goals for the new submodule design is to answer
the scaling problem with ultra-large repositories: the answer is to
break them up into smaller ones and compose them using this beautiful
and powerful mechanism.
> 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).
I don't see how this is relevant to our discussion, but anyway:
Yes, I read about your bind idea back from 2006. TL;DR version for
everyone else reading: Junio proposed that the commit object be
extended in the following way in January 2006.
bind 5b2bcc7b2d546c636f79490655b3347acc91d17f linux-2.6/
bind 0bdd79af62e8621359af08f0afca0ce977348ac7 appliance/
author Junio C Hamano <ju...@kernel.org> 1137965565 -0800
committer Junio C Hamano <ju...@kernel.org> 1137965565 -0800
The bind lines are referring to tree objects. There's a reason the
link infrastructure written in 2007 by Linus made no reference to
this: it's a bad idea. It's a much better idea to compose using
commits. Even better to compose using a specialized link object. Why
are you taking one step back from the current implementation?
So, my final question is: what do I have to do to convince you that
this approach shows promise? Haven't I answered the questions you
keep repeating: "what problem does it solve?" and "why are existing
implementations fundamentally unworkable?". I really don't know what
more to say, so can you give me a list of concrete actionable items
instead of repeating the same questions?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html