Raman Gupta <rocketraman@xxxxxxxxxxx> writes:
> One question about the dev process:
>
> 1) I don't see any topic branches available in git.git. Are these
> generally kept in a private repo and/or shared between individual
> developer's public repositories?
I do not answer "generally" part, but in git.git, I do not publish heads
of individual topic branches. I could, but simply I don't, because that
has been the way I've operated so far, and I am too lazy to change my
configuration. Also I suspect it would make my life more cumbersome
because I have to prune stale topics from the public repositories from
time to time.
> Some questions about the release process:
>
> 1) After a release is made (master is tagged with vX.Y.Z), is the
> maint branch deleted and recreated from the new release tag? e.g.
>
> git branch -d maint
> git branch maint master
It is rather:
git checkout maint
git merge master
which should be the same because the merge should fast-forward, but an
advantage is that it would keep the reflog of 'maint'.
In addition, you can keep older maintenance track around, i.e.
git branch maint-X.Y.(Z-1) maint
git checkout maint
git merge master
so that maintenance releases for even older codebase _could_ be issued
_if_ necessary.
> 2) MaintNotes states:
>
> "After a feature release is made from "master", however, "next" will
> be rebuilt from the tip of "master" using the surviving topics"
>
> Does this mean:
>
> git branch -d next
> git checkout -b next master
> git merge ai/topic1_to_cook_in_next
> git merge ai/topic2_to_cook_in_next
That is more-or-less correct, even though I'd actually do either
git branch -f next master
or
git checkout next
git reset --hard master
instead of deleting and recreating.
--
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
