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

[Phillip Wood <phillip.wood123@gmail.com>]

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.
>