Here's my promised review of the whole patch. Much of the text fits
my understanding of what's actually going on, but Junio will have the
final word on what he actually does (or what a sensible simplification
might be).
rocketraman@xxxxxxxxxxx wrote:
> +The current maintenance branch is optionally copied to another branch
> +named with the older release version number (e.g. maint-X.Y.(Z-1)
> +where X.Y.Z is the previous release). This allows for further
> +maintenance releases on the older codebase.
The use of Z-1 confused me; I guess by "previous release" you mean
"the release we just tagged in the last step". Otherwise the maint
version number would come out wrong.
> +.Update maint to new release
> +[caption="Recipe: "]
> +=====================================
> +* `git checkout maint`
> +* `git merge master`
> +=====================================
> +
> +This updates 'maint' from 'master', while preserving the 'maint'
> +reflog.
I agree with what Junio said in the other mail: it's important at this
point that this was a fast-forward. (If it's not, master could be
missing some fixes made on maint.)
> +An alternative approach to updating the 'maint' branch is to run
> +
> + $ git branch -f maint master
In my book the alternative approach is
git branch -m maint maint-X.Y.(Z-1)
git branch maint master
I'd rather not teach users to play with loaded guns, much less in a
"good examples of workflows" manpage.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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