Hello, A fast forward merge does not create a single merge commit but takes all commits and applies them to the current branch.[1] So this will do what Jeff intended without the necessity of deleting and recreating a static tag or editing version numbers in update scripts. ;)
Regards Christoph [1] http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html ----- Original Message ----- From: "Gilles Gouaillardet" <gilles.gouaillar...@iferc.org> To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org> Sent: Monday, June 30, 2014 4:06:34 AM Subject: Re: [MTT devel] MTT: let's use git tags Jeff, What i meant by "less error prone" is "you use the stable branch by default" so you do not checkout the dev/unstable branch by default. as you pointed, the level/frequency of MTT development is fairly low, my idea would be to create a "dev" branch, and when the state of the dev branch is "production ready", simply do a git checkout master git merge dev that being said, i am far from mastering git and i cannot judge the pros vs cons of this (merge) versus the fast forward approach pointed by Christoph Cheers, Gilles On 2014/06/27 16:11, Christoph Niethammer wrote: > +1, for a stable branch which is *fast forwarded* to master when changes are > confirmed to work. > PS: Tags are intended to be static and not moved around in git as Dave says, > instead you can sign them using gpg fortifying them even more. ;) > > ----- Original Message ----- > From: "Dave Goodell (dgoodell)" <dgood...@cisco.com> > To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org> > Sent: Thursday, June 26, 2014 2:47:35 PM > Subject: Re: [MTT devel] MTT: let's use git tags > > Published Git tags are *not* movable (by design). You're better off making it > a branch that you treat like a tag, if that's your desire. Even then, you > might confuse someone who is less familiar with Git in some cases if you move > that branch around. > > -Dave > >> On Jun 26, 2014, at 6:06 AM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> >> wrote: >> >> I've thought about this a little, and I'm still inclined to use the >> simple/lazy method of tags on master. Some random points, in no particular >> order: >> >> 1. master should always be for development, IMHO. If we start using a >> multi-branch scheme, then the branches should be for releases, etc. >> >> 2. MTT has always been distributed by VCS; we've never made discrete >> distributions (e.g., a tarball). As such, I'm comfortable labeling it as a >> bit "different" than how most other software is delivered -- e.g., using git >> tags on master is "good enough". >> >> 3. The level/frequency of MTT development is fairly low; it would be good to >> keep the bar as low as possible for amount of work required to deploy a new >> feature to the OMPI community for MTT testing. Meaning: a new feature or >> bug fix pops up in MTT every once in a while -- we generally don't have >> commits that are being developed and merged to a release series in an >> out-of-order fashion. So doing a few commits for a new feature/bug fix and >> then tagging the result is fine/good enough. If there *are* interleaved >> commits of multiple new features/bug fixes, we can simply wait until all are >> done before tagging. >> >> 4. I realize this scheme is not as flexible as a release branch (where you >> can merge new features/bug fixes out of order), but the level of MTT >> development is so low that I'd prefer the slightly-simpler model of just >> tagging (vs. merging/etc.). >> >> 5. I'm not sure how using a release branch is less error-prone...? I >> understand git branching is cheap, but if we have a separate branch, then we >> either need to remember to cherry-pick every commit we want or we have to >> continually merge from master->release_branch. Seems like more work/steps >> to follow, and therefore more error-prone. >> >> 6. The point about not being able to automate getting the latest stable MTT >> is a good one. How about using numerical tags just to delineate our >> intended "release" points, but also have a moveable tag, e.g., >> "ompi-mtt-testing" that will always point to the latest "release" that we >> want the OMPI MTT test community to use? That way, you can always "git >> checkout ompi-mtt-testing" to get the latest/greatest. >> >> (...to that end, I've created/pushed an ompi-mtt-testing tag and pointed to >> the same place as v3.0.0) >> >> >> >>> On Jun 24, 2014, at 8:30 PM, Gilles Gouaillardet >>> <gilles.gouaillar...@iferc.org> wrote: >>> >>> +1 for using branches : branch usage is less error prone plus git makes >>> branching unexpensive. >>> >>> as far as i am concerned, i'd rather have the default master branch is >>> the for the "stable" version >>> and have one branch called devel (or dev, or whatever) : >>> - git clone => get the stable (aka master) branch by default (safe by >>> default) >>> - if you use the devel branch, one can only assume you know what you are >>> doing ... >>> >>> That being said, tags on the master branch is a good practice >>> >>> Cheers, >>> >>> Gilles >>> >>>> On 2014/06/25 2:33, Christoph Niethammer wrote: >>>> As an alternative idea: What about using branches to mark "stable" and >>>> "development"? >>>> Tags are for fixed versions and so users will not receive updates unless >>>> they update their update scripts manually?! >>>> When "development" is stable just merge into "stable". >>> _______________________________________________ >>> mtt-devel mailing list >>> mtt-de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0636.php >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mtt-devel mailing list >> mtt-de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel >> Link to this post: >> http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0639.php > _______________________________________________ > mtt-devel mailing list > mtt-de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel > Link to this post: > http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0640.php > _______________________________________________ > mtt-devel mailing list > mtt-de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel > Link to this post: > http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0642.php _______________________________________________ mtt-devel mailing list mtt-de...@open-mpi.org Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel Link to this post: http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0642.php
