Re: Question: What's the best way to implement directory permission control in git?

[Thomas Guyot <tguyot@gmail.com>]

On 2022-07-27 04:56, ZheNing Hu wrote:
> if there is a monorepo such as
> git@github.com:derrickstolee/sparse-checkout-example.git
>
> There are many files and directories:
>
> client/
>      android/
>      electron/
>      iOS/
> service/
>      common/
>      identity/
>      list/
>      photos/
> web/
>      browser/
>      editor/
>      friends/
> boostrap.sh
> LICENSE.md
> README.md
>
> Now we can use partial-clone + sparse-checkout to reduce
> the network overhead, and reduce disk storage space size, that's good.
>
> But I also need a ACL to control what directory or file people can fetch/push.
> e.g. I don't want a client fetch the code in "service" or "web".

Pushes can easily be blocked with a pre-receive or update hook on the 
server side. That covers the case where you want to prevenr users to 
update certain paths in the repo.
> Now if the user client use "git log -p" or "git sparse-checkout add service"...
> or other git command, git which will  download them by
> "git fetch --filter=blob:none --stdin <oid>" automatically.
>
> This means that the git client and server interact with git objects
> (and don't care about path) we cannot simply ban someone download
> a "path" on the server side.

Indeed - core devs can correct me if I'm wrong but afaik even in the 
case of sparse checkouts and partial clones the packs may include other 
objects. I have no ideas how git selects objects and packs on sent and 
when it decides to repack objects... What I know is it can pack entire 
repos in just a few files using delta compression and it would probably 
make sense to sent these pack if there is no real benefit in repacking 
just the requested objects.
> What should I do? You may recommend me to use submodule,
> but due to its complexity, I don't really want to use it :-(

Submodules is definitively an option for read ACLs, and considering git 
was not originally designed to hide information from a single store it's 
probably your only option. Moreover, if the git client is able to fetch 
directly blobs and trees (the later includes partial trees as a tree 
object is a single "directory" that can contain other blobs and trees), 
then even the server has no knowledge of where a tree hook into, or even 
how it's named. All that information would have to be mapped elsewhere.

To take your example above, the "common" subtree of "service/" could be 
in multiple top level directories (i,e, the same tree with same 
contents), and each top level dirs could have a different "common" 
subtree. So git would have to find where each tree object (one per 
directory) is accessible from for *each revision* before deciding if a 
client should be authorized to fetch an object, and the same would be 
required for blobs (and tree objects don't even know their own name, 
that comes from the reference in the parent tree or commit object for 
the top-level tree).

So even before solving the client/server protocol issue you mentioned, 
you can't just hide part of a repo in git right now and changing that is 
definitively not trivial.

--
Thomas