Web lists-archives.com

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

On 22/04/2019 00:38, Junio C Hamano wrote:
"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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

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


[1] https://public-inbox.org/git/CAEFop40OJ5MRwM8zxE44yB0f2Fxw9YsUdM1e-H=Nn9e=sAGJ=w@xxxxxxxxxxxxxx/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"

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"