git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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