Menu
▾
▴
Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)
|
From: Stefan F. <ste...@we...> - 2012-02-01 17:37:49
|
Brett:
thanks for this excellent explanation.
So I got lucky that I have used a valid workflow from the beginning. And
indeed I applied the -x flag.
However I am still wondering if it would be possible to "rebase back to
the past"?
->J->K->L
/ \
A->B->C->D->H-I->M->N---------------->O
\
->E->F-G
If I understand rebase correctly the command (assume that J to L is
branch feature, A to O to master and G to maintenance)
rebase --onto maintenance master feature
should end up with same result?
A->B->C->D->H-I->M->N---------------->O
\
->E->F-G->P(J)->Q(K)->R(L)
Stefan
On 02/01/2012 05:37 PM, brett lentz wrote:
> 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
>
> ------------------------------------------------------------------------------
> 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
|
