Web lists-archives.com

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

Alex Henrie <alexhenrie24@xxxxxxxxx> 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).

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

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.