Re: [GSoC PATCH v5 4/5] repo: add field layout.shallow

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

 



On Sun, Jul 27, 2025 at 1:52 PM Lucas Seiki Oshiro
<lucasseikioshiro@xxxxxxxxx> wrote:
> This commit is part of the series that introduces the new subcommand
> git-repo-info.
>
> The flag `--is-shallow-repository` from git-rev-parse is used for
> retrieving whether the repository is shallow. This way, it is used for
> querying repository metadata, fitting in the purpose of git-repo-info.
>
> Then, add a new field `layout.shallow` to the git-repo-info subcommand
> containing that information.
>
> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx>
> ---
> diff --git a/t/t1900-repo.sh b/t/t1900-repo.sh
> @@ -42,6 +42,20 @@ test_repo_info 'bare repository = false is retrieved correctly' '
> +test_repo_info 'shallow repository = true is retrieved correctly' '
> +       git init remote &&
> +       cd remote &&
> +       echo x >x &&
> +       git add x &&
> +       git commit -m x &&
> +       cd .. &&
> +       git clone --depth 1 "file://$PWD/remote" repo &&
> +       rm -rf remote
> +       ' 'layout.shallow' 'true'

If a command fails between the `cd remote` and the `cd ..`, then the
test will abort while the working directory is still "remote", and
every subsequent test will then run in the wrong directory (because
the tests are not isolated from one another in that way). So, the rule
is: never use `cd` outside of a subshell. Therefore, you want to do
something like this:

    git init remote &&
    (
        cd remote &&
        echo x >x &&
        git add x &&
        git commit -m x
    )
    git clone --depth 1 "file://$PWD/remote" repo &&
    rm -rf remote

Alternatively, you could avoid `cd` entirely:

    git init remote &&
    echo x >remote/x &&
    git -C remote add x &&
    git -C remote commit -m x &&
    git clone --depth 1 "file://$PWD/remote" repo &&
    rm -rf remote

The choice is subjective, though I find that I can spot the secondary
repository more easily in the first example.

As I noted in my review of an earlier patch in this series, we don't
usually clean up just for the sake of cleaning up since doing so makes
it more difficult to diagnose a failed test and slows down the test
suite, so you could probably also drop the `rm -rf remote.

> @@ -60,4 +74,11 @@ test_expect_success "only one value is returned if the same key is requested twi
> +test_expect_success 'output is returned correctly when two keys are requested' '

I think this test could have been added in the previous patch (and
it's where I was expecting to find it).

> +       test_when_finished "rm -f expect" &&
> +       printf "layout.bare=false\nlayout.shallow=false\n" >expect &&

This could be made a bit easier to read either like this:

    test_write_lines layout.bare=false layout.shallow=false >expect &&

or like this:

    cat >expect <<-\EOF
    layout.bare=false
    layout.shallow=false
    EOF

It's subjective, but I find the latter example to be more obvious at a glance.

> +       git repo info layout.shallow layout.bare >actual &&
> +       test_cmp expect actual
> +'





[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