git - Access Control on directories
git
Solution
Some background
While tools like `gitolite` might control who can do what with the repositories (`gitolite` appears to be the de facto standard low level solution for this), they only deal with whole repositories.
The reasons for this:
In a distributed version control system:
- Each commit represents the state of the whole repository.
- You can't clone a part of a commit. And even if you could, it would be impossible to verify the integrity of the history (due to missing objects).
- Everyone has the full repository clone (well, with Git, you might clone just enough objects to have just a single commit or a couple of them but this is a "depth-limiting" operation not "width-limiting").
So, the first thing to know is that implementing per-directory access controls are technically infeasible in a DVCS: having this option would only allow "all or nothing" access: either you have read (or write) permission on the whole repository or do not have this permission. Tools like `gitolite` can do that.
Git does not track directories at all. This is a weird thing to learn but it's true. That's why you can't add an empty directory to Git. The directories only become tracked (in the form of so-called "tree objects") when files located in them become tracked and end being tracked when those files are removed from version control. That is, tracking of directories is there only because contemporary popular filesystems are hierarchical, and Git has to handle this.
This is not some design oversight but rather a conscious design decision. You can read what the Git creator himself said on the "files vs content" debate.
So, the second thing to know is that attaching any "administrative" meaning to directories explicitly confronts the very idea of how a project is managed in Git.
What you can do about this
Use submodules.
Say, if your teams α and β should have separate code bases but some other project uses both of them, make α's and β's code bases into separate repositories and the project which uses them also a separate repository which uses submodules to refer to these two projects it depends on.
A property of submodules is that a submodule reference always refers to exact commit in the corresponding repository, so each commit in your third (dependent) repository will refer to exact states of α's and β's code bases, providing reproducible builds at any past point.
Problem
Is it possible to control different directories in git? I have a java project with many folders (packages in fact) which divides the work for the team. "Team Alpha" must be able to see and change package "alpha" and "Team Beta" must be able to see and change package "beta". but team alpha can not even see the codes in package beta, changing aside. Considering that the project works as a whole and for compiling and running it both alpha and beta packages must be present, is there a way to control this ? Another question : modular design is an option,right? whole project can work with compiled versions of alpha and beta packages, team alpha has the compiled beta package and reverse... if no,why?