16

The Plone project consists of 192 different repos: https://github.com/plone/

During development, sometimes 2 or 4 or 10 different repos will need to be touched to fix a bug or implement a feature. It would be great if all these could be branched together and merged together (e.g. a pull request closing issueX containing commits to repo1, repo2 and repo3).

Releases require the entire set of repos to be branched and tagged together.

Pre-git, a release was defined by a file listing the svn revision numbers of all the modules that make up the release. Does git give us a more streamlined way to work?

At first glance, it seems like "Superprojects" might be applicable:

you can more specifically define the relationships between the projects with tags and branches in the superprojects

http://progit.org/book/ch6-6.html#superprojects "Git/Submodules and Superprojects" seems to confirm this, but remains vague (doesn't address tags or branches). http://en.wikibooks.org/wiki/Git/Submodules_and_Superprojects

Another tool that sounds relevant is Joey Hess's mr:

The mr(1) command can checkout, update, or perform other actions on a set of repositories as if they were one combined respository.

http://kitenet.net/~joey/code/mr/ (I would be concerned that this would result in 192 different branches that happen to have the same name, instead of 1 branch that ties together all the repos.)

This question looks relevant: Is anyone really using git super/subprojects? One answer states:

our project (bitweaver, a content management system) is a highly modular system, with nearly 160 repositories - http:// github.com/bitweaver/".

That sounds like our case. It cites "severe limitations" with submodules and recommends mercurial. It sounds like mr could help to deal with those ("perform git commands to all directories in the super-repo").

Community
  • 1
  • 1
Jean Jordaan
  • 626
  • 8
  • 24
  • 1
    Even if this is a very interesting discussion and it's already going on on plone mailing lists lately (search for "git" on http://plone.org/support/forums), unfortunately your question is not a real question. So please get involved in the proper ml discussion. – Giacomo Spettoli Nov 22 '11 at 09:49
  • I am taking part in the discussion there. Why do you think this question is not real? Do you think there is no general way to use git for many-repo projects? – Jean Jordaan Nov 22 '11 at 12:53
  • Don't get me wrong, my point is not the matter of the question. My point is that "You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page" (http://stackoverflow.com/faq#dontask). – Giacomo Spettoli Nov 22 '11 at 13:25
  • 3
    I think this is a completely valid question: Jean is looking for suggestions from folks beyond the Plone community for best-practices for using Git with large segmented codebases. – Jon Stahl Nov 22 '11 at 20:57
  • 2
    Numbers say that I'm wrong. Forget my objections and please continue. – Giacomo Spettoli Nov 23 '11 at 00:08

2 Answers2

0

Why not take a look at the repo tool that's used by android ?

Stefan Näwe
  • 3,040
  • 1
  • 18
  • 19
0

I would use git submodules in an "all" repo. Also, consider "git slave" if you find work spanning many repos. That can save a lot of effort.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 2
    Wichert Akkerman responded on the mailing list: "(a) [submodules] are in my experience difficult to use and very under-documented. I don't consider myself to be a complete moron, and yet I have never been able to update an existing submodule to point to a newer commit after studying all existing documentation. This will be a deal-breaker for many of our commiters. (b) by design submodules point to a single commit instead of a branch, which means they are not very useful to pull in continuously updated code. This might be fixed in a future git version, but that does not help us now." – Jean Jordaan Nov 23 '11 at 09:38
  • They are not that bad. I use them on a daily basis with no issues. Feel free to ping me anytime you need help. Versioning of what you use as a library is always not-trivial, no matter the tools you use. – Adam Dymitruk Nov 23 '11 at 19:54
  • @JeanJordaan There's no way to update file to newer version without editing it too. To update submodule to newer version you just "cd" to it's directory and then just `git checkout ...` Also it's good idea for submodule to point to commit instead of branch, as branches can change - "Today I checked out this project and it just crashed, but I haven't changed anything since 3 months. Probably this submodule was referring to branch, but I don't know which revision we lastly tested before we stopped development" – MBO Nov 24 '11 at 10:29