Re: [PATCH v3] builtin/clone: avoid failure with GIT_DEFAULT_HASH

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

 



"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:

> On 2020-09-21 at 04:27:14, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
>> 
>> > +test_expect_success 'clone with GIT_DEFAULT_HASH' '
>> > +	(
>> > +		sane_unset GIT_DEFAULT_HASH &&
>> > +		git init --object-format=sha1 test-sha1 &&
>> > +		git init --object-format=sha256 test-sha256
>> > +	) &&
>> > +	test_commit -C test-sha1 foo &&
>> > +	test_commit -C test-sha256 foo &&
>> 
>> Unfortunately, the 'foo' commit is created in test-sha1, but the
>> next step to create 'foo' in test-sha256 fails with
>> 
>>         fatal: unknown repository extensions found:
>>                 objectformat
>
> I'm not seeing that with this series based on master
> (385c171a018f2747b329bcfa6be8eda1709e5abd).  I'm doing this:
>
>   make -j6 all && (cd t && GIT_TEST_DEFAULT_HASH=sha256 ./t5601-*.sh --verbose)
>   make -j6 all && (cd t && GIT_TEST_DEFAULT_HASH=sha1 ./t5601-*.sh --verbose)
>
> And getting this output:
>
>   Initialized empty Git repository in /home/bmc/checkouts/git/t/trash directory.t5601-clone/test-sha1/.git/
>   Initialized empty Git repository in /home/bmc/checkouts/git/t/trash directory.t5601-clone/test-sha256/.git/
>   [master (root-commit) 946e985] foo
>    Author: A U Thor <author@xxxxxxxxxxx>
>    1 file changed, 1 insertion(+)
>    create mode 100644 foo.t
>   [master (root-commit) ff872d8] foo
>    Author: A U Thor <author@xxxxxxxxxxx>
>    1 file changed, 1 insertion(+)
>    create mode 100644 foo.t
>   Cloning into 'test-clone-sha256'...
>   done.
>   Cloning into 'test-clone-sha1'...
>   done.
>   On branch master
>   Your branch is up to date with 'origin/master'.
>   
>   nothing to commit, working tree clean
>   On branch master
>   Your branch is up to date with 'origin/master'.
>   
>   nothing to commit, working tree clean
>
> Is there something I'm missing here?

I think the issue was because I queued the patch on the same base as
the previous round, which was v2.28.0.  Whe applied to 385c171a
(Fifteenth batch, 2020-09-18), I get the same as the above.

Sorry about the noise.  Will queue again.



[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