Re: Need help deciding between subtree and submodule

From: Chris Packham <judge.packham@gmail.com>
Date: Mar 18, 2015, 08:20 UTC
Message-ID: <CAFOYHZCCUUjLnv3qpMBVPExR+4jdu09y5c8BcN8SNT0HWzqpHw@mail.gmail.com>
In-Reply-To: <CAHd499DN1FUzxGYBtUmZ_gKcCvXWJdR6-6XYXsN6BRn0LVO84g@mail.gmail.com>

My $0.02 based on $dayjob

(disclaimer I've never used subtree)

On Wed, Mar 18, 2015 at 11:14 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:

Show 6 quoted lines

> At my workplace, the team is using Atlassian Stash + git
>
> We have a "Core" library that is our common code between various
> projects. To avoid a single monolithic repository and to allow our
> apps and tools to be modularized into their own repos, I have
> considered moving Core to a subtree or submodule.

Our environment is slightly different. Our projects are made up entirely of submodules, we don't embed submodules within a repo with actual code (side note: I know syslog-ng does so it might be worth having a look around there).

Day to day development is done at the submodule level. A developer working on a particular feature is generally only touching one repo notwithstanding a little bit of to-and-fro as they work on the UI aspects. When changes do touch multiple submodules the pushes can generally be ordered in a sane manner. Things get a little complicated when there are interdependent changes, then those pushes require co-operation between submodule owners.

The key to making this work is our build system. It is the thing that updates the project repo. After a successful build for all targets (we hope to add unit/regression tests one day) the submodules sha1s are updated and a new baseline (to borrow a clearcase term) is published. Developers can do "git pull && git submodule update" to get the latest stable baseline, but they can also run git pull in a submodule if they want to be on the bleeding edge.

Show 14 quoted lines

> I tried subtree and this is definitely far more transparent and simple
> to the team (simplicity is very important), however I notice it has
> problems with unnecessary conflicts when you do not do `git subtree
> push` for each `git subtree pull`. This is unnecessary overhead and
> complicates the log graph which I don't like.
>
> Submodule functionally works but it is complicated. We make heavy use
> of pull requests for code reviews (they are required due to company
> policy). Instead of a pull request being atomic and containing any app
> changes + accompanying Core changes, we now need to create two pull
> requests and manage them in proper order. Things also become more
> difficult when branching. All around it just feels like submodule
> would interfere and add more administration overhead on a day to day
> basis, affecting productivity.

We do have policies around review etc. With submodules it does sometimes require engaging owners/reviewers from multiple repositories. Tools like Gerrit can help, particularly where multiple changes and reviewers are involved.

Show 6 quoted lines

> Is there a third option here I'm missing? If only that issue with
> subtree could be addressed (the conflicts), it would be perfect enough
> for us I think. I have done all the stackoverflow reading and research
> I can manage at this point. I would really love some feedback from the
> actual git community on what would be a practical solution and
> structure here from a company perspective.

There's the thing google use for android, I think it's called "repo". There's a few googlers around here so mybe one of them will chime in.