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

[Jonathan Nieder <jrnieder@gmail.com>]

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