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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:
>
> Zakaria ElQotbi <zakaria@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]