Reference for git.git release process

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

Raman Gupta <rocketraman@fastmail.fm> writes:

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.

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.

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:

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

Raman Gupta <rocketraman@fastmail.fm> writes:

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

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

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

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.

On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:

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.

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

Jeff King <peff@peff.net> writes:

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

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

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

-Peff

Jeff King <peff@peff.net> writes:

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

I never thought of that.

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

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

Jeff King <peff@peff.net> writes:

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

jUNio C Hamano <gitster@pobox.com> wrote:

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.

Junio C Hamano wrote:

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 wrote:

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