Re: [git-users] Question about Git and Users
git, in and of itself, cannot limit access to _anything_. It is not an access control system. In order to limit access to one or more directories (folders) or files, you must use the facilities with the host operating system. Because you said folder instead of directory, I assume that you are running Windows. I don't _do_ Windows grin/. On a real OS, like UNIX or Linux, you can use Access Control Lists (ACLs) to enforce limits on a user's abilities. I would hope that Windows has something similar. But how you do this when the git way is for every user to have their own complete copy of the entire repository exist on their personal computer, is really beyond me. Normally there is a bare repository on a server. The developer does a git clone on it. This downloads everything in the repository and creates the working directory. The files and folders all belong to that user. The server is no longer in the picture at all. The developer can do what [s]he wants. They may, or may not, be able to do a git push to merge their changes back to the bare repository from which they did the git clone. But, if they can, that operation is an all or nothing. There is nothing within git, as distributed, to say that developer x can do a push, but only for files in directory y. You might be able to do something like this by using a Server Side Hook as in: http://git-scm.com/book/en/Customizing-Git-Git-Hooks If the above is what you want, then you might want to look at installing gitolite on your server. It won't address the fact that a developer will get the entire repository contents. But it can control what they can successfully push to the bare repository. https://github.com/sitaramc/gitolite Centralized SCM systems, such as Subversion, can control who can check out what. But git does not take this approach. On Fri, Jul 19, 2013 at 6:37 AM, Juan Carlos RodrÃguez juanca...@gmail.comwrote: Hi, ** **I have one question about Git. ** **I want to use Git in a project but only some developers can Access in some folders (not all folders of the Project). Can Git limits the access to folders to users? How? ** **An example: ** **Project p_example /scripts /src /docs ** **Users: A, B and C ** ** Only B and C can access into scripts, src and docs folders but A only can access into scripts folder. ** ** Thanks, -- 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/groups/opt_out. -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- 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/groups/opt_out.
Re: [git-users] Question about Git and Users
On Fri, 19 Jul 2013 04:37:59 -0700 (PDT) Juan Carlos RodrÃguez juanca...@gmail.com wrote: [...] Project p_example /scripts /src /docs Users: A, B and C Only B and C can access into scripts, src and docs folders but A only can access into scripts folder. Impossible with Git. And you have a mindset not matching that of required to use Git sensbibly. First, note that you're talking about some sort of central repository without even mentioning that fact. But Git is not a centralized system -- quite contrary, it's a distributed system where each developer has its *own* repository and has total control over its contents. I mean, whatever imaginary restrictions you would like to set up (we'll return to them shortly), they have no meaning at all in the repositories in which actual developers do their actual work. Second, Git does not track directories. This might sound weird (to someone coming from, say, Subversion) but it's true nevertheless -- the fact Git knows something about directories does not imply it actually pays any attention to them; Git indeed has the concept of trees, which resembles directories, in its repository format, but this is just a byproduct of the fact filesystems on popular OSes Git runs on are also hierarchical. When you rename a file or directory in a Git repository, and commit this change, no information is recorded to explicitly mention this fact; to give you an example, the `git mv` command which renames a file (possibly across directories) is just a shortcut for delete and untrack the file then move it physically in the work tree then start tracking it at its new location. Now let's get back to your centralized workflow. I infer from your question that you have one central (master, blessed, reference or whatever) repository everyone clones from and pushes to, and you want fine-grained control over who pushes what. Now, since Git supports so-called hooks -- scripts which run at key moments of the repository updates, including pushes -- you're in theory are able to write a post-receive hook which would traverse over each of the updated refs (branches, tags etc), then for each ref traverse the new line of commits that ref points to, and inspect it to see if the commit touches any paths you want / do not want, and fail the hook, if needed, to make the whole operation abort. You can see that this is doable but hard to get right. Now let's try to reconsider your approach to this problem. The Git way in a case like this is just to not let every single developer to commit to that reference repo. Instead, have one or two designated integrators who will be responsible for taking changes from individual developers, *verify these changes* and, if they are okay, integrate them and push the resulting commit(s) to the main repo. If needed, your individual developers might have their own central repositories, serving as backups of their local ones and/or for means of easier visibility of the stuff those developers are working on. Or each developer might have their personal set of branches in the single central repository. The de-facto standard tool to implement per-repository and per-branch read/write (or more fine-grained) access for the case of accessing the server via SSH with virtual Git users is gitolite [1]. This tool also makes possible to have per-developer repositories (it calls them wild repositories). The proposed workflow is like this: * Each individual developer either * Has their local repo accessible directly from their workstation (it's not hard to implement, really, -- one should stop thinking that VCS requires a server to operate) or * Has their personal central mirror for their local repository. * has their personal set of branches in the single central repository. In either case each developer either works in their local repo, and integrators pull from it, or they occasionally push their work either to their personal central mirror or use their personal branches in a central repo; in this case the integrators pull their work from there. * Integrators do actual integration and update the central repo. No one except those folks is able to commit there, only fetch. Of course, this approach requires certain mind bending. Linus Torvalds gave a good and lengthy explanations of this alternative mindset while helping KDE folks migrate from their CVCS to Git [2]. 1. https://github.com/sitaramc/gitolite 2. http://lwn.net/Articles/246381/ -- 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/groups/opt_out.
Re: [git-users] Question about Git and Users
On Fri, 19 Jul 2013 08:20:27 -0500 John McKown john.archie.mck...@gmail.com wrote: [...] In order to limit access to one or more directories (folders) or files, you must use the facilities with the host operating system. Because you said folder instead of directory, I assume that you are running Windows. I don't _do_ Windows grin/. On a real OS, like UNIX or Linux, you can use Access Control Lists (ACLs) to enforce limits on a user's abilities. I would hope that Windows has something similar. [...] Oh, come on! I admire your contribution to this list, but please quit spreading FUD *in this particular case:* everyone long forgot Windows 9x and FAT, and every sensible Windows flavor (I mean those OSes based on the NT kernel and its modifications) require their system partition to be on NTFS which has full support for ACLs by design, and these ACLs do actually work. Yes, ACLs are complicated, and yes, stock Windows' and 3rd-party software tend to have an unfortunate property of not paying much attention to security (services (think of daemons) usually run under the LOCAL SYSTEM account (think of root), and there's often little to no separation between the place containing the program code/data and the stuff program writes itself (think of /usr/bin + /usr/sbin vs /var/lib + /var/spool separation as per FHS) but this is no excuse for blindly bashing Windows. Also I'm quite sure you know that reasonably few people use POSIX ACLs -- they are not even enabled in default mount options for most filesystems (in Linux, I have little experience with BSDs and more exotic stuff -- they might have other defaults of implementations of ACLs). -- 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/groups/opt_out.
