Nanako Shiraishi wrote: > .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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html