At this moment I will rethink with your suggested solutions.
The problem is that we have at least 20 module folders:


So I can not do 1 repo for 1 module.

Am Mittwoch, 20. November 2013 15:45:23 UTC+1 schrieb Konstantin Khomoutov:
> On Wed, 20 Nov 2013 05:51:53 -0800 (PST) 
> <javascript:> wrote: 
> > I want to use for several programmer as a team. I thought of this 
> > structure: 
> > 
> > /baselib/folder 
> > /modules/module1 
> > /modules/module2 
> > 
> > The team member should be able to read and write on the baselib but 
> > user1 should only see: 
> > 
> > /baselib/folder 
> > /modules/module1 
> > 
> > and user2 should see: 
> > 
> > /baselib/folder 
> > /modules/module2 
> > 
> > As I understand GIT (beanstalk) every user can see ALL branches so I 
> > can not use branches. 
> With plain Git, yes. 
> But there exists various server-side front-ends (gitolite, gitosis etc) 
> or "turn-key" solutions not based on Git (gitblit, gitlab etc) which 
> provide virtualized Git users and per-branch access controls. 
> > How is it possible to manage different subprojects in one project 
> > with different programmer teams and GIT? 
> Using a front-end armed with access rules is one solution. 
> But if by "beanstalk" you mean [1] then "it" looks like a front-end 
> already so consult their docs/ask their support about whether access 
> controls are possible, and if yes, then what they allow you to control. 
> I'm also afraid you're coming from Subversion and hence you naturally 
> confuse filesystem paths and branches; contrary to Subversion, in Git 
> these concepts are completely orthogonal, and you can't have access 
> controls on filesystem paths Git happens to store in its repositories. 
> If this is your case, then make yourself comfortable with this fact and 
> read on. 
> Using submodules is another solution, requiring nothing but plain Git: 
> you set up three repos: one for baselib, one for module1 and one for 
> module2.  You then make baselib a submodule of module1 and module2 
> repos.  Then you make sure only user1 has read access to the baselib 
> repo and full access to the module1 repo, and user2 has read access to 
> the baselib repo and full access to the module2 repo.  This is 
> typically done by using file-system access controls or front-end 
> facilities. 
> Another approach, which may be "more Git" than those explained above, 
> is to just dump this access control crap completely and use several 
> repos instead of a single one.  "A team member" maintains a repo in 
> which they implement baselib.  user1 and user2 maintain their own 
> separate repos in which they maintain module1 and module2.  They 
> periodically subtree-merge [2] baselib from the team member's repo. 
> Someone else maintains an integration repo, in which they periodically 
> integrate stuff from baselib, module1 and module2 -- for instance, 
> using that same subtree merging technique. 
> Yet another approach is to just have a repo which can be read and 
> written by anyone and perform history reviews: if someone messes up 
> a "foreign" part of the repo, these changes are easy to roll back and 
> the developer is easy to be punished.  I mean, people often tend to 
> seek for heavyweight technical solutions to mostly social problems 
> where a mere policy might serve quite well, and possible problems are 
> rare and are not so hard to fix. 
> 1. 
> 2. 

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 
For more options, visit

Reply via email to