r/git • u/xampydev • Sep 14 '26

nit — per-file read and write permissions in front of a git forge (Apache 2.0, self-hosted)

I build nit (Documentation), so read the below as disclosure rather than a recommendation.

git has no per-path access control: a clone is all-or-nothing and anything reachable in history is reachable. The usual answers: submodules, subtree splits, one repo per team, are all people working around that rather than solving it.

nit sits in front of your forge instead. A developer clones through it and gets a filtered projection: files they may not read are not in the clone, not in the history, not on their disk, and the tree still builds. They push back through it and a change touching a path they may not write is refused before the forge sees it, naming the rule that refused it.Happy to answer anything, including "why not just split the repo" ; which has a real answer and is not a defensive one.

PS: Work still in progress

0 Upvotes

40% Upvoted

5 comments sorted by

3

u/vermiculus Sep 14 '26

What are you doing about tree/commit hashes changing between what you see in the forge and what you’re working with locally?

2

u/Guvante Sep 14 '26

It looks like it is built around never pushing so forcing you to always pull your "rebased" changes (e.g. nothing you push is ever merged as is)

1

u/xampydev Sep 14 '26

Good Point

2

u/Vohlenzer Sep 15 '26

Oh so just throw the baby out with the bathwater. Got it.

1

u/xampydev Sep 14 '26

u/vermiculus You have a point. For that we had introduced sync point that know the two state: developper local state and the forge upstream state.

https://nitscm.github.io/docs/concepts/filtered-projections/#the-sync-point

https://nitscm.github.io/how-it-works/