Re:Git Tricks: Avoiding merge when dealing with remote confl...
by kazinator on Monday October 21, 2019 @07:54PM
(#21318901)
I did that until about 9 years ago. It was too annoying and error-prone (due to forgetting to set that up in new environments, or in some cases not being able to, like in some build machine account or whatever).
Instead I simply learned not to use git pull. I always pick up new changes with git fetch, followed by git rebase.
Just purely out of computer science principle, I want to avoid commands that bundle multiple unrelated operations and behave differently based on magic globals.
If I notice upstream has been forced (shouldn't happen in any well-run public repos), I tread carefully. Instead of just a git rebase, I will do something like git rebase HEAD~3 --onto origin/master. (If 3 of the top commits are my local ones.) That tries to transplant the 3 commits onto the new material coming from the remote. Basically, reset to the remote, then cherry-pick my commits.
Instead I simply learned not to use git pull. I always pick up new changes with git fetch, followed by git rebase.
Just purely out of computer science principle, I want to avoid commands that bundle multiple unrelated operations and behave differently based on magic globals.
If I notice upstream has been forced (shouldn't happen in any well-run public repos), I tread carefully. Instead of just a git rebase, I will do something like git rebase HEAD~3 --onto origin/master. (If 3 of the top commits are my local ones.) That tries to transplant the 3 commits onto the new material coming from the remote. Basically, reset to the remote, then cherry-pick my commits.