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

From: Eric Peters <eric@peters.org>
Date: Jun 6, 2014, 15:41 UTC
Message-ID: <CADbXawuVx4-9ujYFEgaX8EML05pZdcfDAN9FZdHBWHQ6WS6U+g@mail.gmail.com>

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 <gitster@pobox.com> wrote:

Show 41 quoted lines

>
> 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.
> --
> 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