{"thread":{"id":"36858","subject":"Feature Request: Fix/Make git-rebase work with git-subtree (was: Re: subtree merges lose prefix after rebase)","startedAt":"2014-06-06T15:41:26Z","lastAt":"2014-06-06T15:41:26Z","messageCount":1,"participants":["Eric Peters"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"243497","messageId":"CADbXawuVx4-9ujYFEgaX8EML05pZdcfDAN9FZdHBWHQ6WS6U+g@mail.gmail.com","threadId":"36858","inReplyTo":null,"subject":"Feature Request: Fix/Make git-rebase work with git-subtree (was: Re: subtree merges lose prefix after rebase)","fromName":"Eric Peters","fromEmail":"eric@peters.org","sentAt":"2014-06-06T15:41:26Z","receivedAt":"2014-06-06T15:41:26Z","isPatch":false,"sender":{"key":"eric@peters.org","avatar":null},"body":"Hi All ~\n\nThis is sort of re-open of a 2012 thread:\nhttp://git.661346.n2.nabble.com/subtree-merges-lose-prefix-after-rebase-td7332850.html\n\nA related stackoverflow post that describes the problem & a\nwork-arounds/what was attempted to solve the problem:\nhttp://stackoverflow.com/questions/12858199/how-to-rebase-after-git-subtree-add/23094756\n\nI understand that git-subtree/git-rebase are currently working \"as\nintended,\" and sub-modules were, in theory, were intended to be a\nreplacement of subtrees.\n\nHowever, I would like to request re-looking at the viability of making\nthe rebase example work as someone using a git-subtree should expect\nit to.\n\nI don't know enough of the under-the-hood detail of what it would take\nto implement - but so far it looks like there's over 1k people on the\nstackoverflow that have had the same issue I ran into & were looking\nfor a work-around.\n\nThanks,\n\nEric\n\nOn Thu, Mar 1, 2012 at 6:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Zakaria ElQotbi <zakaria@elqotbi.com> writes:\n>\n> > why subtree merges lose prefix after an interactive rebase, is it a known\n> > issue ? or I'am missing somethings:\n> > ...\n> > $ git rebase -i -p a6d4e8e # this the hash of \"merge b\" commit\n> > $ git commit --amend -m \"merge b edit\"\n> > $ git rebase --continue\n> > $ tree\n> > .\n> > |-- C\n> > |-- projects\n> > |   |-- a\n> > |   |   `-- A\n> > |   `-- b\n> > |       `-- B\n> > `-- README\n>\n> Rebase essentially is a stepwise cherry-pick, and cherry-pick does not see\n> anything but the trees recorded in the commit being rebased and in its\n> parent.\n>\n> Your original history is to merge in projects a, b and c in order,\n> renaming them using subtree merge to their own subdirectory.  You rebase\n> the commits after the one that merges b, i.e. the merge of project c, in\n> that history.  As far as that rebased commit is concerned, the change it\n> makes relative to its parent commit is to add file C at the root level.\n> So you are starting from the state you merged a and b into the whole\n> project, and replaing that commit that adds C at the root level.  That\n> matches the above picture.\n>\n> In short, this is expected, because rebase does not know anything about\n> evil merges made by 'subtree' (or 'ours' for that matter).  And I do not\n> think there is any plan to make rebase aware of subtree merges.  After\n> all, subtree merge was invented merely as a short-term hack to serve as a\n> stop gap measure until submodule support becomes mature.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}