Some developers (including myself) prefer to use the "always rebase" configuration option for git pull, which avoids creating superfluous merge commits from un-pushed commits when pulling to a local branch from the same corresponding remote branch. This doesn't cause issues as long as you pull to the same corresponding branch, since the local un-pushed commits don't have remote counterparts yet and commit hashes won't be rewritten.
However, this does cause issues when pulling from a remote branch that is different from the local destination branch, since it's effectively rebasing local changes onto a totally different remote HEAD, which can cause commits to be rewritten.
I propose changing git update and any other command that attempts to pull from a different remote branch to use
git pull origin <upstream_branch> --no-rebase
or alternatively
git fetch origin <upstream_branch>
git merge origin/<upstream_branch>
since that's effectively what the pull should be doing.
Some developers (including myself) prefer to use the "always rebase" configuration option for
git pull, which avoids creating superfluous merge commits from un-pushed commits when pulling to a local branch from the same corresponding remote branch. This doesn't cause issues as long as you pull to the same corresponding branch, since the local un-pushed commits don't have remote counterparts yet and commit hashes won't be rewritten.However, this does cause issues when pulling from a remote branch that is different from the local destination branch, since it's effectively rebasing local changes onto a totally different remote HEAD, which can cause commits to be rewritten.
I propose changing
git updateand any other command that attempts to pull from a different remote branch to useor alternatively
since that's effectively what the pull should be doing.