I've never used multiple git repositories in large scale multi-committer
projects (the closest is a new language frontend for llvm that uses
submodules for beinging in clang and llvm, but I'm the only committer).

I see people advocating splitting large code bases into multiple git
repository and then using one of the mechanisms suggested in this thread to
'federate' the different repositories.
How do people handle atomicity of commits that span multiple repositories
(e.g a library and its clients)?
How do you review CLs spanning multiple repositories?
Are those problems only theoretical and don't happen in practice?


On Fri, Apr 4, 2014 at 2:40 PM, Magnus Therning <mag...@therning.org> wrote:

> On Fri, Apr 04, 2014 at 10:09:08AM -0700, Thomas Beardshear wrote:
> > Anyone have any suggestions for using git for multiple projects?
> >
> > The concept of git seems clear for one large project, but when your
> applets
> > are in multiple locations (departments vs server functions vs cloud-based
> > vendor integrations), it gets a little vague especially for people that
> use
> > it periodically.
> >
> > I used to simply ZIP each folder(collection of scripts/applets/programs),
> > move the ZIP file to a backup folder, then modify a file.  Works great
> but
> > I'm zipping ALL files instead of just the ones that changed.
> >
> > This works great for multiple projects, multiple storage locations,
> etc...
> >
> > Now it's time to put it all together:
> >
> > Multiple Storage Locations:
> >
> > Here is a typical setup (with a SUBSET of folders and projects)
> > Notice the UNRELATED folders.  When I use GIT, it reports that they are
> > unmonitored - when is perfectly fine that they are, but disturbing that
> > they are listed as unmonitored, not to mention screen-cluttery...
> >
> > What "concepts" in git should be used to manage the different
> > server/department project folders/subfolders?
> >
> > Branches are designed (as I understand it) to test code and maintain
> > versions.  But these are unrelated PROJECTS.
> >
> > Should I use a different GIT file for each server/department/vendor?
> > Is there another "structure management" feature that I'm missing?
>
> git submodules : http://www.git-scm.com/book/en/Git-Tools-Submodules
> git subtree :
> https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt
> git-repo : https://code.google.com/p/git-repo/
> myrepos : http://myrepos.branchable.com/
>
> There are numerous options, if I understand your question.
>
> /M
>
> --
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe               http://therning.org/magnus
>
> Most software today is very much like an Egyptian pyramid with
> millions of bricks piled on top of each other, with no structural
> integrity, but just done by brute force and thousands of slaves.
>      -- Alan Kay
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to