Fast forward master branch (if possible) when releasing

[danielcompton]

We use shell scripts wrapping git flow release for our release processes. If the developer doing the release hasn't kept their local master pointing to the origin master, then git flow release finish will fail with the message

Branches 'master' and 'origin/master' have diverged.
Fatal: And branch 'master' may be fast-forwarded.

If master can be fast forwarded, does it make sense to have this done so (either automatically or with a command line option?)

[petervanderdoes]

I think I could add a parameter to automatically fast-forward master, something like

git flow release finish --ff-master

[IDisposable]

Can we possibly make the --ff-master a defaultable setting?

[petervanderdoes]

Yes. All flags can be set to a default state.

[juliusbachnick]

Hey,

Is there any progress regarding this issue?

[petervanderdoes]

I'm currently in a relocation process, I'll get back to the issues soon.

[petervanderdoes]

Implemented in commit a5c3724

Please test thoroughly and let me know if it works :)

[jluttine]

Perhaps I've misunderstood this feature, but I tried and master branch wasn't fast-forwarded. I was expecting that there would be no merge commit from release branch to master branch: the master branch should be fast-forwarded to the last commit in the release branch. Or have I misunderstood? At least that's a feature I'd be very much interested in: no merge commits to master, just fast forward.

Anyway, to reproduce:

git init
git flow init
touch foo
git add foo
git commit -am "add foo"
git flow release start 0.1
touch version
git add version 
git commit -am "add version"
git flow release finish --ff-master 0.1

This creates a merge commit on master.

[danielcompton]

@jluttine this is a slightly different use case. This is for when you've got multiple developers/computers that are releasing. When dev a releases, they will update the master branch, push it, and continue with the release process. When dev b goes to release, unless they explicitly pull the latest from master, then they will have problems as their version of master is behind that on the server.

[jluttine]

Ok, thanks for explaining. I'll open a separate issue for my case (#257). Anyway, I find the switch --ff-master confusing. I'd reserve that for fast forwarding master. For the case in this issue, I'd suggest using some other switch. Perhaps --fetch, --sync or something.

[petervanderdoes]

I can see the confusion with --ff-master.

What do people think of the following: We already have the --fetch flag, which is helpful if you have not setup remote tracking. Instead of the --ff-master flag we could do --fetch-ff-production and --fetch-ff-develop

[petervanderdoes]

Ok, so it seems I sort of create this without the use of the flag, by default the master branch is fast forwarded when it can be on a release finish. I'll fix it in the next few days and use the flags as described in the above comment

[jurgenhaas]

I'm very interested in this and wanted to give it a try. Unfortunately, version 1.9.1 is the latest being available both in the official Ubuntu repositories as well as in https://launchpad.net/~pdoes/+archive/ubuntu/gitflow-avh

So, my questino is two fold: which of the cli options is going to be the "final" one for fast forwarding master (according to release notes it seems to be --ff-master) and also, is it possible to update PPA for the latest release 1.11.0 please?

[Wirone]

This does not make sense. GitFlow model has merging in its foundation. If you want to fast forward while finishing releases/hotfixes, you don't want GitFlow but probably GitHub Flow or other flow :)

Also, fast forwarding does not relate to diverged master - it's just misuse of maintainer. Tool probably could force fetching target branch before merging and warn if branches have diverged, but fast forwarding is not solution for this problem.