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@xxxxxxxxx> wrote: > 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. > 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. > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html