Re: Reference for git.git release process
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 25, 2009, 19:30 UTC
- Message-ID
- <7viqlxz9go.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <49CA78BF.2020101@fastmail.fm>
Raman Gupta <rocketraman@fastmail.fm> writes:
Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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 masterwhich 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 masterso that maintenance releases for even older codebase _could_ be issued _if_ necessary.
Show 11 quoted lines
> 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 masterinstead of deleting and recreating.