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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Apr 22, 2019, 15:14 UTC
Message-ID: <02595523-3b16-b434-1ea9-a9399d7f1783@gmail.com>
In-Reply-To: <xmqqftqb9bf1.fsf@gitster-ct.c.googlers.com>

On 22/04/2019 00:38, Junio C Hamano wrote:

Show 21 quoted lines

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

Show 14 quoted lines

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