Feature Request: Fix/Make git-rebase work with git-subtree (was: Re: subtree merges lose prefix after rebase)

Hi All ~

This is sort of re-open of a 2012 thread:
http://git.661346.n2.nabble.com/subtree-merges-lose-prefix-after-rebase-td7332850.html

A related stackoverflow post that describes the problem & a
work-arounds/what was attempted to solve the problem:
http://stackoverflow.com/questions/12858199/how-to-rebase-after-git-subtree-add/23094756

I understand that git-subtree/git-rebase are currently working "as
intended," and sub-modules were, in theory, were intended to be a
replacement of subtrees.

However, I would like to request re-looking at the viability of making
the rebase example work as someone using a git-subtree should expect
it to.

I don't know enough of the under-the-hood detail of what it would take
to implement - but so far it looks like there's over 1k people on the
stackoverflow that have had the same issue I ran into & were looking
for a work-around.

Thanks,

Eric

On Thu, Mar 1, 2012 at 6:30 PM, Junio C Hamano [off-list ref] wrote:

Zakaria ElQotbi [off-list ref] writes:

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html