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