Menu
▾
▴
Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)
|
From: brett l. <bre...@gm...> - 2012-02-01 20:09:30
|
Awesome. I'm actually happy to be wrong on this. It's nice to see that git is smart enough to not bring in unrelated changes. Thanks for testing this. :-) ---Brett. On Wed, Feb 1, 2012 at 1:47 PM, Stefan Frey <ste...@we...> wrote: > Brett: > I did test it and actually it works as I wished it work: It only takes > the commits from feature after it branched from master and applies those > on top of the maintenance branch. And it does not add anything from > those commits from the time between where maintenance branched until > feature branched. > > So the workflow for a hotfix is: > > git checkout -b feature > ... code & commit ... > git rebase master > git checkout master > git merge feature > > followed by > > git rebase --onto maintenance master feature > git checkout maintenance > git merge feature > > How is this possible? > You are right that git only cares about node relationships, however with > three arguments to rebase git can figure out what do: > > Looking at the history of master and maintenance git knows that > the latter branched after D. > Looking at the history of master and feature git knows that the > latter branched after N. > > Combining that information git knows that the commits between D and N > are actually not "new" part of feature. > > Stefan > > > On 02/01/2012 06:55 PM, brett lentz wrote: >> 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 >> >> ------------------------------------------------------------------------------ >> 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 |
