Re: [PATCH] stash: don't show irrelevant entry count in status

From: Karthik Nayak <karthik.188@gmail.com>
Date: Oct 6, 2025, 14:43 UTC
Message-ID: <CAOLa=ZQVZMNXjZzSDCc9SXxRuAhRbo7hc-F9RmhYap=ABWVxzw@mail.gmail.com>
In-Reply-To: <pull.2067.git.git.1759750539721.gitgitgadget@gmail.com>

"Miroma via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 9 quoted lines

> From: Miroma <its.miroma@proton.me>
>
> Currently, when status.showStash is set, 'stash pop' shows the
> following, confusing, output:
>
>     ...
>     Your stash currently has 1 entry
>     Dropped refs/stash@{0} (abc123...)
>

Right, so your proposal is to not print stash related status information when already running a stash command. It would be nice to note that here, along why you think so.

Personally, I think it is important to keep this as is, because it tells the user the entries left in the stash post the stash operation.

Show 25 quoted lines

> Signed-off-by: Miroma <its.miroma@proton.me>
> ---
>     stash: don't show irrelevant entry count in status
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2067%2Fits-miroma%2Fstash-no-status-showStash-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2067/its-miroma/stash-no-status-showStash-v1
> Pull-Request: https://github.com/git/git/pull/2067
>
>  builtin/stash.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 1977e50df2..2bd4b7d753 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -705,6 +705,9 @@ restore_untracked:
>  			     absolute_path(repo_get_work_tree(the_repository)));
>  		strvec_pushf(&cp.env, GIT_DIR_ENVIRONMENT"=%s",
>  			     absolute_path(repo_get_git_dir(the_repository)));
> +		strvec_push(&cp.env, "GIT_CONFIG_COUNT=1");
> +		strvec_push(&cp.env, "GIT_CONFIG_KEY_0=status.showStash");
> +		strvec_push(&cp.env, "GIT_CONFIG_VALUE_0=false");
>  		strvec_push(&cp.args, "status");
>  		run_command(&cp);
>

So this block is run to print the status, unless the '--quiet' option is used. So it makes sense to do this here.

Small nit: Shouldn't we add a test to validate this change in behavior?