I've found a case where git pull --rebase discards commits in my branch
if the remote-tracking branch was rewound (and the remote tracking
branch's reflog contains my branch's latest commit). This is due to
git-pull's usage of git merge-base --fork-point.
On one hand, this behaviour might be correct since the remote repository
essentially removed that commit from master by 'reset --hard'. On the
other hand, I was surprised that git pull --rebase discarded a commit in
my branch.
Tested on 1.9.1, 2.7.4 and 2.10-rc1.
Steps to reproduce:
# Set up initial repository
git init source
cd source
git config receive.denyCurrentBranch no # make 'git push' work - not
relevant to bug
echo hello > test
git add test
git commit -m "Initial commit."
# Clone repository, make and push two commits.
cd ..
git clone source clone
cd clone
echo greetings >> test
git commit -a -m "This commit is rewritten."
echo something >> test
git commit -a -m "This commit disappears."
git push origin master
# Discard the second and rewrite the first commit.
cd ../source
git reset --hard HEAD~ # remove "This commit disappears"
git commit --amend -m "This commit is a rewrite."
cd ../clone
# Observe that "This commit disappears" is still in our branch but
is not in origin/master
git fetch && git log --graph master origin/master
# Now git pull --rebase gets confused because origin/master used to
point to "This commit disappears",
# so it assumes that that was the fork point for master, and "This
commit disappears" is discarded.
git pull --rebase
git log --graph # "This commit disappears" is completely gone!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
