Is there a difference between these three? git-flow man 7 gitworkflows PETSc workflow
Or are they all the same thing? -- Anders On Thu, Apr 11, 2013 at 09:14:47AM +0800, Garth N. Wells wrote: > The PETSc developers have laid out their approach, which includes > fixes to releases: > > https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git > > Maybe we should follow their approach, and piggy back on their > easy-to-follow development model documentation? Over time we can > evolve our own workflow if required. > > Garth > > On 11 April 2013 02:32, Florian Rathgeber <florian.rathge...@gmail.com> wrote: > > On 10/04/13 16:29, Anders Logg wrote: > >> On Wed, Apr 10, 2013 at 02:55:13PM +0200, Martin Sandve Alnæs wrote: > >>> I've just pushed a critical bugfix to ufl on bitbucket, which should > >>> be backported (cherry-picked) to 1.2. What's the procedure for this > >>> now? Do we apply patches to the old lp series? Is there a 1.2 git > >>> branch I can cherry-pick directly to? > >> > >> There's no such branch. But if we decide to follow the gitflow model, > >> we should create a new branch called 'develop' inside the ufl > >> repository (the branch 'master' already exists). > > > > Note that you can very easily resurrect any revision as any branch: > > $ git branch <branch-name> <revision> > > > > But gitflow doesn't have long lived release branches: > > > >> All releases should be made from the 'master' branch and all > >> development in the 'develop' branch. Before each release, one branches > >> off 'develop' via a release branch and then into 'master'. Then after > >> the release, the release branch gets removed. > >> > >> http://nvie.com/posts/a-successful-git-branching-model/ > > > > The release branch only lives for as long as it takes to finalise the > > release, at which point it is merged into master and that revision of > > master is tagged with the release and the branch removed. > > > >> What is needed for a fix like this is to make a temporary 'hotfix' > >> branch off 'master'. So my suggestion would be to > >> > >> 1. Create the 'develop' branch (from 'master') > >> > >> 2. Create a branch 'hotfix-1.2.1' from master > >> > >> 3. Fix the bug there (cherry pick from 'develop') > >> > >> 4. Merge the fix into 'develop' and 'master' > >> > >> 5. Remove the hotfix branch > >> > >> Steps 3-4 will be a bit different since you already made the fix in > >> 'master'. > > > > I wouldn't retrospectively try to hammer history into gitflow shape. > > Instead I would tag e21d9f6 as release 1.2.1 and start gitflow from > > there i.e. make this also the tip of the dev branch (so this revision > > will the the last revision ever where dev and master will point to the > > same revision) and only work on dev from then on. > > > > # assuming you're on e21d9f6 > > $ git tag 1.2.1 # tag the current revision > > $ git branch dev # create a new branch starting at the current revision > > $ git push --tags -u origin dev > > > > Florian > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~fenics > > Post to : fenics@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~fenics > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
