Hello,
$ git --version
git version 1.9.3
Please consider the following history:
--C--
/ \
/ ----M topic,HEAD
/ /
A---B master
shouldn't
$ 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
--
Sergey.
--
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
