Does git have "Path-Based Authorization"?

>> 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?
>
> Git's model does not allow the same type "Path-Based Authorization" that
> Subversion uses, because git uses secure hash sums to make sure that
> people don't try to sneak changes into a pull request or merge, and you
> can't selectively download parts of the tree because then you couldn't
> check that one of your remotes isn't trying to lie to you.
>
> You can do something that is (or can be) similar with git and
> gitolite[0] so a developer (or set of developers) only has access to a
> particular set of branches. Depending on what exactly you're trying to
> do, this can be more or less complicated to set up. If you only want a
> set of developers to access the subdirectory
> clients/importantsecretclient, then you create that directory only in
> the branch or branches that developer can read. There are many examples
> int he gitolite wiki.

> [0] https://github.com/sitaramc/gitolite/wiki/
>
> HTH
>
>   cmn

> I have a series of files containing server-side code which make up a
> website.  The entire layout contains only a few folders, but those
> folders contain many files.  I want to be able to allow access to only
> certain files at a time, sometimes only a single file.  Can that be
> done in the way you describe?

>> I have a series of files containing server-side code which make up a
>> website.  The entire layout contains only a few folders, but those
>> folders contain many files.  I want to be able to allow access to only
>> certain files at a time, sometimes only a single file.  Can that be
>> done in the way you describe?
>
> If you can gather all sensitive files in a subdirectory, then you can
> split that directory into its own repository (see git-submodule man
> page) and grant limited access to that repo.
> --
> Duy

>>> I have a series of files containing server-side code which make up a
>>> website.  The entire layout contains only a few folders, but those
>>> folders contain many files.  I want to be able to allow access to only
>>> certain files at a time, sometimes only a single file.  Can that be
>>> done in the way you describe?
>>
>> If you can gather all sensitive files in a subdirectory, then you can
>> split that directory into its own repository (see git-submodule man
>> page) and grant limited access to that repo.
>> --
>> Duy
>
> I thought about separating files the dev has had access to into a
> separate folder from files the dev hasn't had access to, but it would
> mean constantly changing the code as files move around, plus it would
> be too complicated if I have multiple devs and want to give them
> access to different stuff.  It's not that some files are more
> sensitive than others, it's just that I don't want to give anyone
> access to more than I have to.

> 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

>> 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.

> 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.

>>> 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.

>>>> 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.
>
> I'm afraid I did not follow the full thread, but I can assure you we
> have several "secret secret" type projects at work, both mine as well
> as many others.
>
> There are a few occasions when they need the kind of stuff you seem to
> want more regularly, (the only one I can really recall is one of our
> largest customers has a custom version of one of our product for
> themselves and do not want people working on the generic version to
> see those changes in case they propagate to their competitors).  We
> just do that by using a different repo entirely, and making sure
> changes to common code migrate only one way.

> How would something like that work in a case like mine where I have a
> series of maybe 100 files and I only want to give my developer
> read/write access to one or a few files at a time with no read or
> write access to any of the other files?  Wouldn't setting up a
> different repo for each set of files be difficult to manage?

>> How would something like that work in a case like mine where I have a
>> series of maybe 100 files and I only want to give my developer
>> read/write access to one or a few files at a time with no read or
>> write access to any of the other files?  Wouldn't setting up a
>> different repo for each set of files be difficult to manage?
>
> The write part is easy. Just setup hooks to reject updates on those
> files (however, notice the offline nature of git, people may commit
> locally and the push later, you may need to check commit time on your
> hooks).
>
> The reading part is hard, especially the way you put it ("at a time").
> The only way I can think of is to not download those objects and try
> to fetch from central repo every time the objects are read,
> essentially turn git into a central scm again. Git does not support
> this and may never do unless there's an reasonable use case.
>
> So I have to ask, why do you do it this way? Once you give read-access
> to a developer, he/she can always save the files somewhere, revoking
> read access later on would be useless.