Reference for git.git release process

Reference for git.git release process

[Raman Gupta]

Hi I'm relatively new to git and I've been reading the git.git notes
about how git itself is maintained, as I'm interested in using a
similar workflow. I've read the MaintNotes document, the
howto/maintain-git.txt addendum, and Documentation/gitworkflows.txt.

I believe I understand reasonably well the concepts presented in those
three documents. However, those documents have a lot of detail about
the development process, but not much about the release process.


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?


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

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
...

Lastly, I note that the gitk --all representation of a repository
maintained in this way is very difficult to follow (at least for me)
because of all the merging. Are there some canned gitk invocations
that can be used to make the visualization of the integration and
topic branches more intuitive?

Thank you all very much for an excellent tool.

Cheers,
Raman

Re: Reference for git.git release process

[Junio C Hamano]

Raman Gupta <rocketraman@fastmail.fm> 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.

Re: Reference for git.git release process

[Raman Gupta]

Junio C Hamano wrote:
>> "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

Re: Reference for git.git release process

[Junio C Hamano]

Raman Gupta <rocketraman@fastmail.fm> writes:

> Junio C Hamano wrote:
> ...
>> 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?

No, yes, and no.  The last answer "no" relates to the fact that the
preservation of the reflog and per-branch configuration for "next", which
is the reason behind the second answer "yes".

> ... 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,...

I do not share the difficulty, and there is no answer from me to your
"earlier" question.  Perhaps other people have some tips.

Re: Reference for git.git release process

[Jeff King]

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

Re: Reference for git.git release process

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.

Exactly.

Incidentally, that is why I usually favor the current 'matching' default.
If I decide to push something to the other repository, the other
repository remembers my wish, so I do not have to keep track (of course,
for that to work effectively, you have to _own_ the other side; it does
not work well for a shared public repository and that is why we had a
lengthy discussion on push.default).

Re: Reference for git.git release process

[Jeff King]

On Wed, Mar 25, 2009 at 08:13:13PM -0700, Junio C Hamano wrote:

> Incidentally, that is why I usually favor the current 'matching' default.
> If I decide to push something to the other repository, the other
> repository remembers my wish, so I do not have to keep track (of course,
> for that to work effectively, you have to _own_ the other side; it does
> not work well for a shared public repository and that is why we had a
> lengthy discussion on push.default).

So if I understand correctly, you would actually like "push matching,
delete missing" behavior?

-Peff

Re: Reference for git.git release process

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Raman Gupta <rocketraman@fastmail.fm> writes:
> ...
>> ... 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,...
>
> I do not share the difficulty, and there is no answer from me to your
> "earlier" question.  Perhaps other people have some tips.

This may deserve a but more explanation as to why I do not share that
difficulty.  In short, I never look at gitk output to see how next is
doing, and that is why many repeated merges to next does not bother me.

On my main integration branches ('master' and 'maint'), new development
never happens directly (I do apply trivially correct patches to them, but
they are exceptions).  Because of this, you can get a pretty good overview
by running "git log --oneline --first-parent" starting from the tip of
these branches to see what topics have graduated.

My primary gitk replacement is the periodical "What's in git" and "What's
cooking in git" messages.  I use a few custom scripts (Meta/WC,
Meta/git-topic.perl and Meta/UWC) to manage the latter (the production of
the former is merely "git shortlog --no-merges <last-issue>..master").

After accumulating new patches on top of topics and merging more topics to
integration branches (such as master and next), I run Meta/WC which in
turn runs Meta/UWC to read the last issue of "What's cooking", and the raw
material that should go in the next issue of the message (generated by
Meta/git-topic.perl), and the comments on each topic in the last issue is
merged to produce the draft of the next issue.  I add further text to it
to describe new deveolopment to existing topics and comment on new topics
before sending it out, and another cycle begins.

Re: Reference for git.git release process

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Mar 25, 2009 at 08:13:13PM -0700, Junio C Hamano wrote:
>
>> Incidentally, that is why I usually favor the current 'matching' default.
>> If I decide to push something to the other repository, the other
>> repository remembers my wish, so I do not have to keep track (of course,
>> for that to work effectively, you have to _own_ the other side; it does
>> not work well for a shared public repository and that is why we had a
>> lengthy discussion on push.default).
>
> So if I understand correctly, you would actually like "push matching,
> delete missing" behavior?

Hmm, that would be good.  That would allow me to start publishing the
individual topics with ease.

I never thought of that.

Re: Reference for git.git release process

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.

Both times Shawn took over the maintainership from me in October for the
past few years (and I will ask him to this year, too, although I do not
know if he is willing to take it again yet), it would have made his life
(and possibly everybody who had his topic in flight) much easier if they
were public.  Last year I sent him for-each-ref output offline before I
took off to make it a bit easier on him (my disappearance two years ago
was unscheduled and I couldn't do that).

Re: Reference for git.git release process

[Jeff King]

On Wed, Mar 25, 2009 at 08:28:15PM -0700, Junio C Hamano wrote:

> > So if I understand correctly, you would actually like "push matching,
> > delete missing" behavior?
> 
> Hmm, that would be good.  That would allow me to start publishing the
> individual topics with ease.
> 
> I never thought of that.

I'm not sure of the best way to implement it. Is it a new behavior on
par with matching, tracking, current, etc; or is "delete missing"
orthogonal to what is being pushed? Should "delete missing" attempt to
match according to your refspecs, or according to the whole repo (like
mirror)?

I was thinking "orthogonal, limited to your refspec". So configure via

  git config remote.origin.prune-push true

and then you can

  # pseudo-mirror following your refspec or matching behavior
  git push origin

  # push foo if it exists, or delete it if it doesn't
  git push origin foo

  # sync some subset of your refs
  git push origin refs/heads/jk/*:refs/heads/jk/*

-Peff

Re: Reference for git.git release process

[Andreas Ericsson]

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.

Re: Reference for git.git release process

[Raman Gupta]

Andreas Ericsson wrote:
> 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.

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

Re: Reference for git.git release process

[Shawn O. Pearce]

jUNio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
> > 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.
> 
> Both times Shawn took over the maintainership from me in October for the
> past few years (and I will ask him to this year, too, although I do not
> know if he is willing to take it again yet), it would have made his life
> (and possibly everybody who had his topic in flight) much easier if they
> were public.  Last year I sent him for-each-ref output offline before I
> took off to make it a bit easier on him (my disappearance two years ago
> was unscheduled and I couldn't do that).

So yes, I'd be happy to fill in while you are offline again.

But back to Jeff's point, the bigger issue when you dropped off
all of a sudden wasn't extracting the refs from the `pu` branch
(that was fairly easy, just scan through the merge commits, copy
and paste the branch name, copy and paste the 2nd parent), it was
figuring out what the state of each branch was, and what your final
thoughts on that branch had been before you left.

The newer "what's in" tools in your Meta project make this easier,
along with having the messages archived.  The first year I had to
go pull the what's in email from the list archives, and just scan
through the code and form my own opinion in a few cases.

-- 
Shawn.