Yes as mike said, if its a one-off case we can do a empty merge(merge -s ours) for it and git will assume its merged but will not bring in any changes.
If the branches diverged a lot, for example after a major rewrite, we could stop merging to that branch and above and make the fix manually. ~Rajani On 30-May-2014, at 11:26 pm, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Yep, that's what I was referring to in that a particular fix for an old > release may not apply to newer versions. That does happen. > > We used to mark those as "don't need to merge to branch x" in SVN and then > you handed it however made sense on the applicable branch(es). > > > On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <stephen.tur...@citrix.com> > wrote: > >> What happens if a fix isn't relevant for newer versions, or has to be >> rewritten for newer versions because the code has changed? Don't the >> branches diverge and you end up cherry-picking after that? >> >> -- >> Stephen Turner >> >> >> -----Original Message----- >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >> Sent: 30 May 2014 18:48 >> To: dev@cloudstack.apache.org >> Subject: Re: [PROPOSAL] git workflow >> >> I think this flow is something we should seriously consider. >> >> I find cherry picking from branch to branch to be error prone in that it's >> easy for someone to forget to cherry pick to all applicable branches and >> you don't have any easy way to see the cherry picks are related. >> >> When I worked at HP, we had automated tools check to see if you checked a >> fix into a prior release, but not later releases. In such a situation, you >> either 1) forgot to perform the check-in or 2) the check-in was no longer >> applicable in the later release(s), so you needed to mark it as >> un-necessary (SVN supported this ability...not sure about Git). >> >> >> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < >> rajani.karut...@citrix.com> wrote: >> >>> Hi all, >>> >>> >>> >>> Our current git workflow is confusing with the *forward branches and >>> cherry-picking. Its hard to track on what all releases the commit has >>> gone into unless I do some git log greping. Also, as a contributor, I >>> endup creating patches for each branch as it doesn’t cleanly apply on >>> different branches. >>> >>> >>> >>> I think we should have some guidelines. Here is what I propose. >>> >>> >>> >>> 1. There should be branch for every major release(ex: 4.3.x, 4.4.x, >>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on >>> the respective branches. >>> 2. The branch naming convention is to be followed. Many branches >>> with 4.3, 4.3.0, 4.3.1 etc. is confusing >>> 3. Cherry-picking should be avoided. In git, when we cherry-pick, >>> we have two physically distinct commits for the same change or fix and >>> is difficult to track unless you do cherry-pick -x >>> 4. There should always be a continous flow from release branches to >>> master. This doesn’t mean cherry-picking. They should be merged(either >>> ff or no-ff) which retains the commit ids and easily trackable with >>> git branch --contains >>> * Every bug fix should always flow from minimal release uptill >>> master. A bug isnt fixed until the fix reaches master. >>> * For ex. A bug 4.2.1 should be committed to >>> 4.2.x->4.3.x->4.4.x->master >>> * If someone forgets to do the merge, the next time a new commit >> is >>> done this will also get merged. >>> 5. There should always be a continuous flow from master to feature >>> branches. Meaning all feature branch owners should proactively take >>> any new commits from master by doing a merge from master >>> 6. The commits from feature branch will make to master on code >>> complete through a merge. >>> 7. There should never be a merge from master to release branches >>> 8. Every commit in LTS branch(targetted to any minor release) >>> should have atleast bug id and correct author information >>> * Cassandra's template: patch by <author>; reviewed by <committer> >>> for CASSANDRA-<ticket> >>> 9. Once the release branch is created(after code freeze), any bug >>> in jira can be marked with fix version current release(4.4) only on >>> RM's approval and only they can go to the release branch. This can be >>> done through jira and with certain rules.(may be using jira vote?) >>> this would save the cherry-picking time and another branch maintenance. >>> >>> >>> >>> Please add your thoughts/suggestions/comments. >>> >>> >>> >>> Ref: >>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html >>> https://www.youtube.com/watch?v=AJ-CpGsCpM0 >>> >>> ~Rajani >>> >>> >>> >>> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™*
