Re: 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?
>>>>
>>>> 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.