3 ms·
> it doesn't have access controls (and there's only so much you can add) so there's a lot of drawbacks to using gitolite but we were able to customise access c
by falsedan 7y ago
> it doesn't have access controls (and there's only so much you can add)
so there's a lot of drawbacks to using gitolite but we were able to customise access controls down to allowing some users the ability to only change lines of checked-in config only to certain values
- klodolph 7y agoHow do you prevent users from reading certain parts of the repository, though? This was what I meant by "there's only so much you can add"... you can reject pushes that change parts of the repo, but you can't prevent reads without breaking everything.
- falsedan 7y ago> can't prevent reads without breaking everything I don't understand, you can lie to git-upload-pack and send anything you want to the user? but when we used gitolite, we put sensitive stuff in a separate server and restricted reads to trusted users/deployment tools edit oh I see, you want to let some people clone the repo but with some stuff redacted and still be able to make changes to the non-redacted stuff. I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement
- klodolph 7y ago> I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement If you're putting a few large files in LFS, or maybe a couple sensitive files, I can understand and I'd say you're still using Git, but with some extensions. If you're putting an entire sensitive subtree in LFS, I don't think you're really using Git any more, in the sense that many of your standard Git workflows will have to be different.