Re: Reference for git.git release process

[Junio C Hamano <gitster@pobox.com>]

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.