From: Bryan Larsen Date: Mon, 26 Jul 2010 17:36:25 GMT Subject: Re: Avery Pennarun's git-subtree? Message-ID: <4C4DC799.6070702@gmail.com> In-Reply-To: On 10-07-26 12:41 PM, Linus Torvalds wrote: > On Mon, Jul 26, 2010 at 9:37 AM, Marc Branchaud 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. > > That said, I'm not competent to comment on the actual user interface > issues. I can well believe that git-subtree has a nicer interface. > > Linus > To me, that's what git-subtree is: an internal private mirror of an external repo. Using git submodule moves that into a separately managed repo, which is just unnecessary hassle. Why maintain repo called "clone of library X for project A" when you can just stick it inside of project A without any downsides? For us, changes are made in the superproject and tested in the superproject. Once they're tested, a git subtree push or a git subtree split pushes the patches to the subproject. Once the subproject has accepted the patches, a git subtree pull merges them. Same workflow as the "private git mirror of external repo" listed above, just without the hassle of having another repo to manage. Bryan