rebase flattens history when it shouldn't?
- From
- Sergei Organov <osv@javad.com>
- Date
- Jul 23, 2014, 13:34 UTC
- Message-ID
- <87k374xkpq.fsf@osv.gnss.ru>
Hello,
$ git --version git version 1.9.3
Please consider the following history:
--C--
/ \
/ ----M topic,HEAD
/ /
A---B mastershouldn'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 masterI'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.