Zakaria ElQotbi <zakaria@xxxxxxxxxxx> writes: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html