Re: subtree merges lose prefix after rebase
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 1, 2012, 18:30 UTC
- Message-ID
- <7vboognph1.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CALtv3HqtdUrRaGWvrwo89r3y1RQ4wy1Bzt5=RhQHaJTXS3gk9A@mail.gmail.com>
Zakaria ElQotbi <zakaria@elqotbi.com> writes:
Show 15 quoted lines
> why subtree merges lose prefix after an interactive rebase, is it a known > issue ? or I'am missing somethings: > ... > $ git rebase -i -p a6d4e8e # this the hash of "merge b" commit > $ git commit --amend -m "merge b edit" > $ git rebase --continue > $ tree > . > |-- C > |-- projects > | |-- a > | | `-- A > | `-- b > | `-- B > `-- README
Rebase essentially is a stepwise cherry-pick, and cherry-pick does not see anything but the trees recorded in the commit being rebased and in its parent.
Your original history is to merge in projects a, b and c in order, renaming them using subtree merge to their own subdirectory. You rebase the commits after the one that merges b, i.e. the merge of project c, in that history. As far as that rebased commit is concerned, the change it makes relative to its parent commit is to add file C at the root level. So you are starting from the state you merged a and b into the whole project, and replaing that commit that adds C at the root level. That matches the above picture.
In short, this is expected, because rebase does not know anything about evil merges made by 'subtree' (or 'ours' for that matter). And I do not think there is any plan to make rebase aware of subtree merges. After all, subtree merge was invented merely as a short-term hack to serve as a stop gap measure until submodule support becomes mature.