Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[brett l. <bre...@gm...>]

So...  there's a couple ways to do this, depending on what end-result we want.

As Stefan mentions, cherry-picking is one of the better options for
this. Changes should be merged into master, and then cherry-picked
into the feature branch. Ideally, all cherry-picks should use the "-x"
flag, which appends a line to your commit message saying where it was
cherry-picked from. This is important because, otherwise, cherry-picks
are commits that are wholly disconnected from their parent commit, so
the chain of history is not well-preserved with cherry-picks.

Remember, git cares about *history* far more than it does about any
particular change. It tracks changes by parent-child relationships, so
we need to be aware of when we're breaking that relationship.

This is also what makes rebasing against two different branches
somewhat problematic. Here's an example. (Hopefully my bad ascii art
displays correctly on your side)

Imagine commits in master look something like this:

A -> B -> C -> D

Then, we create a release, and create a maintenance branch for the release:

A->B->C->D->H-I
           \
            ->E->F-G

Now, let's say more work is done, including some work I've done on a
feature in my own local branch:

                      ->J->K->L
                     /
A->B->C->D->H-I->M->N
           \
            ->E->F-G


So...  now let's say I rebase my local branch against master. This
rewinds my local branch to the common point in both branch's history
(H), then replays the commits that were in master so my local branch
"catches up", like so:

                                   ->J->K->L
                                  /
A->B->C->D->H-I->M->N
           \
            ->E->F-G

Git has reordered the history on my local branch. This is important
because most traditional SCMs don't allow you to rewrite history. Git
does, but it expects you to understand that this is what you're doing.

This allows me to now merge my changes into master cleanly at the most
current point in the history:

                                   ->J->K->L
                                  /               \
A->B->C->D->H-I->M->N---------------->O
           \
            ->E->F-G

Note, O is a merge commit that has no content of it's own, but marks
the point in the history where there is multiple parents.

So, now the question is... how do I get my changes into the maintenance branch?

If I rebase my local tree a second time, git will again rewind to the
common ancestor (C) and... it will see all of the new changes from
master as if they were changes I had made in my local branch, because
they are not common to the maintenance branch. This means that a bunch
of stuff from master will be brought into the maintenance branch.

Maybe that's what we want, and maybe it isn't.

However, the alternative is to cherry-pick *only* my changes out of
either master or my local branch, divorce them from the history, and
append them into the maintenance branch, like so:


                                   ->J->K->L
                                  /               \
A->B->C->D->H-I->M->N---------------->O
           \
            ->E->F-G->P(J)->Q(K)->R(L)


Hopefully that helps. :-)

---Brett.



On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey <ste...@we...> wrote:
> Frederick:
> My solution for this currently is to git cherry-pick the
> bug-fix commit into the 1.6.x branch.
>
> Usually bug fixes do not effect lots of file, and if there
> is a conflict it is usually easy to resolve.
>
> But the main reason for this solution is that usually I receive the
> bug-fixes as already merged into master.
>
> Should it not be possible to first rebase on master, then revert that
> rebase and then rebase on 1.6.x.?
>
> However I am curious if Brett has a better recommendation.
>
> Stefan
>
>
>
> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>> Brett:
>> So what would be the git command sequence when wanting to create a fix
>> in a separate branch which is to be merged back to both 1.6.x and
>> master (You could copy-paste aforementioned order as a template)?
>>
>> If rebasing is done before merging into 1.6.x and master, the hotfix
>> commit will be altered (and not be the same as used in 1.6.x).
>> Probably no big issue as 1.6.x and master will never be merged again.
>>
>> --Frederick
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel