Re: [PATCH v2] Give git-pull a --reset option

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

On 22/04/2019 00:38, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
>> It may be helpful to point out that this is essentially the workflow I
>> had ...
>> I'm not sure if this email is an argument for or against this option,
>> but maybe it provides some helpful perspective.
> 
> I think you and Phillip misread me.
> 
> I did not question if the workflow is common the message you are
> responding to.  I've done my fair share of "I know what I have on my
> laptop is stale as I pushed it out to elsewhere to continue working
> on it, so let's get rid of it from the updated upstream and start
> afresh" myself.
> 
> What I questioned was if it is sensible to ensure that it stays
> common.
> 
> We'd be encouraging the dangerous workflow, instead of analysing the
> situation where people employ it and trying to give them a better
> alternative to deal with the situation. 

I agree that it would be better to support this workflow in a safer 
manner. I use a script that looks at the reflog of the local and remote 
branches to work out if it is safe to reset --hard when pulling. If 
there are local changes since the last push/pull (because I forget to 
sync before starting work) then it will run rebase --onto <new-remote> 
<last-sync>. If the remote branch and local branches have both been 
rewritten it tells me to run range-diff to figure out how to fix it.

The value of <last-sync> is the most recent push or pull that updated 
the local branch. i.e. when both the local and remote refs pointed to 
the same commit at the same time (rebase complicates this as the remote 
we rebased onto does not appear in directly the local reflog - you have 
to look for "rebase .*finish.* <local-ref> <remote-oid>". Also an ide 
might auto fetch and update the remote ref while we're rebasing the 
local work which stops the reflog coinciding exactly.) The <last-sync> 
is also useful for making forced pushes safer. The script pushes with 
--force-with-lease=<ref>:<last-sync> if the local branch has been 
rewritten since the last sync so that any remote changes since the last 
sync are not overwritten.

Using the reflog to figure out the last sync makes forced pushes and 
pulls much safer. If we want to support this workflow in core git (and 
it does seem to be fairly common) then I think it needs to be based on 
something that prevents people from accidentally throwing away local 
changes when pulling and remote changes when pushing. There was some 
discussion of this with respect to pushing last summer[1]

Best Wishes

Phillip

[1] 
https://public-inbox.org/git/CAEFop40OJ5MRwM8zxE44yB0f2Fxw9YsUdM1e-H=Nn9e=sAGJ=w@mail.gmail.com/T/#u

  That is what we'd be doing
> with "pull --reset", i.e. an easier to type short-hand that robs the
> chance to double check in the middle of "fetch && inspect && reset"
> sequence.
> 
> As to where the feature should go, if we decide that it is a good
> idea to promote this workflow element as a supported feature, I
> agree with Alex's design in the patch that it makes sense to have it
> as "pull --reset".  Existing "pull --merge" and "pull -rebase" are
> "fetch and then integrate by merging theirs into ours" and "fetch
> and then integrate by rebasing our stuff on top of theirs"; the new
> "pull --reset" would fit well sitting next to them with its "fetch
> and then treat our stuff as valueless and replace it with theirs"
> semantics.
>