On Sun, Oct 2, 2011 at 1:53 PM, Grant <emailgrant@xxxxxxxxx> wrote:
> 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.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html