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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.