On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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). 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
