Re: Is fetch.writeCommitGraph (and thus features.experimental) meant to work in the presence of shallow clones?

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

 



Hi,

Elijah Newren wrote:

> I was building a version of git for internal use, and thought I'd try
> turning on features.experimental to get more testing of it.  The
> following test error in the testsuite scared me, though:
>
> t5537.9 (fetch --update-shallow):
>
> ...
> + git fetch --update-shallow ../shallow/.git refs/heads/*:refs/remotes/shallow/*
> remote: Enumerating objects: 18, done.
> remote: Counting objects: 100% (18/18), done.
> remote: Compressing objects: 100% (6/6), done.
> remote: Total 16 (delta 0), reused 6 (delta 0), pack-reused 0
> Unpacking objects: 100% (16/16), 1.16 KiB | 1.17 MiB/s, done.
> From ../shallow/
>  * [new branch]      master     -> shallow/master
>  * [new tag]         heavy-tag  -> heavy-tag
>  * [new tag]         light-tag  -> light-tag
> error: Could not read ac67d3021b4319951fb176469d7732e6914530c5
> error: Could not read ac67d3021b4319951fb176469d7732e6914530c5
> error: Could not read ac67d3021b4319951fb176469d7732e6914530c5
> fatal: unable to parse commit ac67d3021b4319951fb176469d7732e6914530c5
>
> Passing -c fetch.writeCommitGraph=false to the fetch command in that
> test makes it pass.

Oh!  Thanks for checking this.  At $DAYJOB this was the week we were
going to roll out features.experimental.  Time to roll that back...

How did you go about the experiment?  Does Taylor's patch make it pass?

(I'm thinking it would be nice to have a
GIT_TEST_EXPERIMENTAL_FEATURES setting that uses test_config_global at
test init time.)

Thanks,
Jonathan



[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