On Sun, Apr 21, 2019 at 02:38:38PM +0900, Junio C Hamano wrote:
> Alex Henrie <alexhenrie24@gmail.com> 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