[falsedan]

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

How 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]

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

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