Re: [PATCH v2 1/3] stash: add test to ensure reflog --rewrite --updatref behavior

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

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

>> +test_expect_success 'drop stash reflog updates refs/stash' '
>> +	git reset --hard &&
>> +	git rev-parse refs/stash >expect &&
>> +	echo 9 >file &&
>> +	git stash &&
>> +	git stash drop stash@{0} &&
>> +	git rev-parse refs/stash >actual &&
>> +	test_cmp expect actual
>> +'
>
> This one will be portable to the reftable backend.
>
>> +test_expect_success 'drop stash reflog updates refs/stash with rewrite' '
>
> But as I noted in <220222.86fsob88h7.gmgdl@xxxxxxxxxxxxxxxxxxx> (but it
> was easy to miss) this test will need to depend on REFFILES. So just
> changing this line to:
>
>     test_expect_success REFFILES 'drop stash[...]'
>
>> +	git reset --hard &&
>> +	echo 9 >file &&
>> +	git stash &&
>> +	oid="$(git rev-parse stash@{0})" &&
>> +	git stash drop stash@{1} &&
>> +	cut -d" " -f1-2 .git/logs/refs/stash >actual &&
>> +	cat >expect <<-EOF &&
>> +	$(test_oid zero) $oid
>> +	EOF
>> +	test_cmp expect actual
>> +'

Why should this be tested with "cut" in the first place, though?

If we start from

    stash@{0} = A
    stash@{1} = B
    stash@{2} = C

and after saying "drop stash@{1}", what we need to check is that

    stash@{0} = A
    stash@{1} = C

now holds, which can be done with "git rev-parse", and the fact that
the ref-files backend happens to record both before-and-after object
IDs is an irrelevant implementation detail, no?

I am still puzzled.






[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