Menu
▾
▴
Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)
|
From: Stefan F. <ste...@we...> - 2012-02-01 18:47:45
|
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 |
