Re: [PATCH] pull: add --hard mode

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 <[email protected]> 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.