Hi All ~
This is sort of re-open of a 2012 thread:
A related stackoverflow post that describes the problem & a
work-arounds/what was attempted to solve the problem:
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
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.
On Thu, Mar 1, 2012 at 6:30 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Zakaria ElQotbi <zaka...@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
> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html