From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: saurabh@stockal.com, git@vger.kernel.org
Subject: Re: Whether Git supports directory level access or not?
Date: Tue, 07 Jul 2015 10:03:11 -0700 [thread overview]
Message-ID: <xmqq7fqb529c.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CA+P7+xpqk2m2Mxv_12Mg+03GzqVa5kzVk29HAOMiW9EGpmrWww@mail.gmail.com> (Jacob Keller's message of "Tue, 7 Jul 2015 00:20:27 -0700")
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".
next prev parent reply other threads:[~2015-07-07 17:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 6:40 Whether Git supports directory level access or not? saurabh
2015-07-07 7:16 ` Torsten Bögershausen
2015-07-07 7:20 ` Jacob Keller
2015-07-07 17:03 ` Junio C Hamano [this message]
2015-07-07 23:03 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7fqb529c.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jacob.keller@gmail.com \
--cc=saurabh@stockal.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).