From: Jakub Narebski <jnareb@gmail.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 01/14] Extend index to save more flags
Date: Sat, 20 Sep 2008 14:59:20 -0700 (PDT) [thread overview]
Message-ID: <m3skrulbrd.fsf@localhost.localdomain> (raw)
In-Reply-To: <1221904913-25887-2-git-send-email-pclouds@gmail.com>
Comments below are just nitpicking. Feel free to diregard them...
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The on-disk format of index only saves 16 bit flags, nearly all have
> been used. The last bit (CE_EXTENDED) is used to for future extension.
>
> This patch extends index entry format to save more flags in future.
> The new entry format will be used when CE_EXTENDED bit is 1.
>
> Because older implementation may not understand CE_EXTENDED bit and
> misread the new format, if there is any extended entry in index, index
> header version will turn 3, which makes it incompatible for older git.
> If there is none, header version will return to 2 again.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
It would be nice if at least this part of series got accepted...
> ---
> cache.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
> read-cache.c | 51 +++++++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 95 insertions(+), 14 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index f4b8ddf..77b6eb3 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -109,6 +109,26 @@ struct ondisk_cache_entry {
> char name[FLEX_ARRAY]; /* more */
> };
>
> +/*
> + * This struct is used when CE_EXTENDED bit is 1
> + * The struct must match ondisk_cache_entry exactly from
> + * ctime till flags
> + */
Errr... "must match"? Wouldn't "does match" be better?
This type is defined below, not is to be defined...
> +struct ondisk_cache_entry_extended {
> + struct cache_time ctime;
> + struct cache_time mtime;
> + unsigned int dev;
> + unsigned int ino;
> + unsigned int mode;
> + unsigned int uid;
> + unsigned int gid;
> + unsigned int size;
> + unsigned char sha1[20];
> + unsigned short flags;
> + unsigned short flags2;
flags and flags2? Why not flags1 and flags2, or flags[2], or flags and
flags_ext/flags_extended?
Just nitpicking.
> + char name[FLEX_ARRAY]; /* more */
> +};
> +
> struct cache_entry {
> unsigned int ce_ctime;
> unsigned int ce_mtime;
> @@ -130,7 +150,15 @@ struct cache_entry {
> #define CE_VALID (0x8000)
> #define CE_STAGESHIFT 12
>
> -/* In-memory only */
> +/*
> + * Range 0xFFFF0000 in ce_flags is divided into
> + * two parts: in-memory flags and on-disk ones.
> + * Flags in CE_EXTENDED_FLAGS will get saved on-disk
Semicolon at the end of below text to separate, I think. Or at least
comma.
> + * if you want to save a new flag, add it in
> + * CE_EXTENDED_FLAGS
Nice comment.
> + *
> + * In-memory only flags
> + */
> #define CE_UPDATE (0x10000)
> #define CE_REMOVE (0x20000)
> #define CE_UPTODATE (0x40000)
> @@ -140,6 +168,24 @@ struct cache_entry {
> #define CE_UNHASHED (0x200000)
>
> /*
> + * Extended on-disk flags
> + */
> +/* CE_EXTENDED2 is for future extension */
> +#define CE_EXTENDED2 0x80000000
Perhaps CE_RESERVED then?
> +
> +#define CE_EXTENDED_FLAGS (0)
> +
> +/*
> + * Safeguard to avoid saving wrong flags:
> + * - CE_EXTENDED2 won't get saved until its semantic is known
> + * - Bits in 0x0000FFFF have been saved in ce_flags already
> + * - Bits in 0x003F0000 are currently in-memory flags
> + */
> +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
> +#error "CE_EXTENDED_FLAGS out of range"
> +#endif
I don't quite understand the above fragment (especially with the fact
that CE_EXTENDED_FLAGS is defined as (0))...
> diff --git a/read-cache.c b/read-cache.c
> index c5a8659..667c36b 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1096,7 +1096,7 @@ static int verify_hdr(struct cache_header *hdr, unsigned long size)
>
> if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
> return error("bad signature");
> - if (hdr->hdr_version != htonl(2))
> + if (hdr->hdr_version != htonl(2) && hdr->hdr_version != htonl(3))
> return error("bad index version");
By the way: what was index version 1?
[...]
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2008-09-20 22:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-20 10:01 [PATCH v2 00/14] Sparse checkout Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 01/14] Extend index to save more flags Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 02/14] Introduce CE_NO_CHECKOUT bit Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 03/14] ls-files: add options to support sparse checkout Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 04/14] update-index: refactor mark_valid() in preparation for new options Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 05/14] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 06/14] ls-files: Add tests for --sparse and friends Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 07/14] Prevent diff machinery from examining worktree outside sparse checkout Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 08/14] checkout_entry(): CE_NO_CHECKOUT on checked out entries Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 09/14] grep: skip files outside sparse checkout area Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 10/14] ls-files: support "sparse patterns", used to form sparse checkout areas Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 11/14] unpack_trees(): add support for sparse checkout Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 12/14] clone: support sparse checkout with --narrow-path option Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 13/14] checkout: add new options to support sparse checkout Nguyễn Thái Ngọc Duy
2008-09-20 10:01 ` [PATCH 14/14] wt-status: Show orphaned entries in "git status" output Nguyễn Thái Ngọc Duy
2008-09-20 21:59 ` Jakub Narebski [this message]
2008-09-20 22:23 ` [PATCH 01/14] Extend index to save more flags Junio C Hamano
2008-09-20 22:26 ` Junio C Hamano
2008-09-21 4:34 ` Nguyen Thai Ngoc Duy
2008-09-21 22:21 ` Jakub Narebski
2008-09-20 10:48 ` [PATCH v2 00/14] Sparse checkout Santi Béjar
2008-09-20 12:07 ` Nguyen Thai Ngoc Duy
2008-09-20 16:45 ` Jakub Narebski
2008-09-20 17:33 ` Nguyen Thai Ngoc Duy
2008-09-20 18:01 ` Jakub Narebski
2008-09-20 18:40 ` Encoding problems with format-patch [Was: [PATCH v2 00/14] Sparse checkout] Uwe Kleine-König
2008-09-20 19:48 ` [PATCH v2 00/14] Sparse checkout Nguyen Thai Ngoc Duy
2008-09-20 22:11 ` Junio C Hamano
2008-09-21 10:11 ` Nguyen Thai Ngoc Duy
2008-09-21 10:49 ` Jakub Narebski
2008-09-21 11:32 ` Nguyen Thai Ngoc Duy
2008-09-21 22:14 ` Jakub Narebski
2008-09-23 11:06 ` Santi Béjar
2008-09-23 11:56 ` Nguyen Thai Ngoc Duy
2008-09-26 16:00 ` Nguyen Thai Ngoc Duy
2008-09-20 18:52 ` Junio C Hamano
2008-09-23 11:57 ` Santi Béjar
[not found] <48d723bf90941_5de93fcd2ee870984625e@app02.zenbe.com.tmail>
2008-09-28 11:59 ` [PATCH 01/14] Extend index to save more flags Jakub Narebski
2008-09-28 12:21 ` 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=m3skrulbrd.fsf@localhost.localdomain \
--to=jnareb@gmail.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).