4 ms·

What are the best practices to follow in a single-repo-multiple-projecrs world? Some people recommend git submodule, others recommend subtree. How do you guys

What are the best practices to follow in a single-repo-multiple-projecrs world? Some people recommend git submodule, others recommend subtree. How do you guys manage alerts and messages - does every developer get a commit notification,or is there a way to filter out messages based upon submodule. How does branching and merging work? I'm wondering what processes are used by non-Google/FB teams to help them be more productive in a monolithic repo world.

ajross 11y ago
FWIW: git submodules are not a single repo by definition. It's just a way to automate the checkout of specifically-versioned external projects without requiring hackery like packing tarballs into the project source. It has its uses, but it's definitely not what they're talking about here.
- luckydude 11y ago
  Agree 100%. Git submodules are for tracking other stuff, not for doing dev on that other stuff. If you would like to see how things would work with submodules that behaved just like files behave (full distributed workflow) we've got a (unfortunately commercial) solution here: http://www.bitkeeper.com/nested http://www.bitkeeper.com/nested
cmrdporcupine 11y ago
Generally branching isn't really a thing at Google. Work is done at the code review level per change list ("CL"). Most changes happen through incremental submission of reviewed CLs, not by merging in feature branches. Every CL must run the gauntlet of code review, as well as can not usually be submitted without passing tests. There are rare cases where branching is used, but not commonly. As for notifications, the CL has a list of reviewers and subscribers. If you want to see code changing, you watch those CLs. Most projects have a list where all submitted CLs go.
- sandGorgon 11y ago
  Can you explain this a little more - what is a CL vs a changeset...and what do you mean by watching changelists. It sounds like you're subscribing to specific commits...but I'm talking about more at a project/directory level within the monolithic repo.
  - devinj 11y ago
    Changelist is Perforce-speak for changeset. Because each CL gets an individual review before applying to the codebase, there is no merge process -- there is no branching/merging. There is a solution for project/directory-level CC / review requirements. I didn't see it discussed in the talk, though.

ajross 11y ago

FWIW: git submodules are not a single repo by definition. It's just a way to automate the checkout of specifically-versioned external projects without requiring hackery like packing tarballs into the project source. It has its uses, but it's definitely not what they're talking about here.

luckydude 11y ago
Agree 100%. Git submodules are for tracking other stuff, not for doing dev on that other stuff. If you would like to see how things would work with submodules that behaved just like files behave (full distributed workflow) we've got a (unfortunately commercial) solution here: http://www.bitkeeper.com/nested http://www.bitkeeper.com/nested

cmrdporcupine 11y ago

Generally branching isn't really a thing at Google. Work is done at the code review level per change list ("CL"). Most changes happen through incremental submission of reviewed CLs, not by merging in feature branches. Every CL must run the gauntlet of code review, as well as can not usually be submitted without passing tests. There are rare cases where branching is used, but not commonly. As for notifications, the CL has a list of reviewers and subscribers. If you want to see code changing, you watch those CLs. Most projects have a list where all submitted CLs go.

sandGorgon 11y ago
Can you explain this a little more - what is a CL vs a changeset...and what do you mean by watching changelists. It sounds like you're subscribing to specific commits...but I'm talking about more at a project/directory level within the monolithic repo.
- devinj 11y ago
  Changelist is Perforce-speak for changeset. Because each CL gets an individual review before applying to the codebase, there is no merge process -- there is no branching/merging. There is a solution for project/directory-level CC / review requirements. I didn't see it discussed in the talk, though.