Re: [PATCHv3] Add branch management for releases to gitworkflows

From: Raman Gupta <rocketraman@fastmail.fm>
Date: Nov 13, 2009, 22:56 UTC
Message-ID: <4AFDE421.5050307@fastmail.fm>
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>

Nanako Shiraishi wrote:

Show 17 quoted lines

>  .Update maint to new release
>  [caption="Recipe: "]
>  =====================================
> -* `git checkout maint`
> -* `git merge master`
> +* `git checkout maint`
> +* `git merge --ff-only master`
>  =====================================
>  
> -This 'should' fast forward 'maint' from 'master'. If it is not a fast
> -forward, then 'maint' contained some commits that were not included on
> +This should fast-forward 'maint' from 'master'. If it is not a
> +fast-forward, then 'maint' contained some commits that were not included on
>  'master', which means that the recent feature release could be missing
> -some fixes made on 'maint'. The exception is if there were any commits
> -that were cherry-picked to 'maint' as described above in "Merging
> -upwards". In this case, the merge will not be a fast forward.

I noticed you removed the discussion I added about the situation in which maint will *not* be a subset of master i.e. when the user has cherry-picked commits from other branches. This type of cherry-pick is described as a valid operation, though one to generally be avoided earlier in the man page. If we tell users that the occasional cherry-pick to maint is ok, then shouldn't we explain how that affects the release process?

Cheers, Raman