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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2019, 05:38 UTC
Message-ID: <xmqqftqbdijl.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190421040823.24821-1-alexhenrie24@gmail.com>

Alex Henrie <alexhenrie24@gmail.com> writes:

Show 6 quoted lines

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

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.

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

So I have a moderately strong suspicion that "git pull --reset" promotes a wrong workflow and should not exist.