My company is moving from CVS to git in a few weeks (and we have a
training class scheduled with the github folks).

That said our CI/build guys have already got gitorious set up (we get
to it through ssh with ssh keys and one "git" user on the server) and
we are in the process of migrating all new CVS checkins to a git repo.

As a business decision we have decided to pull in some "staff
augmentation".  We don't want the remote developers to have direct
access.  Our plan is to have some sort of external repo on which they
can push things, and locally we can pull those changes to our
"official" repo and check it as we go.  So far so good.

Our product has several logically separate projects, which right now
we have in the one big mega repo (in CVS, and migrating per checkin to

So... I was wondering what the best way to split up our new repo might
be - or is it best to NOT split it?   One of the concerns we have is
that in the one big repo we can't control access to the various
projects.  So far we haven't needed to but this might be because we

So one plan is to have multiple repos, and then a mirror of those for
the remote devs.  The other plan is to say "sod it" and have one local
and one remote and just suffer through possible non-requirements of
varying authorization profiles.

Is there documentation I can refer to for this, or is there an obvious
way to do these things?  Any help or pointers appreciated.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to