Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

The problem is all of the commits in between (The C->N commits). This
is, admittedly, where my experience with git runs a little thin, so
please feel free to test this out on your local repositories. (Hooray
distributed SCM!)

I *believe* what will happen if you rebase onto the maintenance
branch, then merge after first having rebased onto master, will look
something like this...

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

Where P is another merge commit, just like O.

Feel free to test this out and prove me right/wrong. :-) However, I'm
pretty sure this is what will happen because git doesn't know or care
about the context of the commits, but only cares about their
parent/child relationships. So, once you've rebased your local branch
onto the latest master, the parent commit of J *is* N, and so when you
rebase onto the maintenance branch, it sees that the shared point C
begins to diverge at D/E and, therefore from D to N is considered "new
work" relative to the maintenance branch, exactly the same as the J to
L commits that you really want on the maintenance branch.

I think the way around this is to create *two* private feature
branches, rebase one onto master and rebase the other onto the
maintenance branch, and either merge or cherry-pick your commits
between your two private feature branches in whatever way makes sense
in your work flow.

---Brett.

On Wed, Feb 1, 2012 at 12:37 PM, Stefan Frey <ste...@we...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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