Re: Avery Pennarun's git-subtree?

From: Chris Webb <chris@arachsys.com>
Date: Jul 23, 2010, 08:31 UTC
Message-ID: <20100723083149.GD27082@arachsys.com>
In-Reply-To: <AANLkTimOb2VjYI21wQsC64lm4HsVPwpRWd1twIUBnbJ3@mail.gmail.com>

Avery Pennarun <apenwarr@gmail.com> writes:

Show 9 quoted lines

> I actually think Linus's contribution - the particular change to the
> repo format to have trees link to commits - was exactly right.  If we
> want to talk about failings of git-subtree, they all precisely come
> down to the fact that, because it has tree->tree links instead of
> tree->commit links, it has to stash commitid information in the commit
> message, which is gross and error prone.
> 
> git-subtree would have benefitted from tree->commit links, but because
> git's implementation of them is broken, that wasn't an option.

I considered using submodules for one of my projects, and decided against for some of the usability reasons with multiple repositories which you highlight. (I didn't know about subtree.)

You've surely considered this already, but reading your description in this thread, my first thought is that commits within trees could mean different things depending on whether they're at paths listed in .gitmodules or not. If the path is listed, the commit is in an external repository. If it isn't, it's a reference to a local commit, allowing submodules to live in the same repo as their parent and share some of the advantages you describe for sub-tree.

Over time, git could then become smarter about recursing through commits in trees, although I can see a potential problem with needing to know about a .gitmodules blob in the top-level tree when we're examining a deeper level tree.

Cheers,

Chris.