Re: [PATCH v2 2/3] update-index: add --show-index-version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Arver <linusa@xxxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> "git update-index --version N" is used to set the index format
>
> s/--version/--index-version

Good eyes.

>> +	`git add -N`.  With `--verbose` option, also reports the
>
> How about
>
>     `git add -N`.  With `--verbose`, also report the

Yup, that is much better.

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

OK.  The entry before that says "write" and it makes it clear enough
that it is talking about the "on-disk" thing, hence "write index" is
sufficient.  The readers, who do not know the "format version"
matters only on-disk and does not matter once the index data gets
slurped into memory, would benefit with "on-disk index" here.  I
will also take your "show" -> "report" suggestion.

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

There is no commit yet in this repository at this point, which means
that "reset --hard [HEAD]" cannot be the first command.  There are
newly added paths in the index, some of which are further modified
in the working tree.  Creating a snapshot commit will record what is
in the index, and a hard reset will make the contents of the working
tree match exactly what was in the index, reverting the modification
made to some paths in the working tree.

Having said that, we may further want to tighten these "clean the
slate" steps for later tests (read on).

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

That was what I specifically wanted to avoid.  I am not interested
in testing what the default version of the day is.  The only thing
this invocation cares about is to (try to) use the version 2; it
will be detected as a failure if the next show-index-version
reported something else ...

>> +	git update-index --show-index-version >actual &&
>> +	echo 2 >expect &&
>> +	test_cmp expect actual &&

... which is checked here.

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

And how a transition is reported with --verbose is tested here.

>> +'
>
> 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

I assumed that the flipping between versions without --verbose had
adequate coverage and the tests this patch adds were solely about
reporting with the "--verbose" option.  It seems there is no such
test coverage, so these may want to be added.  Perhaps we should
flip from 2 to 4 _without_ verbose and make sure we are still silent
as well.

Testing downgrading an index with unspecified [*] contents from 3
(or higher) to 2 would be unwise, as such a conversion may or may
not work depending on the contents.  I will tighten the "clean the
slate" steps and add downgrades to the list, as the initial "try to
set to 2" may not even work with unknown contents in the index.

Thanks.


[Footnote] 

* This is in a very late part of the test script and the state
  previous tests left us will change over time.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux