subtree merges lose prefix after rebase

Hi, folks! why subtree merges lose prefix after an interactive rebase, is it a known issue ? or I'am missing somethings:

$ for project in a b c ; do
    mkdir $project
    ( cd $project ; git init; touch ${project^} ; git add ${project^}
; git commit -m "add ${project^}" )
   done
$ tree
.
|-- a
|   `-- A
|-- b
|   `-- B
`-- c
    `-- C

$ mkdir tree && cd tree && git init
$ touch README && git add README && git commit -m "add readme"
$ for project in a b c ; do
  mkdir -p projects/$project
  git remote add -f $project ../$project
  git merge -s ours --no-commit $project/master
  git read-tree --prefix=projects/$project -u $project/master
  git commit -m "merge $project into tree"
  git pull -s subtree $project master
 done

$ tree
.
|-- projects
|   |-- a
|   |   `-- A
|   |-- b
|   |   `-- B
|   `-- c
|       `-- C
`-- README

$ 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

Best regards -- Zakaria ElQotbi 4096R/3DC2241A

"The secret of creativity is knowing how to hide your sources."
        - Albert Einstein

Zakaria ElQotbi <zakaria@elqotbi.com> writes:

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.