Re: [RFC PATCH 0/9] Narrow/Sparse checkout round 3: "easy mode"

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2008, 06:10 UTC
Message-ID: <7v3al49nos.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vbpzs9om7.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> ...
>> The problem is "narrow rules" may change over time in a way that git
>> may handle it wrong. Assume that you have a directory with two files:
>> a and b. You first narrow checkout a (which would save the rule
>> "checkout a"). Then you do "git checkout b". When you update HEAD,
>> what should happen?
>
> I'd expect that this sequence:
> ...
> you can record list of pathspecs (with positive and negative) to implement
> that semantics, no?

By the way, I was just mentioning the index extension area as a means to store the rules if _you wanted to_. I do not insist you to actually store the rules, and in fact, I do not know if it is even a good idea to do so.

Show 11 quoted lines

> Ok.  We would need to use an extra bit for this.
>
> The bit 0x4000 is the last one available, so we would want to use it as
> "this index entry uses more bits than the traditional format" bit, and
> define a backward incompatible on-disk index entry format to actually
> record CE_NO_CHECKOUT and other flags we will invent in the future.
>
> Perhaps ondisk_cache_entry structure will have an extra "unsigned int
> flags2" after "flags" when that bit is on, and we can have 31 more bits in
> flags2, with the highest bit of flags2 signalling the presense of flags3
> word in the future, or something like that.

It might make sense to do this first as a futureproof, if we really want to go this route. We can ensure that an index that does use the new flag bits won't be misinterpreted by older git.

-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 16 Aug 2008 23:02:08 -0700
Subject: [PATCH] index: future proof for "extended" index entries

We do not have any more bits in the on-disk index flags word, but we would need to have more in the future. Use the last remaining bits as a signal to tell us that the index entry we are looking at is an extended one.

Since we do not understand the extended format yet, we will just error out when we see it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 cache.h      |    1 +
 read-cache.c |    4 ++++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 2475de9..7b5cc83 100644
--- a/cache.h
+++ b/cache.h
@@ -126,6 +126,7 @@ struct cache_entry {
 
 #define CE_NAMEMASK  (0x0fff)
 #define CE_STAGEMASK (0x3000)
+#define CE_EXTENDED  (0x4000)
 #define CE_VALID     (0x8000)
 #define CE_STAGESHIFT 12
 
diff --git a/read-cache.c b/read-cache.c
index 2c03ec3..f0ba224 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1118,6 +1118,10 @@ static void convert_from_disk(struct ondisk_cache_entry *ondisk, struct cache_en
 	ce->ce_size  = ntohl(ondisk->size);
 	/* On-disk flags are just 16 bits */
 	ce->ce_flags = ntohs(ondisk->flags);
+
+	/* For future extension: we do not understand this entry yet */
+	if (ce->ce_flags & CE_EXTENDED)
+		die("Unknown index entry format");
 	hashcpy(ce->sha1, ondisk->sha1);
 
 	len = ce->ce_flags & CE_NAMEMASK;

-- 
1.6.0.rc3.18.g20157