Re: Whether Git supports directory level access or not?

[Jacob Keller <jacob.keller@gmail.com>]

On Tue, Jul 7, 2015 at 10:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> However, in-repo per-directory permissions make no sense, as there
>> would be no way to generate commits.
>
> That may be the case for the current generation of Git, but I do not
> think you have to be so pessimistic.
>
> Suppose that an imaginary future version of Git allowed you to
> "hide" one directory from you.  That is:
>
>  * A commit object records "tree". "git cat-file -t HEAD^{tree}"
>    or "git ls-tree HEAD" lets you inspect its contents;
>
>  * The "hidden" directory shows up as one of the subtrees of that
>    output.  It may say
>
>      040000 tree b4006c408979a0c6261dbfaeaa36639457469ad4   hidden
>
>  * However, your repository lack b4006c40... object.  So if you did
>    "git ls-tree HEAD:hidden", you would get "no such tree object".
>
>  * This imaginary future version of Git has a new implementation of
>    the index (both on-disk and in-core) that lets you keep just the
>    "tree" entry for an unmodified directory, without having to store
>    any of the files and subdirectories in it.
>
>  * All the other machinery of this imaginary future version of Git
>    are aware of the fact that "hidden" thing is not visible, or even
>    available, to your clone of the project repository.  That means
>    "fsck" does not complain about missing object b4006c40..., "push"
>    knows it should not consider it an error that you cannot enumerate
>    and send objects that are reachable from b4006c40..., etc.
>
> With such a Git, you can modify anything outside the parts of the
> project tree that are hidden from you, and make a commit.  The tree
> recorded in a new commit object would record the same
>
>      040000 tree b4006c408979a0c6261dbfaeaa36639457469ad4   hidden
>
> for the "hidden" directory, and you can even push it back to update
> the parts for other people to see your work outside the "hidden"
> area.
>
> "All the other machinery" that would need to accomodate such a
> hidden directory would span the entire plumbing layer and
> transports.  The wire protocol would need to be updated, especially
> the part that determines what needs to be sent and received, which
> is currently purely on commit ancestry, needs to become aware of the
> paths.
>
> I am *NOT* saying that this is easy.  I'd imagine if we gather all
> the competent Gits in a room and have them work on it and doing
> nothing else for six months, we would have some system that works.
> It would be a lot of work.
>
> I think it may be worth doing in the longer term, and it will likely
> to have other benefits as side effects.
>
>  - For example, did you notice that my description above does not
>    mention "permission" even once?  Yes, that's right.  This does
>    not have to be limited to permissions.  The user may have decided
>    that the "hidden" part of that directory structure is not
>    interesting and said "git clone --exclude=hidden" when she made
>    her clone to set it up.
>
>  - Also notice that the "new implementation of the index" that
>    lazily expands subtrees does not say anythying about a directory
>    that is "hidden"---it just said "an unmodified directory" and
>    that was deliberate.  Even when you are not doing a "narrow
>    clone", keeping an untouched tree without expanding its subtrees
>    and blobs flatted into the index may make it faster when you are
>    working on a series of many small commits each of which touches
>    only a handful of files.
>
> I might agree with you that "in-repo per-directory permissions make
> no sense", but the reason to say so would not be because "there
> would be no way to generate commits".

Actually as you laid out here, it does make sense I had just assumed
you would need the tree object to actually be able to generate the
commits. It does sound like a lot of work though.

Regards,
Jake