git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Lidong Yan <yldhome2d2@gmail.com>
Cc: gitster@pobox.com, git@vger.kernel.org, hi@looping.me, j6t@kdbg.org
Subject: Re: [PATCH] pull: add pull.autoStash config option
Date: Wed, 16 Jul 2025 23:27:57 -0400	[thread overview]
Message-ID: <CAPig+cTQ017qGK_Qx04+R_0rCXEOirW+oLEjeaDoCFJiQbnsGw@mail.gmail.com> (raw)
In-Reply-To: <20250717030732.75106-1-yldhome2d2@gmail.com>

On Wed, Jul 16, 2025 at 11:07 PM Lidong Yan <yldhome2d2@gmail.com> wrote:
> Git uses the `rebase.autoStash` option to decide if git-pull is allowed
> when the working tree has uncommitted changes. However, since the
> documentation does not explicitly state this, users may find it difficult
> to associate `rebase.autoStash` with the git-pull command. Add
> `pull.autoStash` option along with its documentation.

I have no opinion as to whether this is a good path forward.

> `pull.autoStash` provides the same functionality as `rebase.autoStash`
> but is more user-friendly because its prefix clearly associates it
> with git-pull commands.

Rather than "user-friendly", perhaps a better way to phrase it would
be to say that `pull.autoStash` is more *discoverable*.

> Additionally, when both options are set,
> `pull.autoStash` takes precedence and overrides the value of
> `rebase.autoStash`.

This was a question which immediately popped into my head, so it's
nice to see that you considered it and discussed it in the commit
message.

> Signed-off-by: Lidong Yan <yldhome2d2@gmail.com>
> ---
>  Documentation/config/pull.adoc |  9 +++++++++
>  builtin/pull.c                 | 10 +++++++---
>  2 files changed, 16 insertions(+), 3 deletions(-)

You will want to add one or more new tests to a test script to verify
that this new configuration works as expected, and probably also to
verify that `pull.autoStash` takes precedence over `rebase.autoStash`.

> diff --git a/Documentation/config/pull.adoc b/Documentation/config/pull.adoc
> @@ -13,6 +13,15 @@ pull.rebase::
> +pull.autoStash::
> +       When true, Git will automatically perform a `git stash` before the
> +       operation and then restore the local changes with `git stash pop`
> +       after the merge or rebase is complete. This means that you can run

I wonder if you meant "pull" instead of "merge or rebase".

> +       pull on a dirty worktree. Noticed that `rebase.autoStash` provides

s/Noticed/Notice/

> +       the same functionality, but `pull.autoStash` overrides its behavior

Rather: "...same functionality as `pull.autoStash` but overrides the
latter when..."

> +       when both are set. This option can be overridden by the `--no-autostash`
> +       and `--autostash` options of linkgit:git-pull[1]. Defaults to false.
> diff --git a/builtin/pull.c b/builtin/pull.c
> @@ -1052,7 +1056,7 @@ int cmd_pull(int argc,
>         if (opt_rebase) {
>                 if (opt_autostash == -1)
> -                       opt_autostash = config_autostash;
> +                       opt_autostash = config_pull_autostash == -1 ? config_rebase_autostash : config_pull_autostash;

You may want to wrap this over-long line. Perhaps:

    opt_autostash = config_pull_autostash == -1 ?
        config_rebase_autostash : config_pull_autostash;

  reply	other threads:[~2025-07-17  3:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15  3:26 [BUG] git pull ignores pull.autostash=true configuration when used with --git-dir and --work-tree flags on a bare repository Bryan Lee
2025-07-15  4:09 ` Lidong Yan
2025-07-15  5:31   ` Bryan Lee
2025-07-15 15:02     ` Lidong Yan
2025-07-15 20:46       ` Junio C Hamano
2025-07-16  1:39         ` Lidong Yan
2025-07-16  5:55           ` Johannes Sixt
2025-07-16 11:20             ` Lidong Yan
2025-07-16 15:16             ` Junio C Hamano
2025-07-17  3:07               ` [PATCH] pull: add pull.autoStash config option Lidong Yan
2025-07-17  3:27                 ` Eric Sunshine [this message]
2025-07-17  4:09                   ` Lidong Yan
2025-07-17  4:37                     ` Junio C Hamano
2025-07-17  5:01                       ` Lidong Yan
2025-07-17  5:48                         ` Junio C Hamano
2025-07-17  4:44                   ` Junio C Hamano
2025-07-18  3:52                 ` Lidong Yan
2025-07-18 22:13                   ` Junio C Hamano
2025-07-19  3:14                     ` Lidong Yan
2025-07-20 12:43                   ` [PATCH v2] " Lidong Yan
2025-07-21 22:10                     ` Junio C Hamano
2025-07-17 19:32               ` [BUG] git pull ignores pull.autostash=true configuration when used with --git-dir and --work-tree flags on a bare repository Ben Knoble
2025-07-15  5:31   ` Bryan Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cTQ017qGK_Qx04+R_0rCXEOirW+oLEjeaDoCFJiQbnsGw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hi@looping.me \
    --cc=j6t@kdbg.org \
    --cc=yldhome2d2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).