$ git --version
git version 1.9.3

Please consider the following history:

    /     \
   /   ----M topic,HEAD
  /   /
 A---B master


$ git rebase master

be a no-op here? According to my reading of the rebase manual page, it
should be a no-op, as 'topic' is a descendant of the 'master'. Instead,
"git rebase master" flattens the history to:

       ----C topic,HEAD
 A---B master

I'd expect --force-rebase to be required for this to happen:

-f, --force-rebase
    Force the rebase even if the current branch is a descendant of the
    commit you are rebasing onto. Normally non-interactive rebase will
    exit with the message "Current branch is up to date" in such a
    situation. Incompatible with the --interactive option.

Also notice that:

$ git rebase --preserve-merges --verbose master

does perform the rebasing work, even though it does not change the
history in the end.

Here is use-case where it came from and where it gave me real surprise:

I have pull.rebase=true in configuration. Being on a remote tracking
branch, I've successfully pulled from the origin and had no any local
changes on this branch. Then I've successfully merged another branch to
the current one but didn't push the changes back upstream. A few hours
later I returned to the work and issued "git pull" that instead of doing
nothing (as it would be should pull.rebase be either "false" or
"preserve") created a surprising mess.

Do you think it's worth fixing?

Here are reproduction commands for the example history:

git init t
cd t
echo A > a
echo B > b
git add a b
git commit -m A -a
git checkout -b x
echo A >> a
git commit -m C -a
git checkout master
echo B >> b
git commit -m B -a
git checkout -b topic
git merge -m M x
git branch -d x
git rebase master

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