As someone who has worked with a number of different version control systems (and have far more love for git than any other), I'm curious as to why we would want to fight what I've always seen as the core feature of git. Branching and merging. The gitflow model is incredibly useful for keeping track of a number of different development paths concurrently. Branches remained organized and have a clear destination and workflow that they need to go through as part of the merging process. We use it internally (on a much smaller team) with great success. And with the difficulties I've seen on the mailing list around the -forward branches and cherry-picking, I'm curious as to why this is the preferred method. From everything I've read about git and cherry-picking, it is a copy of the commit, not a reference to the original commit. This makes it hard to track down an individual change to find the original source.
Thanks, -Nate On Tue, Jul 8, 2014 at 11:04 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Thanks for bringing this up again, Sebastien. > > I've had http://nvie.com/posts/a-successful-git-branching-model/ up in > Chrome since you sent that link and been reading through it a bit here and > there, but have just been too busy as of late to give it a bunch of > thought. > > I agree, though, that we should really think about moving to another model > of using Git as it is not un-common for master to be broken, which leads to > a lot of lost development time for many people. > > > On Mon, Jun 30, 2014 at 4:09 PM, Sebastien Goasguen <run...@gmail.com> > wrote: > > > I would like to re-start this discussion. > > > > Rajani made some good points and someone mentioned Gitflow: > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > Thinking about our release procedure, we clearly need more tests and a > CI. > > However it looks like this is going to take some time. > > > > In the meantime I think there is nothing preventing us from agreeing to > > 'git practices', we don't need tests or new infra, we just need to agree > on > > the git workflow. > > > > Right now Master is really a development branch, we should make it a > > stable branch for production with very few commits. > > This does not mean that we would release less, in contrary this would > > ensure that a commit to master means it's a production release. > > > > In addition gitflow [1] does not do cherry-picks (gets back to Rajani's > > point) everything is based on merges. > > > > I am of the opinion that git flow provides a nice process. It basically > > freezes master. Development happens in a 'develop' branch, releases > > branches are branched off of that and merged into master and back into > > develop….etc > > > > Please read [1] it's a good read. > > > > And let's discuss, > > > > [1] http://nvie.com/posts/a-successful-git-branching-model/ > > > > -Sebastien > > > > On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <rajani.karut...@citrix.com > > > > wrote: > > > > > There is also the problem of cherry-picking. > > > As a contributor, I always endup creating multiple patches for each > > branch as they don’t cleanly apply on the upward branches. which means > > distinct commits for each branch and I don’t easily know which all > branches > > my commit exists unless I do grep. > > > if we follow merging strategy properly, apart from the first merge of > > the branch, everything else on top of it should be a painless merge. > > > > > > > > > > > > ~Rajani > > > > > > > > > > > > On 02-Jun-2014, at 10:51 pm, Marcus <shadow...@gmail.com> wrote: > > > > > >> I think many of the bullet points are what we are currently doing > > >> (guidelines for commit comments, feature branches need to stay in sync > > with > > >> master, no back-merging). I also think that much of what we do now is > > done > > >> the way it is simply because there *are* vast changes between > versions. > > >> Classes are getting shuffled around and changed all the time. If its > > >> feasible to merge branch fixes to master, that's fine, but some quick > > tests > > >> seem to indicate that this will be messy getting started. > > >> > > >> That leaves us with how we do releases. I'm fine with having single > > >> branches for major releases(4.3) and tagging the commits where each > > >> incremental release (4.3.x) is done. I'm trying to remember why we > went > > >> with the -forward, I'm sure it's in the mailing list somewhere, but > one > > of > > >> the nice things it provides is the ability for the release manager to > > >> control what changes are made during code freeze while giving people a > > >> place to stage fixes (though admittedly this is not always followed). > > >> Without -forward, would the flow be for each dev to have their own > repo > > and > > >> issue pull requests for bugfixes? > > >> > > >> > > >> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi < > > rajani.karut...@citrix.com> > > >> wrote: > > >> > > >>> Any other suggestions/objections/comments?? > > >>> Can we discuss this in detail and agree to a process?? > > >>> > > >>> > > >>> ~Rajani > > >>> > > >>> > > >>> > > >>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi < > > rajani.karut...@citrix.com> > > >>> wrote: > > >>> > > >>>> 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>*™* > > >>>> > > >>> > > >>> > > > > > > > > > > -- > *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>*™* > -- *Nate Gordon*Director of Technology | Appcore - the business of cloud computing® Office +1.800.735.7104 | Direct +1.515.612.7787 nate.gor...@appcore.com | www.appcore.com ---------------------------------------------------------------------- The information in this message is intended for the named recipients only. It may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message is strictly prohibited. If you have received this e-mail in error, do not print it or disseminate it or its contents. In such event, please notify the sender by return e-mail and delete the e-mail file immediately thereafter. Thank you.
