fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

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

> --
> Anders

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature