On Sun, Apr 21, 2019 at 02:38:38PM +0900, Junio C Hamano 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). It may be helpful to point out that this is essentially the workflow I had before I had only one computer. I would make some changes on my desktop, which was my primary computer, then need to travel somewhere and use my laptop. I would want to go back to my desktop when I returned home, because it was far more powerful, and I would know that I was the only user of this branch. Now, as a contributor and a moderately advanced user, I would likely end up using "git commit --fixup" (or "--squash") for this purpose and squash only before submitting, but there are situations where fixup commits cause conflicts and it's necessary to do a rebase and force push if you don't want extensive pain. So while I think that "git pull --rebase" or "git pull --ff-only" are probably better options in most situations, I can see the use in this command, with appropriate foresight and knowledge. I can also see how it's easy to blow away data with the proposed option, especially for novice users, who are likely not aware of how to restore it from the reflog. I'm not sure if this email is an argument for or against this option, but maybe it provides some helpful perspective. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
