Re: Avery Pennarun's git-subtree?

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

Avery Pennarun <apenwarr@gmail.com> writes:

> On Mon, Jul 26, 2010 at 09:41:42AM -0700, Linus Torvalds wrote:
>
>> On Mon, Jul 26, 2010 at 9:37 AM, Marc Branchaud <marcnarc@xiplink.com> wrote:
>> >
>> > I think I should mention one aspect of what we're doing, which is that a lot
>> > of our submodules are based on external code, and that we occasionally need
>> > to modify or customize some of that code.  So it's quite nice for us to
>> > maintain private git mirrors of the external repos, with our own private
>> > branches that contain our modifications.  Although we want to get much of our
>> > changes incorporated into the upstream code bases, upstream release cycles
>> > are rarely in sync with ours.
>> 
>> THIS.
>> 
>> This is why I always thought that submodules absolutely have to be
>> commits, not trees. It's why the git submodule data structures are
>> done the way they are. Anything that makes the submodule just a tree
>> is fundamentally broken, I think.
>
> I agree completely.  The major failing of git-subtree is that it uses
> tree->tree links instead of tree->commit links.
>
> This was necessary only because git fundamentally *mistreats* tree->commit
> links: it refuses to push or fetch through them automatically.

I do not think that is so "fundamental" as you seem to think.

Isn't it just the matter of how the default UI of object transfer commands
(like push and fetch) are set up?

Admittedly, the way the default UI is set up is to strongly favor the
early design decision we made back when Linus did his initial "gitlink"
implementation, which is "separate project lives in a separate repository,
and not having to check out any subproject should be the norm for using a
superproject".  

Some "recursive" operations have been added to commands for which it makes
sense (e.g. "clone --recursive") by people who cared enough.  Even though
there are a few other commands that shouldn't ever learn the recursive
mode (e.g. "commit --recursive -m $msg" would not make sense), there still
are some commands where a similar "--recursive" option would make sense
but haven't learned it (e.g. "push --recursive").

I also consider it merely a lack of UI enhancement that you have to clone
the submodule again (or cannot switch to a clean slate very easily) when
switching between revisions of superproject before and after you add a
submodule, and nothing fundamental.  

When switching back in history to lose a recent submodule, the user
experience should be like switching to a revision that didn't have a
directory.  You shouldn't be able to lose your change in that directory,
but if the directory is clean, you should be able to lose it.  And when
you switch to a more recent revision that has the submodule, you should be
able to get it back (again, if you have a precious file there, the
checkout should barf).

We have added support for having "gitdir: $dir" in a regular file .git
exactly because we wanted to be able to stash away the submodule's .git
directory somewhere inside .git (e.g. .git/modules/<submodulename>) in the
superproject when we do that kind of branch switching, so that we can get
it back when switching back to a revision with the submodule without
having to re-clone (also this presumably would help when you move the
submodule in the superproject tree), but there haven't been further work
to make use of this in "git submodule update" (it probably needs to start
by teaching "git clone" how to make use of "gitdir: $dir", if anybody is
interested).

By the way, I also do not think it is such a bad thing that git-subtree
does not bind commit into its superproject tree while it is working
"natively" (in a "git-subtree" workflow), but allows users to easily split
the history into an exportable shape to upstreams of its submodules when
such an operqation is needed.  If you rarely push back to upstreams but
constantly consume their changes, that sounds like a reasonable way to go.