Re: Submodule design

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi,
>
> Today I learnt that a gitlink is a commit object embedded in a tree.
> However, I can't seem to be able to cat it.
>
>     $ git ls-tree HEAD
>     100644 blob 5a91f388f3648b98ae34a19ec42ba9acc7852ef4    .gitmodules
>     160000 commit 8daa12004db8862b22f6c7dd244a88ac6108b194  dotfiles
>     $ git cat-file 8daa12004db8862b22f6c7dd244a88ac6108b194
>     fatal: git cat-file 8daa12004db8862b22f6c7dd244a88ac6108b194: bad file

Is this handcrafted typescript?  You do not have "-t" nor "commit"
after cat-file, so you should have got the usage message.

In any case, not having the commit object available in the
superproject is essential and fundamental.

Binding a separate project as a submodule at a specific path in the
superproject, instead of adding the tree structure as a subdirectory
as part of the superproject, is what allows you (note this is not
"requires") to work with the superproject _without_ having to
populate the submodule.  Imagine a submodule for the source of a
library the superproject uses and the superproject is arranged in
such a way that you can build the whole thing from the source, or
you can use the installed library and link to it.  When doing the
latter, you do not have to "submodule init" that part.

The only thing the superproject needs to record is what specific
state of the submodule is meant to appear, if it is instantiated, in
the path.  We (primarily Linus, actually) chose to do so by
recording the name of the commit object from the submodule after
considering other possibilities (check the list archive).

And having to include that commit object in the superproject defeats
the whole point of binding a _separate_ and _independent_ project as
a submodule.  You could deliberately arrange the submodule so that
it shares the object store with the superproject, but that is not
the common or default mode of operation.  Not finding an object from
the submodule's history in the superproject is perfectly normal.

> What is going on?  Shouldn't we get rid of these ugly inconsistencies?

I do not see anything ugly or inconsistent, except that the way you
phrased your message may be unnecessarily an ugly way to show
frustration coming either from a lack of understanding or from a
simple misunderstanding.