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

> From: Artur Bieniek <ar2rekb@gmail.com>
>
> Add --hard as an explicit alternative to merge and rebase. After
> fetching, require a single integration candidate and reset the current
> branch, index, and working tree to it.

There may be a population of users who *never* make changes to their
history or working tree, and always want to "hard reset to the
updated upstream".  Doing so would be safe for them because they
create nothing in their tree whose loss matters.

Giving them a convenient and safe way to do so might be worth
considering, but the behavior is already safely and explicitly
achieved by running 'git fetch' followed by 'git reset --hard @{u}',
so I am not sure whether it is worth adding another way to do so.

More importantly, throwing it into 'git pull' feels very wrong.

The core purpose of 'git pull' is history integration.  The command
is designed to help those who make their own changes and advance
history.  Adding a destructive option to the command makes it easier
for them to trigger it by accident, and unlike the main target of
this new feature, they have things in their tree that they cannot
afford to lose to accidents or mistakes.

So, I am mildly against adding anything of this sort to 'git pull'.
For that matter, I am generally against making it convenient to
discard or destroy history.  I prefer to keep these destructive
operations explicit, e.g., "fetch + reset --hard".

Thanks.

On 18/08/2026 15:48, Junio C Hamano wrote:
> "Artur Bieniek via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >> From: Artur Bieniek <ar2rekb@gmail.com>
>>
>> Add --hard as an explicit alternative to merge and rebase. After
>> fetching, require a single integration candidate and reset the current
>> branch, index, and working tree to it.
> > There may be a population of users who *never* make changes to their
> history or working tree, and always want to "hard reset to the
> updated upstream".  Doing so would be safe for them because they
> create nothing in their tree whose loss matters.
> > Giving them a convenient and safe way to do so might be worth
> considering, but the behavior is already safely and explicitly
> achieved by running 'git fetch' followed by 'git reset --hard @{u}',
> so I am not sure whether it is worth adding another way to do so.

I think if the design was slightly different so that it errored out by default if there were uncommitted changes then that would make it worth while as it is safer than "git fetch; git reset --hard @{u}" and would allow the user to carry over those changes with "--autostash". So to me something like

	git pull --reset [--discard-changes | --autostash]

would be a more convincing design.

> More importantly, throwing it into 'git pull' feels very wrong.
> > The core purpose of 'git pull' is history integration.  The command
> is designed to help those who make their own changes and advance
> history.  Adding a destructive option to the command makes it easier
> for them to trigger it by accident, and unlike the main target of
> this new feature, they have things in their tree that they cannot
> afford to lose to accidents or mistakes.

If it refused to reset by default when there were uncommitted changes would that be safe enough? Uncommitted changes would be protected and any local commits that become unreachable after the reset can still be retrieved from the reflog. It's not quite the same as integrating remote and local changes, but more like updating the working copy.

Thanks

Phillip

> So, I am mildly against adding anything of this sort to 'git pull'.
> For that matter, I am generally against making it convenient to
> discard or destroy history.  I prefer to keep these destructive
> operations explicit, e.g., "fetch + reset --hard".
> > Thanks.
> 

Phillip Wood <phillip.wood123@gmail.com> writes:

> I think if the design was slightly different so that it errored out by 
> default if there were uncommitted changes then that would make it worth 
> while as it is safer than "git fetch; git reset --hard @{u}" and would 
> allow the user to carry over those changes with "--autostash". So to me 
> something like
>
> 	git pull --reset [--discard-changes | --autostash]
>
> would be a more convincing design.
> ...
> If it refused to reset by default when there were uncommitted changes 
> would that be safe enough? Uncommitted changes would be protected and 
> any local commits that become unreachable after the reset can still be 
> retrieved from the reflog. It's not quite the same as integrating remote 
> and local changes, but more like updating the working copy.

Yup, but git pull --ff-only serves the "No development is done in
this repository; it is merely to keep the latest sources here"
audience just fine.

What you are suggesting may be *useful* for those who agree with
this statement:

    I do value my local changes because I haven't committed them,
    but I am willing to discard these changes and replace them with
    whatever the upstream did.

