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

> On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Alex Henrie <alexhenrie24@gmail.com> writes:
>>
>>> A common workflow is to make a commit on a local branch, push the branch
>>> to the remote, check out the remote branch on a second computer, amend
>>> the commit on the second computer, force-push back to the remote branch,
>>> and finally submit a pull request. However, if the user switches back to
>>> the first computer, they must then run the cumbersome command
>>> `git fetch && git reset --hard origin`.

>> Doesn't anybody sense there is a larger problem if such a workflow
>> is "common" in the first place?  In that sequence, when you come
>> back to the first repository there is no guarantee that what you are
>> losing is exactly what you are willing to lose and nothing else
>> (i.e. your earlier WIP you sent to the second repository, which was
>> further polished, making the earlier WIP you had here irrelevant).

> You may be right. On the other hand, you're expected to think about
> what you're doing before running `git push --force` and clobbering a
> remote branch. Similarly, you would be expected to think about what
> you're doing before running `git pull --reset` and clobbering a local
> branch. It's actually easier to recover from accidentally clobbering a
> local branch than accidentally clobbering a remote branch because you
> can use `git reflog` to find the lost commits.
>
>> If the last "recovery at the first repository" step were "pull --rebase",
>> at least you would realize that you have the earlier WIP locally
>> that either
>>
>>      (1) conflicts with the more polished work that have been
>>          accepted at the upstream, in which case you can tell the
>>          rebase machinery to drop that earlier WIP _after_ making
>>          sure that it is only that stale WIP you not only are willing
>>          to but actively do want to lose that is getting discarded.
>>
>>      (2) replays cleanly on top of the updated upstream, which hasn't
>>          accepted your pull request made from the second repository
>>          with the more polished version, in which case you'd realize
>>          that you may have to work on the topic further.  And you
>>          have a chance to inspect what you ended up with before using
>>          "reset --hard" or "rebase -i" to discard what you no longer
>>          need.
> I understand that `git pull --rebase` followed by `git rebase --skip`
> is a safer workflow. I just feel like an option like `git pull
> --reset` should be there for users who know what they're doing, just
> like `git push --force` is available for users who know what they're
> doing.
>
>> At least, I think the longhand this attempts to replace, "fetch"
>> followed by "reset --hard origin" is better because of two reasons.
>> It is more explicit that the procedure is destructive, and more
>> importantly, it can allow to have (and we should encourage users to
>> make a habit to have) an extra step to inspect what the user is
>> about to lose with "git log origin.." after "fetch" but before
>> "reset --hard".
> I'd be happy to emphasize the destructive nature of this option by
> calling it `git pull --hard-reset` instead.
>
>> So I have a moderately strong suspicion that "git pull --reset"
>> promotes a wrong workflow and should not exist.
> It'd be great to get some feedback from other Git users, but in the
> end it's up to you and I trust your decision.
>
> -Alex