From: Grant <emailgrant@gmail.com>
To: git@vger.kernel.org
Subject: Re: Does git have "Path-Based Authorization"?
Date: Sat, 1 Oct 2011 17:00:56 -0700 [thread overview]
Message-ID: <CAN0CFw3kzAgaVBKNHE5ttJgYnc_csjeHjOLq=EBjLizW=RPUkA@mail.gmail.com> (raw)
In-Reply-To: <m3lit4oo9q.fsf@localhost.localdomain>
>> Hello, I'm trying to decide between git and subversion. Subversion
>> has "Path-Based Authorization" so I can give a developer access to
>> only specific files instead of everything. Does git have something
>> similar?
>>
>> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>
> In distributed version control systems each developers gets full copy
> (a clone) of a repository (separate repository instance). This means that
> if you want for developer to see only specified subset of repository
> (specific subdirectories) you would have to split repository into
> submodules, and control access on (sub)repository basis.
I do want to prevent reading of all but one or a few specified files
at a time. I did some reading on the differences between centralized
and distributed version control systems, and I can see how a
distributed system may be better for open source projects, but a
business project like mine may work better with centralized control.
Would you guys agree in general? Easier read/write control of
individual files in the repository is one benefit of the centralized
model I will put to use.
> However if you want only to prevent developer from making changes outside
> specific subdirectory or specified files, you can do that on publish time
> via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
> repository management tool such as Gitolite. That would prevent a push if
> any of commits being published touches files that it shouldn't.
>
> P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
> writes that social solutions wrt. restricting contributors to given area
> are better than technical solutions such as (overly-)strict access
> control.
When I started this thread, I didn't realize the fact that my project
is not open-source would help decide which version control system to
use. Now I see that it does factor into the decision so I apologize
for not mentioning it previously.
- Grant
next prev parent reply other threads:[~2011-10-02 0:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 23:43 Does git have "Path-Based Authorization"? Grant
2011-10-01 0:05 ` Carlos Martín Nieto
2011-10-01 1:31 ` Grant
2011-10-01 1:34 ` Nguyen Thai Ngoc Duy
2011-10-01 1:43 ` Grant
2011-10-01 2:09 ` david
2011-10-01 13:06 ` Jakub Narebski
2011-10-02 0:00 ` Grant [this message]
2011-10-02 1:27 ` Sitaram Chamarty
2011-10-02 2:53 ` Grant
2011-10-02 3:24 ` Nguyen Thai Ngoc Duy
2011-10-02 3:34 ` Grant
2011-10-02 6:38 ` Andreas Krey
2011-10-02 6:43 ` Frans Klaver
2011-10-02 14:50 ` Enrico Weigelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN0CFw3kzAgaVBKNHE5ttJgYnc_csjeHjOLq=EBjLizW=RPUkA@mail.gmail.com' \
--to=emailgrant@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).