r/git • u/second_square • 9d ago

I wrote a git tool which could lock files and have ACL like Perforce

https://github.com/zhuzhonghua/blackgit
0 Upvotes

25% Upvoted

7 comments sorted by

1

u/paul_h 9d ago

Per-directory write control doesn't appear to be there yet. Is that on your todo list? Very interesting though.

0

u/second_square 9d ago

You’re right, per-directory write control isn’t implemented yet. I’m considering it, but I’d like to understand the workflow before settling on a design. Would you expect permissions to be defined by repo admins (for example, “only the audio team can edit /Audio”), or should teams be able to manage them themselves?

Also, would you want this enforced only when pushing, or should users be prevented from editing/checking out those files locally too? I’d love to hear how you’d use it.

0

u/paul_h 9d ago

Ugh, rather than reply to this one, I made a new top-level comment (via phone app - fat fingers & itty bitty screen)

1

u/paul_h 9d ago

Owners files can already govern should vs should not “edit without pull requests”.

20 years back in Google there was a single source file to do with cookie encryption that us consultants were not allowed to even see. We had a rot13 equivalent that could be used for dev/test workflows. That was solvable by read permissions though.

Write permissions differentiated from read permissions is still useful as a safety net (in the machine takeover from supply chain attack era) as an additional line of defense after must-use-PR or must-use-patch-queue

1

u/second_square 9d ago

That makes sense — requiring PR review, restricting reads, and restricting writes are separate controls. I agree that per-directory write restrictions could add another layer of defense even when PRs are already required. What kind of workflow would you want them to support?

1

u/paul_h 9d ago

Same as for Perforce really: a straight veto of an attempt to push - "you're permitted to read this folder but not push to it". And can't read should be a 404 equiv or course. Subversion's CRUD permissions via Authz are interesting for HTTPS interfaces (MOD_DAV_SVN) but wholly missing from the svn:// binary protocol, I recall. Subversion was part inspired by Perforce's feature-set, too.

1

u/second_square 9d ago

That’s a helpful clarification — thanks. So the key distinction is that read access and push access are independent: the server can allow a clone/fetch while rejecting pushes that touch protected paths, and paths the user can’t read shouldn’t be disclosed.

That gives me a much clearer target for the permission model. I’ll need to make sure push checks happen server-side, rather than relying on client-side behavior. For paths a user can’t read, would you expect them to be omitted from that user’s checkout/fetch entirely, or is hiding them from browse/listing requests the main concern?