subtree merges lose prefix after rebase

subtree merges lose prefix after rebase

[Zakaria ElQotbi]

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

Re: subtree merges lose prefix after rebase

[Junio C Hamano]

Zakaria ElQotbi <zakaria@elqotbi.com> 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.