Re: subtree merges lose prefix after rebase

Zakaria ElQotbi [off-list ref] 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.