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

Junio C Hamano [off-list ref] writes:

"Nguyen Thai Ngoc Duy" [off-list ref] writes:
...

quoted

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.

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 <redacted>
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 <redacted>
---
 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

s/but we would need to have/but we may need/
in the commit message?

On 8/17/08, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

 > "Nguyen Thai Ngoc Duy" [off-list ref] writes:

quoted

...

quoted

quoted

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:

quoted

...

quoted

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.

I was more worried about those rules getting out of control because
git-checkout is not the only command that can change narrow rules.
After enough commands, the rules can become a mess that you don't even
want to look at them. I don't do negative rules now, but yes that's
possible.

 > 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.

The patch is fine. Still we need to do something to prevent older git
from using new index format.
-- 
Duy

Eric Raible [off-list ref] writes:

s/but we would need to have/but we may need/
in the commit message?

Yeah, strictly speaking, perhaps.

One thing that I refuse to believe is we will need only one more bit and
after assigning the 0x4000 bit to whatever that single purpose the index
will stay that way forever.  So we would need to reserve that bit as the
extension bit in any case.  If we do not have any extension forever, that
means any index entry with the bit set is corrupt, so erroring out would
be the right thing to do anyway ;-).