Re: [Outreachy] [PATCH v2] diff: do not show submodule with untracked files as "-dirty"

From: Eric Sunshine <sunshine@sunshineco.com>
To: Sangeeta Jain <sangunb09@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Kaartic Sivaraam <kaartic.sivaraam@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [Outreachy] [PATCH v2] diff: do not show submodule with untracked files as "-dirty"
Date: Wed, 21 Oct 2020 13:43:03 -0400	[thread overview]
Message-ID: <CAPig+cSi1SSZTS86-6_0gDCeDqPCEvT+Lh3gLXe--Y1PDJSDfw@mail.gmail.com> (raw)
In-Reply-To: <20201021131012.20703-1-sangunb09@gmail.com>

On Wed, Oct 21, 2020 at 9:10 AM Sangeeta Jain <sangunb09@gmail.com> wrote:
> [...]
> This patch makes `git diff HEAD` consistent with `git describe --dirty`
> when a submodule contains untracked files by making
> `--ignore-submodules=untracked` the default.
> [...]
> Signed-off-by: Sangeeta Jain <sangunb09@gmail.com>
> ---
> diff --git a/diff.c b/diff.c
> @@ -4585,6 +4585,9 @@ void repo_diff_setup(struct repository *r, struct diff_options *options)
> +       if(!options->flags.ignore_submodule_set)
> +               options->flags.ignore_untracked_in_submodules = 1;

Style nit: insert a space between 'if' and the opening parenthesis

> diff --git a/submodule.c b/submodule.c
> @@ -1678,6 +1679,8 @@ unsigned is_submodule_modified(const char *path, int ignore_untracked)
>         if (ignore_untracked)
>                 strvec_push(&cp.args, "-uno");
> +       else
> +        strvec_push (&cp.args, "--ignore-submodules=none");

Style nit: use TAB for indentation, not spaces

Style nit: drop space between 'strvec_push' and open parenthesis

> diff --git a/t/t7064-wtstatus-pv2.sh b/t/t7064-wtstatus-pv2.sh
> @@ -503,6 +503,31 @@ test_expect_success 'untracked changes in added submodule (AM S..U)' '
> +test_expect_success 'untracked changes in added submodule (A. S...) (untracked ignored)' '
> +       (       cd super_repo &&
> +               ## create untracked file in the submodule.
> +               (       cd sub1 &&
> +                       echo "xxxx" >file_in_sub
> +               ) &&

I realize that you're following style of some, but not all tests, in
this file, but current the way we format subshells these days is:

    (
        cd foo &&
        ...
    ) &&

Whether you should adopt modern style or use existing style is a
judgment call. (If I was doing this, I might be inclined to follow
modern style rather than introducing even more of the unwanted old
style.)

But for really silly stuff like the 'echo', you don't need a subshell
at all, so it would be cleaner to write it like this without the
subshell:

    echo "xxxx" >sub1/file_in_sub &&

(But again, I see that you're just following local style.)

> +test_expect_success 'staged and untracked changes in added submodule (AM S.M.) (untracked ignored)' '
> +       (       cd super_repo &&
> +               (       cd sub1 &&
> +                       ## stage new changes in tracked file.
> +                       git add file_in_sub &&
> +                       ## create new untracked file.
> +                       echo "yyyy" >>another_file_in_sub
> +               ) &&

These days, `git` also understands -C, so this subshell likewise is
not necessary, and:

    git -C sub1 add file_in_sub &&
    echo "yyyy" >>sub1/another_file_in_sub

would be equivalent. (But perhaps that diverges too much from existing
style in the file? It's a judgment call.)

> diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh
> @@ -94,36 +94,60 @@ test_expect_success 'status with added file in submodule (short)' '
> +test_expect_success 'status with untracked file in submodule (untracked ignored)' '
> +       (cd sub && git reset --hard) &&

These one-liner subshells are super common in this particular script.
These days we'd write this as:

    git -C sub reset --hard &&

Again, it's a judgment call whether to go with modern style or follow
existing style of the file.

Another option is to have a preparatory patch which first modernizes
the script, and then your new tests would follow modern style. But,
that may be outside of scope of your submission.

To summarize: The only really actionable review comments are the minor
style nits in the C code. The nits about style issues in the tests are
judgement calls, and could be handled (by someone) at a later date.