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