Raman Gupta [off-list ref] 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.
Junio C Hamano wrote:
quoted
"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.
Is that a stylistic preference or does your approach have some
advantage over the delete/create? Doesn't git branch -f internally
delete and re-create?
This whole approach seems really workable and powerful -- the only
concern I had with this workflow was the difficult to understand
visualization of the history. So to repeat my earlier question: Are
there some canned gitk invocations, or other tips/tricks/approaches,
that can be used to make the visualization of the integration and
topic branches more intuitive?
Within the next couple of days I will probably submit a patch to
maintain-git.txt that includes the information you have relayed to me
here, as I think it may be useful to others.
Cheers,
Raman
On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:
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.
I don't think it is a big problem in practice. But every once in a while
I have had to dig through pu to re-create a topic branch manually. And I
believe Thomas Rast posted a script to do so automatically. So I think
there is some indication that people might find this information useful,
but I don't feel too strongly about it.
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.
Mirror mode would handle this automatically, but it unfortunately also
ignores your push refspec. So any cruft or work-in-progress refs in your
repository would be pushed.
-Peff
Junio C Hamano wrote:
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.
Assuming one tags ones releases (which one should, and git.git does),
creating maint-X.Y.Z when it's actually needed is a far better approach.
No morning coffee yet, Junio? ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
Andreas Ericsson wrote:
Junio C Hamano wrote:
quoted
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.
Assuming one tags ones releases (which one should, and git.git does),
creating maint-X.Y.Z when it's actually needed is a far better approach.
This is only correct if the current tip of the maint branch is in fact
the last tagged release i.e. that there is nothing pending on the
maint branch that is intended for a maintenance release on the older
codebase.
Cheers,
Raman