git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Arver <linusa@google.com>
To: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v2 2/3] update-index: add --show-index-version
Date: Mon, 11 Sep 2023 22:54:08 -0700	[thread overview]
Message-ID: <owlybke8kkcf.fsf@fine.c.googlers.com> (raw)
In-Reply-To: <20230818233729.2766281-3-gitster@pobox.com>

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

> "git update-index --version N" is used to set the index format

s/--version/--index-version

> version to a specific version, but there was no way to query the
> current version used in the on-disk index file.
>
> Teach the command a new "--show-index-version" option, and also
> teach the "--index-version N" option to report what the version was
> when run with the "--verbose" option.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  Documentation/git-update-index.txt |  6 +++++-
>  builtin/update-index.c             | 19 +++++++++++++------
>  t/t2107-update-index-basic.sh      | 16 ++++++++++++++++
>  3 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
> index a367f8d65a..3f204891ce 100644
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -162,7 +162,8 @@ you will need to handle the situation manually.
>  	Write the resulting index out in the named on-disk format version.
>  	Supported versions are 2, 3 and 4. The current default version is 2
>  	or 3, depending on whether extra features are used, such as
> -	`git add -N`.
> +	`git add -N`.  With `--verbose` option, also reports the

How about

    `git add -N`.  With `--verbose`, also report the

> +	version the index file uses before and after this command.
>  +
>  Version 4 performs a simple pathname compression that reduces index
>  size by 30%-50% on large repositories, which results in faster load
> @@ -171,6 +172,9 @@ and support for it was added to libgit2 in 2016 and to JGit in 2020.
>  Older editions of this manual page called it "relatively young", but
>  it should be considered mature technology these days.
>
> +--show-index-version::
> +	Report the index format version used by the on-disk index file.
> +	See `--index-version` above.

Looks good.

>  -z::
>  	Only meaningful with `--stdin` or `--index-info`; paths are
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index 5fab9ad2ec..e713e2a04c 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -1089,6 +1089,8 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
>  			resolve_undo_clear_callback),
>  		OPT_INTEGER(0, "index-version", &preferred_index_format,
>  			N_("write index in this format")),
> +		OPT_SET_INT(0, "show-index-version", &preferred_index_format,
> +			    N_("show index format version"), -1),

How about

    "show on-disk index format version"

for the help text? Also "report" may be preferable instead of "show" for
consistency with the manpage.

Also, I think it would be easier to read if we didn't overload
preferred_index_format here and instead used a new variable (perhaps named
"show_index_format").

And I just realized that we are now using not only "show" and "report"
interchangeably in this patch, but also "format" and "version" ---
it would be nice to clean up as #leftoverbits.

