Re: Avery Pennarun's git-subtree?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2010, 20:25 UTC
Message-ID: <7vaapc7jv8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100727182841.GA25124@worldvisions.ca>

Avery Pennarun <apenwarr@gmail.com> writes:

Show 24 quoted lines

> 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.