From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [WIP/RFC PATCH 1/2] Introduce GIT_INDEX_PREFIX
Date: Wed, 04 Jun 2008 11:00:41 -0700 [thread overview]
Message-ID: <7vabi1xepi.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080604162825.GB23975@laptop> (Nguyễn Thái Ngọc Duy's message of "Wed, 4 Jun 2008 23:28:25 +0700")
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> GIT_INDEX_PREFIX is used to limit write access to a specific directory.
> Only "important" information is protected by index prefix (those will
> be used to create tree objects)
>
> When GIT_INDEX_PREFIX is set, any attempt to modify the index (refresh
> it is okay though) will bail out. read-tree and merge, however, can
> write to full index. For merge, no conflict is allowed outside index
> prefix.
This is kind of hard to judge as part of "narrow checkout" series, because
it is not clear how this will actually _help_ narrow checkout.
In other words, as a standalone "protect parts outside a single
subdirectory" it can be reviewed and judged, but it is unclear how it
would help narrow checkout if you excempted only a _single_ subdirectory.
E.g. you might want to limit yourself to arch/x86 _and_ include/asm-x86.
I sympathize that this series will be hard to get right as the places _you
identify_ in the code as "touching index entries" are the only places that
you _could_ write test scripts for --- if you missed one codepath it would
be easy for you to forget writing the test for that codepath.
Having said that...
> @@ -71,6 +73,9 @@ static void setup_git_env(void)
> git_graft_file = getenv(GRAFT_ENVIRONMENT);
> if (!git_graft_file)
> git_graft_file = xstrdup(git_path("info/grafts"));
> + index_prefix = getenv(INDEX_PREFIX_ENVIRONMENT);
> + if (index_prefix && (!*index_prefix || index_prefix[strlen(index_prefix)-1] != '/'))
> + die("GIT_INDEX_PREFIX must end with a slash");
Not nice (aka "why 'must'?").
> diff --git a/read-cache.c b/read-cache.c
> index ac9a8e7..4f8d44b 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -23,6 +23,11 @@
>
> struct index_state the_index;
>
> +static int outside_index_prefix(const struct index_state *istate, const char *ce_name)
> +{
> + return istate == &the_index && get_index_prefix() && prefixcmp(ce_name, get_index_prefix());
> +}
The first check above needs to be justified.
If you say "outside of this path are off-limits", why do you allow a
temporary index that is used during a partial commit and other
index_states excempt from that rule?
> @@ -793,21 +804,35 @@ static int check_file_directory_conflict(struct index_state *istate,
> return retval + has_dir_name(istate, ce, pos, ok_to_replace);
> }
>
> +static int ce_compare(const struct cache_entry *ce1, const struct cache_entry *ce2)
> +{
> + return ce1->ce_mode == ce2->ce_mode &&
> + ((ce1->ce_flags ^ ce2->ce_flags) & ~(CE_HASHED | CE_UPDATE)) == 0 &&
> + !memcmp(ce1->sha1, ce2->sha1, 20) &&
> + !strcmp(ce1->name, ce2->name);
> +}
This needs a bit of commenting to explain why HASHED and UPDATE are
specifically ignored, so that people who later add their own bit to the
flag can easily tell if their new bit should also be ignored.
> + cache1 = the_index.cache;
> + cache2 = index->cache;
> + start = 0;
> + end1 = the_index.cache_nr ? the_index.cache_nr - 1 : 0;
> + end2 = index->cache_nr ? index->cache_nr - 1 : 0;
> + while (start < end1 && start < end2 &&
> + ce_compare(cache1[start], cache2[start]))
> + start ++;
> +
> + while (end1 > start && end2 > start &&
> + ce_compare(cache1[end1], cache2[end2])) {
> + end1 --;
> + end2 --;
> + }
Style. Drop excess SP before post-increment and -decrement.
> + /*
> + * everything in start..end1 and start..end2 must
> + * be prefixed by get_index_prefix()
> + */
> + if (start < end1 &&
> + (prefixcmp(cache1[start]->name, index_prefix) ||
> + prefixcmp(cache1[end1]->name, index_prefix)))
> + return 1;
It is conventional to return negative or 0 for a function that checks "is
this kosher". Returning 0/1 risks getting misunderstood that this returns
ok for 1 and bad for 0.
next prev parent reply other threads:[~2008-06-04 18:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-04 16:28 [WIP/RFC PATCH 1/2] Introduce GIT_INDEX_PREFIX Nguyễn Thái Ngọc Duy
2008-06-04 18:00 ` Junio C Hamano [this message]
2008-06-05 3:15 ` Nguyen Thai Ngoc Duy
2008-06-05 4:35 ` Johannes Schindelin
2008-06-05 12:03 ` Nguyen Thai Ngoc Duy
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vabi1xepi.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.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.
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 NNTP newsgroup(s).