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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to