public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Ben Knoble <ben.knoble@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: Johannes Sixt <j6t@kdbg•org>, Lidong Yan <yldhome2d2@gmail•com>,
	Bryan Lee <hi@looping•me>,
	git@vger•kernel.org
Subject: Re: [BUG] git pull ignores pull.autostash=true configuration when used with --git-dir and --work-tree flags on a bare repository
Date: Thu, 17 Jul 2025 15:32:03 -0400	[thread overview]
Message-ID: <66D1F0CE-3DBC-45BE-A777-606D50E84094@gmail.com> (raw)
In-Reply-To: <xmqq5xfsdv3w.fsf@gitster.g>


> Le 16 juil. 2025 à 11:17, Junio C Hamano <gitster@pobox•com> a écrit :
> 
> Johannes Sixt <j6t@kdbg•org> writes:
> 
>> Instead of this complexity, it is most likely a lot easier to fix the
>> origin of the misconception that `pull.autostash` is the correct
>> configuration. After all, it isn't even mentioned in the git-config nor
>> the git-pull man page.
> 
> git_pull_config() does pay attention to "rebase.autostash".  
> 
> Either it is a bug for the code to do so, or it is a bug that the
> documentation does not talk about it.  
> 
> The reason why I think "git pull" that pays attention to
> rebase.autostash is a bug is because the user is more likely to be
> much more familiar with both branches involved and more likely to be
> prepared to deal with conflicts potentially created by autostashing
> behaviour when making a private merge or rebase of local branches,
> than when pulling from other repositories.  So those who show
> willingness to accept the responsibility of having to resolve
> conflicts that arise when popping autostashed changes by setting
> rebase.autostash may not want to be cavalier to the same degree when
> running "git pull".  git_pull_config() that pays attention to
> "rebase.autostash" breaks that expectation.

On the other hand, a pull that rebases is (conceptually) a fetch followed by a rebase, and there is a lot of description and teaching of pull as fetch+merge. Breaking that expectation is also unnatural.

I would consider it far more inconsistent if pulls that rebase don’t honor rebase configuration. So put me in the camp that pull should probably respect merge.autostash, too. (I don’t have any opinion about pull.autostash, which seems reasonable on the surface.)

> 
> There is another curiosity.  git_pull_config() does not pay
> attention to "merge.autostash", which seems inconsistent.
> 
> If I did not have any existing users, I would actually vote to teach
> git_pull_config() stop paying attention to "rebase.autostash", but
> we do not live in an ideal world.  Perhaps rectify this at Git 3.0?

      parent reply	other threads:[~2025-07-17 19:32 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  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
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               ` Ben Knoble [this message]

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=66D1F0CE-3DBC-45BE-A777-606D50E84094@gmail.com \
    --to=ben.knoble@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=hi@looping$(echo .)me \
    --cc=j6t@kdbg$(echo .)org \
    --cc=yldhome2d2@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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