On Tue, Jul 7, 2015 at 10:03 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jacob Keller <jacob.keller@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html