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

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