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