{"thread":{"id":"18543","subject":"Reference for git.git release process","startedAt":"2009-03-25T18:32:31Z","lastAt":"2009-03-26T17:03:26Z","messageCount":14,"participants":["Raman Gupta","Junio C Hamano","Jeff King","Andreas Ericsson","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109395","messageId":"49CA78BF.2020101@fastmail.fm","threadId":"18543","inReplyTo":null,"subject":"Reference for git.git release process","fromName":"Raman Gupta","fromEmail":"rocketraman@fastmail.fm","sentAt":"2009-03-25T18:32:31Z","receivedAt":"2009-03-25T18:32:31Z","isPatch":false,"sender":{"key":"rocketraman@fastmail.fm","avatar":null},"body":"Hi I'm relatively new to git and I've been reading the git.git notes\nabout how git itself is maintained, as I'm interested in using a\nsimilar workflow. I've read the MaintNotes document, the\nhowto/maintain-git.txt addendum, and Documentation/gitworkflows.txt.\n\nI believe I understand reasonably well the concepts presented in those\nthree documents. However, those documents have a lot of detail about\nthe development process, but not much about the release process.\n\n\nOne question about the dev process:\n\n1) I don't see any topic branches available in git.git. Are these\ngenerally kept in a private repo and/or shared between individual\ndeveloper's public repositories?\n\n\nSome questions about the release process:\n\n1) After a release is made (master is tagged with vX.Y.Z), is the\nmaint branch deleted and recreated from the new release tag? e.g.\n\ngit branch -d maint\ngit branch maint master\n\n2) MaintNotes states:\n\n\"After a feature release is made from \"master\", however, \"next\" will\nbe rebuilt from the tip of \"master\" using the surviving topics\"\n\nDoes this mean:\n\ngit branch -d next\ngit checkout -b next master\ngit merge ai/topic1_to_cook_in_next\ngit merge ai/topic2_to_cook_in_next\n...\n\nLastly, I note that the gitk --all representation of a repository\nmaintained in this way is very difficult to follow (at least for me)\nbecause of all the merging. Are there some canned gitk invocations\nthat can be used to make the visualization of the integration and\ntopic branches more intuitive?\n\nThank you all very much for an excellent tool.\n\nCheers,\nRaman\n"},{"id":"109404","messageId":"7viqlxz9go.fsf@gitster.siamese.dyndns.org","threadId":"18543","inReplyTo":"49CA78BF.2020101@fastmail.fm","subject":"Re: Reference for git.git release process","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T19:30:31Z","receivedAt":"2009-03-25T19:30:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Raman Gupta writes:\n\n> One question about the dev process:\n>\n> 1) I don't see any topic branches available in git.git. Are these\n> generally kept in a private repo and/or shared between individual\n> developer's public repositories?\n\nI do not answer \"generally\" part, but in git.git, I do not publish heads\nof individual topic branches. I could, but simply I don't, because that\nhas been the way I've operated so far, and I am too lazy to change my\nconfiguration. Also I suspect it would make my life more cumbersome\nbecause I have to prune stale topics from the public repositories from\ntime to time.\n\n> Some questions about the release process:\n>\n> 1) After a release is made (master is tagged with vX.Y.Z), is the\n> maint branch deleted and recreated from the new release tag? e.g.\n>\n> git branch -d maint\n> git branch maint master\n\nIt is rather:\n\n git checkout maint\n git merge master\n\nwhich should be the same because the merge should fast-forward, but an\nadvantage is that it would keep the reflog of 'maint'.\n\nIn addition, you can keep older maintenance track around, i.e.\n\n\tgit branch maint-X.Y.(Z-1) maint\n git checkout maint\n git merge master\n\nso that maintenance releases for even older codebase _could_ be issued\n_if_ necessary.\n\n> 2) MaintNotes states:\n>\n> \"After a feature release is made from \"master\", however, \"next\" will\n> be rebuilt from the tip of \"master\" using the surviving topics\"\n>\n> Does this mean:\n>\n> git branch -d next\n> git checkout -b next master\n> git merge ai/topic1_to_cook_in_next\n> git merge ai/topic2_to_cook_in_next\n\nThat is more-or-less correct, even though I'd actually do either\n\n\tgit branch -f next master\n\nor\n\n\tgit checkout next\n git reset --hard master\n\ninstead of deleting and recreating.\n"},{"id":"109437","messageId":"49CAAA16.1080401@fastmail.fm","threadId":"18543","inReplyTo":"7viqlxz9go.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Raman Gupta","fromEmail":"rocketraman@fastmail.fm","sentAt":"2009-03-25T22:03:02Z","receivedAt":"2009-03-25T22:03:02Z","isPatch":false,"sender":{"key":"rocketraman@fastmail.fm","avatar":null},"body":"Junio C Hamano wrote:\n>> \"After a feature release is made from \"master\", however, \"next\" will\n>> be rebuilt from the tip of \"master\" using the surviving topics\"\n>>\n>> Does this mean:\n>>\n>> git branch -d next\n>> git checkout -b next master\n>> git merge ai/topic1_to_cook_in_next\n>> git merge ai/topic2_to_cook_in_next\n> \n> That is more-or-less correct, even though I'd actually do either\n> \n> \tgit branch -f next master\n> \n> or\n> \n> \tgit checkout next\n> git reset --hard master\n> \n> instead of deleting and recreating.\n\nIs that a stylistic preference or does your approach have some\nadvantage over the delete/create? Doesn't git branch -f internally\ndelete and re-create?\n\nThis whole approach seems really workable and powerful -- the only\nconcern I had with this workflow was the difficult to understand\nvisualization of the history. So to repeat my earlier question: Are\nthere some canned gitk invocations, or other tips/tricks/approaches,\nthat can be used to make the visualization of the integration and\ntopic branches more intuitive?\n\nWithin the next couple of days I will probably submit a patch to\nmaintain-git.txt that includes the information you have relayed to me\nhere, as I think it may be useful to others.\n\nCheers,\nRaman\n"},{"id":"109444","messageId":"7vocvpw4q1.fsf@gitster.siamese.dyndns.org","threadId":"18543","inReplyTo":"49CAAA16.1080401@fastmail.fm","subject":"Re: Reference for git.git release process","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T23:41:10Z","receivedAt":"2009-03-25T23:41:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Raman Gupta writes:\n\n> Junio C Hamano wrote:\n> ...\n>> That is more-or-less correct, even though I'd actually do either\n>> \n>> \tgit branch -f next master\n>> \n>> or\n>> \n>> \tgit checkout next\n>> git reset --hard master\n>> \n>> instead of deleting and recreating.\n>\n> Is that a stylistic preference or does your approach have some\n> advantage over the delete/create? Doesn't git branch -f internally\n> delete and re-create?\n\nNo, yes, and no. The last answer \"no\" relates to the fact that the\npreservation of the reflog and per-branch configuration for \"next\", which\nis the reason behind the second answer \"yes\".\n\n> ... The only\n> concern I had with this workflow was the difficult to understand\n> visualization of the history. So to repeat my earlier question: Are\n> there some canned gitk invocations, or other tips/tricks/approaches,...\n\nI do not share the difficulty, and there is no answer from me to your\n\"earlier\" question. Perhaps other people have some tips.\n"},{"id":"109460","messageId":"20090326022757.GC5835@coredump.intra.peff.net","threadId":"18543","inReplyTo":"7viqlxz9go.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-26T02:27:58Z","receivedAt":"2009-03-26T02:27:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:\n\n> I do not answer \"generally\" part, but in git.git, I do not publish heads\n> of individual topic branches. I could, but simply I don't, because that\n> has been the way I've operated so far, and I am too lazy to change my\n> configuration.\n\nI don't think it is a big problem in practice. But every once in a while\nI have had to dig through pu to re-create a topic branch manually. And I\nbelieve Thomas Rast posted a script to do so automatically. So I think\nthere is some indication that people might find this information useful,\nbut I don't feel too strongly about it.\n\n> Also I suspect it would make my life more cumbersome\n> because I have to prune stale topics from the public repositories from\n> time to time.\n\nMirror mode would handle this automatically, but it unfortunately also\nignores your push refspec. So any cruft or work-in-progress refs in your\nrepository would be pushed.\n\n-Peff\n"},{"id":"109462","messageId":"7vtz5hugc6.fsf@gitster.siamese.dyndns.org","threadId":"18543","inReplyTo":"20090326022757.GC5835@coredump.intra.peff.net","subject":"Re: Reference for git.git release process","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-26T03:13:13Z","receivedAt":"2009-03-26T03:13:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Mirror mode would handle this automatically, but it unfortunately also\n> ignores your push refspec. So any cruft or work-in-progress refs in your\n> repository would be pushed.\n\nExactly.\n\nIncidentally, that is why I usually favor the current 'matching' default.\nIf I decide to push something to the other repository, the other\nrepository remembers my wish, so I do not have to keep track (of course,\nfor that to work effectively, you have to _own_ the other side; it does\nnot work well for a shared public repository and that is why we had a\nlengthy discussion on push.default).\n"},{"id":"109463","messageId":"20090326031521.GA7984@coredump.intra.peff.net","threadId":"18543","inReplyTo":"7vtz5hugc6.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-26T03:15:21Z","receivedAt":"2009-03-26T03:15:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 25, 2009 at 08:13:13PM -0700, Junio C Hamano wrote:\n\n> Incidentally, that is why I usually favor the current 'matching' default.\n> If I decide to push something to the other repository, the other\n> repository remembers my wish, so I do not have to keep track (of course,\n> for that to work effectively, you have to _own_ the other side; it does\n> not work well for a shared public repository and that is why we had a\n> lengthy discussion on push.default).\n\nSo if I understand correctly, you would actually like \"push matching,\ndelete missing\" behavior?\n\n-Peff\n"},{"id":"109464","messageId":"7vd4c5ufqj.fsf@gitster.siamese.dyndns.org","threadId":"18543","inReplyTo":"7vocvpw4q1.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-26T03:26:12Z","receivedAt":"2009-03-26T03:26:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Raman Gupta writes:\n> ...\n>> ... The only\n>> concern I had with this workflow was the difficult to understand\n>> visualization of the history. So to repeat my earlier question: Are\n>> there some canned gitk invocations, or other tips/tricks/approaches,...\n>\n> I do not share the difficulty, and there is no answer from me to your\n> \"earlier\" question. Perhaps other people have some tips.\n\nThis may deserve a but more explanation as to why I do not share that\ndifficulty. In short, I never look at gitk output to see how next is\ndoing, and that is why many repeated merges to next does not bother me.\n\nOn my main integration branches ('master' and 'maint'), new development\nnever happens directly (I do apply trivially correct patches to them, but\nthey are exceptions). Because of this, you can get a pretty good overview\nby running \"git log --oneline --first-parent\" starting from the tip of\nthese branches to see what topics have graduated.\n\nMy primary gitk replacement is the periodical \"What's in git\" and \"What's\ncooking in git\" messages. I use a few custom scripts (Meta/WC,\nMeta/git-topic.perl and Meta/UWC) to manage the latter (the production of\nthe former is merely \"git shortlog --no-merges ..master\").\n\nAfter accumulating new patches on top of topics and merging more topics to\nintegration branches (such as master and next), I run Meta/WC which in\nturn runs Meta/UWC to read the last issue of \"What's cooking\", and the raw\nmaterial that should go in the next issue of the message (generated by\nMeta/git-topic.perl), and the comments on each topic in the last issue is\nmerged to produce the draft of the next issue. I add further text to it\nto describe new deveolopment to existing topics and comment on new topics\nbefore sending it out, and another cycle begins.\n"},{"id":"109466","messageId":"7v8wmtufn4.fsf@gitster.siamese.dyndns.org","threadId":"18543","inReplyTo":"20090326031521.GA7984@coredump.intra.peff.net","subject":"Re: Reference for git.git release process","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-26T03:28:15Z","receivedAt":"2009-03-26T03:28:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Mar 25, 2009 at 08:13:13PM -0700, Junio C Hamano wrote:\n>\n>> Incidentally, that is why I usually favor the current 'matching' default.\n>> If I decide to push something to the other repository, the other\n>> repository remembers my wish, so I do not have to keep track (of course,\n>> for that to work effectively, you have to _own_ the other side; it does\n>> not work well for a shared public repository and that is why we had a\n>> lengthy discussion on push.default).\n>\n> So if I understand correctly, you would actually like \"push matching,\n> delete missing\" behavior?\n\nHmm, that would be good. That would allow me to start publishing the\nindividual topics with ease.\n\nI never thought of that.\n"},{"id":"109467","messageId":"7v3ad1ufcb.fsf@gitster.siamese.dyndns.org","threadId":"18543","inReplyTo":"20090326022757.GC5835@coredump.intra.peff.net","subject":"Re: Reference for git.git release process","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-26T03:34:44Z","receivedAt":"2009-03-26T03:34:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:\n>\n>> I do not answer \"generally\" part, but in git.git, I do not publish heads\n>> of individual topic branches. I could, but simply I don't, because that\n>> has been the way I've operated so far, and I am too lazy to change my\n>> configuration.\n>\n> I don't think it is a big problem in practice.\n\nBoth times Shawn took over the maintainership from me in October for the\npast few years (and I will ask him to this year, too, although I do not\nknow if he is willing to take it again yet), it would have made his life\n(and possibly everybody who had his topic in flight) much easier if they\nwere public. Last year I sent him for-each-ref output offline before I\ntook off to make it a bit easier on him (my disappearance two years ago\nwas unscheduled and I couldn't do that).\n"},{"id":"109472","messageId":"20090326034909.GB8031@coredump.intra.peff.net","threadId":"18543","inReplyTo":"7v8wmtufn4.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-26T03:49:09Z","receivedAt":"2009-03-26T03:49:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 25, 2009 at 08:28:15PM -0700, Junio C Hamano wrote:\n\n> > So if I understand correctly, you would actually like \"push matching,\n> > delete missing\" behavior?\n> \n> Hmm, that would be good. That would allow me to start publishing the\n> individual topics with ease.\n> \n> I never thought of that.\n\nI'm not sure of the best way to implement it. Is it a new behavior on\npar with matching, tracking, current, etc; or is \"delete missing\"\northogonal to what is being pushed? Should \"delete missing\" attempt to\nmatch according to your refspecs, or according to the whole repo (like\nmirror)?\n\nI was thinking \"orthogonal, limited to your refspec\". So configure via\n\n git config remote.origin.prune-push true\n\nand then you can\n\n # pseudo-mirror following your refspec or matching behavior\n git push origin\n\n # push foo if it exists, or delete it if it doesn't\n git push origin foo\n\n # sync some subset of your refs\n git push origin refs/heads/jk/*:refs/heads/jk/*\n\n-Peff\n"},{"id":"109500","messageId":"49CB3766.5090109@op5.se","threadId":"18543","inReplyTo":"7viqlxz9go.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-03-26T08:05:58Z","receivedAt":"2009-03-26T08:05:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> In addition, you can keep older maintenance track around, i.e.\n> \n> \tgit branch maint-X.Y.(Z-1) maint\n> git checkout maint\n> git merge master\n> \n> so that maintenance releases for even older codebase _could_ be issued\n> _if_ necessary.\n> \n\nAssuming one tags ones releases (which one should, and git.git does),\ncreating maint-X.Y.Z when it's actually needed is a far better approach.\n\nNo morning coffee yet, Junio? ;-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"109534","messageId":"49CB9159.6030606@fastmail.fm","threadId":"18543","inReplyTo":"49CB3766.5090109@op5.se","subject":"Re: Reference for git.git release process","fromName":"Raman Gupta","fromEmail":"rocketraman@fastmail.fm","sentAt":"2009-03-26T14:29:45Z","receivedAt":"2009-03-26T14:29:45Z","isPatch":false,"sender":{"key":"rocketraman@fastmail.fm","avatar":null},"body":"Andreas Ericsson wrote:\n> Junio C Hamano wrote:\n>>\n>> In addition, you can keep older maintenance track around, i.e.\n>>\n>> git branch maint-X.Y.(Z-1) maint\n>> git checkout maint\n>> git merge master\n>>\n>> so that maintenance releases for even older codebase _could_ be issued\n>> _if_ necessary.\n>>\n> \n> Assuming one tags ones releases (which one should, and git.git does),\n> creating maint-X.Y.Z when it's actually needed is a far better approach.\n\nThis is only correct if the current tip of the maint branch is in fact\nthe last tagged release i.e. that there is nothing pending on the\nmaint branch that is intended for a maintenance release on the older\ncodebase.\n\nCheers,\nRaman\n"},{"id":"109557","messageId":"20090326170326.GE23521@spearce.org","threadId":"18543","inReplyTo":"7v3ad1ufcb.fsf@gitster.siamese.dyndns.org","subject":"Re: Reference for git.git release process","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-03-26T17:03:26Z","receivedAt":"2009-03-26T17:03:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"jUNio C Hamano wrote:\n> Jeff King writes:\n> > On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:\n> >\n> >> I do not answer \"generally\" part, but in git.git, I do not publish heads\n> >> of individual topic branches. I could, but simply I don't, because that\n> >> has been the way I've operated so far, and I am too lazy to change my\n> >> configuration.\n> >\n> > I don't think it is a big problem in practice.\n> \n> Both times Shawn took over the maintainership from me in October for the\n> past few years (and I will ask him to this year, too, although I do not\n> know if he is willing to take it again yet), it would have made his life\n> (and possibly everybody who had his topic in flight) much easier if they\n> were public. Last year I sent him for-each-ref output offline before I\n> took off to make it a bit easier on him (my disappearance two years ago\n> was unscheduled and I couldn't do that).\n\nSo yes, I'd be happy to fill in while you are offline again.\n\nBut back to Jeff's point, the bigger issue when you dropped off\nall of a sudden wasn't extracting the refs from the `pu` branch\n(that was fairly easy, just scan through the merge commits, copy\nand paste the branch name, copy and paste the 2nd parent), it was\nfiguring out what the state of each branch was, and what your final\nthoughts on that branch had been before you left.\n\nThe newer \"what's in\" tools in your Meta project make this easier,\nalong with having the messages archived. The first year I had to\ngo pull the what's in email from the list archives, and just scan\nthrough the code and form my own opinion in a few cases.\n\n-- \nShawn.\n"}]}