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

From: Alex Henrie <alexhenrie24@gmail.com>
Date: Apr 21, 2019, 07:01 UTC
Message-ID: <CAMMLpeRnwrcjn3UAgs5p532pf8=xAwBqh2qg7Cfqun6qsqD06w@mail.gmail.com>
In-Reply-To: <xmqqftqbdijl.fsf@gitster-ct.c.googlers.com>

On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

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

Show 17 quoted lines

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

Show 7 quoted lines

> 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