but I am not sure of the use case for a repository/working tree
that is managed in such a way.

One case where --ff-only does not seem to cover that audience is when the upstream branch itself is rewritten.

For example, a checkout may contain no local development at all and only be used to track the latest state of an upstream branch, but if that branch is rebased or otherwise force-updated, git pull --ff-only will refuse to update it because the histories have diverged.

That seems like a reasonably natural use case for the behavior Phillip described: git pull --reset on a clean working tree would mean "make this checkout match the fetched upstream", while still refusing by default to discard uncommitted changes.

I also like that distinction better than my original --hard proposal, since the destructive working-tree behavior would no longer be implicit in the primary option.

Thanks,
Artur

On 8/20/26 5:59 PM, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> >> I think if the design was slightly different so that it errored out by
>> default if there were uncommitted changes then that would make it worth
>> while as it is safer than "git fetch; git reset --hard @{u}" and would
>> allow the user to carry over those changes with "--autostash". So to me
>> something like
>>
>> 	git pull --reset [--discard-changes | --autostash]
>>
>> would be a more convincing design.
>> ...
>> If it refused to reset by default when there were uncommitted changes
>> would that be safe enough? Uncommitted changes would be protected and
>> any local commits that become unreachable after the reset can still be
>> retrieved from the reflog. It's not quite the same as integrating remote
>> and local changes, but more like updating the working copy.
> > Yup, but git pull --ff-only serves the "No development is done in
> this repository; it is merely to keep the latest sources here"
> audience just fine.
> > What you are suggesting may be *useful* for those who agree with
> this statement:
> >      I do value my local changes because I haven't committed them,
>      but I am willing to discard these changes and replace them with
>      whatever the upstream did.
> > but I am not sure of the use case for a repository/working tree
> that is managed in such a way.

On Thu, Aug 20, 2026, at 18:43, Artur Bieniek wrote:
> One case where --ff-only does not seem to cover that audience is when
> the upstream branch itself is rewritten.
>
> For example, a checkout may contain no local development at all and only
> be used to track the latest state of an upstream branch, but if that
> branch is rebased or otherwise force-updated, git pull --ff-only will
> refuse to update it because the histories have diverged.

I don’t understand what you need a branch for in that case. I just use
the remote-tracking branch in that case (`origin/main` e.g.).

PS: Bottom posting is strongly preferred on this list.

> ...

Artur Bieniek <abieniek@antmicro.com> writes:

> One case where --ff-only does not seem to cover that audience is when 
> the upstream branch itself is rewritten.

It does, doesn't it?  

It is not like you want to always blindly follow them.  Rewound
upstream is w warning-worthy event that the user should be notified
rather loudly, I would expect.

On 8/20/26 7:29 PM, Kristoffer Haugsbakk wrote:
> On Thu, Aug 20, 2026, at 18:43, Artur Bieniek wrote:
>> One case where --ff-only does not seem to cover that audience is when
>> the upstream branch itself is rewritten.
>>
>> For example, a checkout may contain no local development at all and only
>> be used to track the latest state of an upstream branch, but if that
>> branch is rebased or otherwise force-updated, git pull --ff-only will
>> refuse to update it because the histories have diverged.
> > I don’t understand what you need a branch for in that case. I just use
> the remote-tracking branch in that case (`origin/main` e.g.).
> > PS: Bottom posting is strongly preferred on this list.
> >> ...


The branch itself is not essential; the point is to update the checked-out working tree as well. git fetch updates origin/main, but leaves the checkout at the old commit.

If resetting does not belong under pull, would the inverse design be more appropriate, e.g. git reset --pull --hard, meaning “fetch the configured upstream and reset to it”? Or would making reset perform network I/O be undesirable for the same reason?

Thanks,
Artur

Artur Bieniek <abieniek@antmicro.com> writes:

> If resetting does not belong under pull, would the inverse design be 
> more appropriate, e.g. git reset --pull --hard, meaning “fetch the 
> configured upstream and reset to it”? Or would making reset perform 
> network I/O be undesirable for the same reason?

Very true.  I wonder if the feature of git you should be looking at
for doing things like this is not "pull", "fetch", or "reset" but is
"alias"?