Hi Alex
On 21/04/2019 08:01, Alex Henrie wrote:
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`.
This will be quite a common occurrence especially for personal repos on
one of the hosting sites (GitHub, GitLab, etc), so we know that we are
the only user of that repo.
I've certainly used that style of technique for Windows vs Linux machine
transfers of Git work (when my old hack linux machine is functional:-).
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).
I'd agree that a public/joint repository could have issues if a user
blindly assumes that no one has cooperated with them and added more
commits, but that becomes a social issue (plus worthy of a documentation
mention!).
There are still a few blind spots in the functionality of Git regarding
how users interact with their hosting provider, which is trying to be
(from a user perspective) both a backup and an independent repo (side
discussion at Git Merge). This would appear to be one of those cases
where one is collaborating with no-one (oneself), but from two machines.
It may just be that we need to put aside `pull` because of its old
semantics, and start with a fresh command name for the 'fetch + sort
stuff out' for these use cases.
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
I though it worth chiming in that folks do use these simple dumb use cases.
--
Philip