>  		OPT_BOOL(0, "split-index", &split_index,
>  			N_("enable or disable split index")),
>  		OPT_BOOL(0, "untracked-cache", &untracked_cache,
> @@ -1181,15 +1183,20 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
>
>  	getline_fn = nul_term_line ? strbuf_getline_nul : strbuf_getline_lf;
>  	if (preferred_index_format) {
> -		if (preferred_index_format < INDEX_FORMAT_LB ||
> -		    INDEX_FORMAT_UB < preferred_index_format)
> +		if (preferred_index_format < 0) {
> +			printf(_("%d\n"), the_index.version);
> +		} else if (preferred_index_format < INDEX_FORMAT_LB ||
> +			   INDEX_FORMAT_UB < preferred_index_format) {
>  			die("index-version %d not in range: %d..%d",
>  			    preferred_index_format,
>  			    INDEX_FORMAT_LB, INDEX_FORMAT_UB);
> -
> -		if (the_index.version != preferred_index_format)
> -			the_index.cache_changed |= SOMETHING_CHANGED;
> -		the_index.version = preferred_index_format;
> +		} else {
> +			if (the_index.version != preferred_index_format)
> +				the_index.cache_changed |= SOMETHING_CHANGED;
> +			report(_("index-version: was %d, set to %d"),
> +			       the_index.version, preferred_index_format);
> +			the_index.version = preferred_index_format;
> +		}
>  	}

Looks good. But if you decide to use a new variable like
"show_index_format" as suggested above, you might want to refactor this
out to a separate function. Then you could obviously do away with the
chained if/else and replace them with early returns, which would be
easier to read.

>  	if (read_from_stdin) {
> diff --git a/t/t2107-update-index-basic.sh b/t/t2107-update-index-basic.sh
> index 89b285fa3a..c78d1e9396 100755
> --- a/t/t2107-update-index-basic.sh
> +++ b/t/t2107-update-index-basic.sh
> @@ -111,4 +111,20 @@ test_expect_success '--chmod=+x and chmod=-x in the same argument list' '
>  	test_cmp expect actual
>  '
>
> +test_expect_success '--index-version' '
> +	git commit --allow-empty -m snap &&
> +	git reset --hard &&

Not sure why this "git reset --hard" is needed here --- is it to clear
out state from previous test cases? If so, perhaps it's better to run
this as the very first command in this test case?

But this also makes me wonder why "git commit --allow-empty -m snap" is
even necessary (if we already have a git repo)?

> +	git update-index --index-version 2 >actual &&
> +	test_must_be_empty actual &&

Before we do "--index-version 2", it may be desirable to run the
"--show-index-version" flag first to see what we have before modifying
it with "2".

> +	git update-index --show-index-version >actual &&
> +	echo 2 >expect &&
> +	test_cmp expect actual &&
> +
> +	git update-index --index-version 4 --verbose >actual &&
> +	echo "index-version: was 2, set to 4" >expect &&
> +	test_cmp expect actual
> +'

How about adding this check below to check what happens if the newly-set
version is the same as the existing version?

        git update-index --index-version 4 --verbose >actual &&
        echo "index-version: was 4, set to 4" >expect &&
        test_cmp expect actual

And also how about a similar check, but for downgrading from a higher
version number to a lower one?

        git update-index --index-version 2 --verbose >actual &&
        echo "index-version: was 4, set to 2" >expect &&
        test_cmp expect actual

> +
>  test_done
> --
> 2.42.0-rc2-7-gf9972720e9

  reply	other threads:[~2023-09-12  5:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-18 23:37 [PATCH v2 0/3] "update-index --show-index-version" Junio C Hamano
2023-08-18 23:37 ` [PATCH v2 1/3] update-index doc: v4 is OK with JGit and libgit2 Junio C Hamano
2023-09-12  4:57   ` Linus Arver
2023-09-12 17:14     ` Junio C Hamano
2023-08-18 23:37 ` [PATCH v2 2/3] update-index: add --show-index-version Junio C Hamano
2023-09-12  5:54   ` Linus Arver [this message]
2023-09-12 19:01     ` Junio C Hamano
2023-08-18 23:37 ` [PATCH v2 3/3] test-tool: retire "index-version" Junio C Hamano
2023-09-12  6:10   ` Linus Arver
2023-09-12 19:32 ` [PATCH v3 0/3] "update-index --show-index-version" Junio C Hamano
2023-09-12 19:32   ` [PATCH v3 1/3] update-index doc: v4 is OK with JGit and libgit2 Junio C Hamano
2023-09-12 19:32   ` [PATCH v3 2/3] update-index: add --show-index-version Junio C Hamano
2023-11-14  2:18     ` Teng Long
2023-11-14  2:55       ` Junio C Hamano
2023-09-12 19:32   ` [PATCH v3 3/3] test-tool: retire "index-version" Junio C Hamano
2023-09-14  6:19   ` [PATCH v3 0/3] "update-index --show-index-version" Linus Arver
2023-09-14 18:15     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=owlybke8kkcf.fsf@fine.c.googlers.com \
    --to=linusa@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).