Re: [PATCH v2 1/3] stash: add test to ensure reflog --rewrite --updatref behavior
- From
John Cai <johncai86@gmail.com>
- Date
- Feb 23, 2022, 23:12 UTC
- Message-ID
- <272D2409-1CAE-4203-96F7-9B104F7E5D4D@gmail.com>
- In-Reply-To
- <xmqqbkyxqjrq.fsf@gitster.g>
Hi Junio,
On 23 Feb 2022, at 17:51, Junio C Hamano wrote:
Show 46 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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@evledraar.gmail.com> (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} = CYes, this is true but that doesn't seem to test the --rewrite functionality. I could be missing something, but it seems that the reflog --rewrite option will write the LHS old oid value in the .git/logs/refs/stash file. When --rewrite isn't used, the reflog delete still does the right thing to the RHS entry.
I couldn't find any way to check this LFS value other than reaching into the actual file. If there is a way that would be preferable.
Show 6 quoted lines
> > 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.