{"thread":{"id":"19219","subject":"A note from the maintainer","startedAt":"2009-05-07T07:09:39Z","lastAt":"2009-05-07T16:30:50Z","messageCount":3,"participants":["Junio C Hamano","Baz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113173","messageId":"7vocu5s824.fsf@alter.siamese.dyndns.org","threadId":"19219","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-07T07:09:39Z","receivedAt":"2009-05-07T07:09:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Welcome to git community.\n\nThis message talks about how git.git is managed, and how you can work\nwith it.\n\n* IRC and Mailing list\n\nMany active members of development community hang around on #git\nIRC channel on Freenode.  Its log is available at:\n\n        http://colabti.org/irclogger/irclogger_log/git\n\nThe development however is primarily done on the git mailing list\n(git@vger.kernel.org).  If you have patches, please send them to the\nlist, following Documentation/SubmittingPatches.\n\nI usually try to read all patches posted to the list, and follow\nalmost all the discussions on the list, unless the topic is about an\nobscure corner that I do not personally use.  But I am obviously not\nperfect.  If you sent a patch that you did not hear from anybody for\nthree days, that is a very good indication that it was dropped on the\nfloor --- please do not hesitate to remind me.\n\nThe list archive is available at a few public sites as well:\n\n        http://news.gmane.org/gmane.comp.version-control.git/\n        http://marc.theaimsgroup.com/?l=git\n        http://www.spinics.net/lists/git/\n\nand some people seem to prefer to read it over NNTP:\n\n        nntp://news.gmane.org/gmane.comp.version-control.git\n\nWhen you point at a message in a mailing list archive, using\ngmane is often the easiest to follow by readers, like this:\n\n        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217\n\nas it also allows people who subscribe to the mailing list as\ngmane newsgroup to \"jump to\" the article.\n\n* Repositories, branches and documentation.\n\nMy public git.git repository is at:\n\n        git://git.kernel.org/pub/scm/git/git.git/\n\nImmediately after I publish to the primary repository at kernel.org, I\nalso push into an alternate here:\n\n        git://repo.or.cz/alt-git.git/\n\nImpatient people might have better luck with the latter one.\n\nTheir gitweb interfaces are found at:\n\n        http://git.kernel.org/?p=git/git.git\n        http://repo.or.cz/w/alt-git.git\n\nThere are three branches in git.git repository that are not about the\nsource tree of git: \"todo\", \"html\" and \"man\".  The first one was meant\nto contain TODO list for me, but I am not good at maintaining such a\nlist and it is in an abandoned state.  The branch mostly is used to\nkeep some helper scripts I use to maintain git and the regular \"What's\nin/cooking\" messages these days.\n\nThe \"html\" and \"man\" are autogenerated documentation from the\ntip of the \"master\" branch; the tip of \"html\" is extracted to be\nvisible at kernel.org at:\n\n        http://www.kernel.org/pub/software/scm/git/docs/\n\nThe above URL is the top-level documentation page, and it has\nlinks to documentation of older releases.\n\nThe script to maintain these two documentation branches are\nfound in \"todo\" branch as dodoc.sh, if you are interested.  It\nis a good demonstration of how to use a post-update hook to\nautomate a task.\n\nThere are four branches in git.git repository that track the\nsource tree of git: \"master\", \"maint\", \"next\", and \"pu\".  I may\nadd more maintenance branches (e.g. \"maint-1.5.4\") if we have\nhugely backward incompatible feature updates in the future to keep\nan older release alive; I may not, but the distributed nature of\ngit means any volunteer can run a stable-tree like that herself.\n\nThe \"master\" branch is meant to contain what are very well\ntested and ready to be used in a production setting.  There\ncould occasionally be minor breakages or brown paper bag bugs\nbut they are not expected to be anything major, and more\nimportantly quickly and trivially fixable.  Every now and\nthen, a \"feature release\" is cut from the tip of this branch and\nthey typically are named with three dotted decimal digits.  The\nlast such release was 1.6.3 done on May 6th 2009.  You\ncan expect that the tip of the \"master\" branch is always more\nstable than any of the released versions.\n\nWhenever a feature release is made, \"maint\" branch is forked off\nfrom \"master\" at that point.  Obvious, safe and urgent fixes\nafter a feature release are applied to this branch and\nmaintenance releases are cut from it.  The maintenance releases\nare named with four dotted decimal, named after the feature\nrelease they are updates to; the last such release was 1.6.2.5.\nNew features never go to this branch.  This branch is also\nmerged into \"master\" to propagate the fixes forward.\n\nA trivial and safe enhancement goes directly on top of \"master\".\nA new development, either initiated by myself or more often by\nsomebody who found his or her own itch to scratch, does not\nusually happen on \"master\", however.  Instead, a separate topic\nbranch is forked from the tip of \"master\", and it first is\ntested in isolation; I may make minimum fixups at this point.\nUsually there are a handful such topic branches that are running\nahead of \"master\" in git.git repository.  I do not publish the\ntip of these branches in my public repository, however, partly\nto keep the number of branches that downstream developers need\nto worry about low, and primarily because I am lazy.\n\nThe quality of topic branches are judged primarily by the mailing list\ndiscussions.  Some of them start out as \"good idea but obviously is\nbroken in some areas (e.g. breaks the existing testsuite)\" and then\nwith some more work (either by the original contributor's effort or\nhelp from other people on the list) becomes \"more or less done and can\nnow be tested by wider audience\".  Luckily, most of them start out in\nthe latter, better shape.\n\nThe \"next\" branch is to merge and test topic branches in the\nlatter category.  In general, the branch always contains the tip\nof \"master\".  It might not be quite rock-solid production ready,\nbut is expected to work more or less without major breakage.  I\nusually use \"next\" version of git for my own work, so it cannot\nbe _that_ broken to prevent me from pushing the changes out.\nThe \"next\" branch is where new and exciting things take place.\n\nThe two branches \"master\" and \"maint\" are never rewound, and\n\"next\" usually will not be either (this automatically means the\ntopics that have been merged into \"next\" are usually not\nrebased, and you can find the tip of topic branches you are\ninterested in from the output of \"git log next\"). You should be\nable to safely track them.\n\nAfter a feature release is made from \"master\", however, \"next\"\nwill be rebuilt from the tip of \"master\" using the surviving\ntopics.  The commit that replaces the tip of the \"next\" will\nusually have the identical tree, but it will have different ancestry\nfrom the tip of \"master\".  An announcement will be made to warn\npeople about such a rebasing.\n\nThe \"pu\" (proposed updates) branch bundles all the remainder of\ntopic branches.  The \"pu\" branch, and topic branches that are\nonly in \"pu\", are subject to rebasing in general.  By the above\ndefinition of how \"next\" works, you can tell that this branch\nwill contain quite experimental and obviously broken stuff.\n\nWhen a topic that was in \"pu\" proves to be in testable shape, it\ngraduates to \"next\".  I do this with:\n\n        git checkout next\n        git merge that-topic-branch\n\nSometimes, an idea that looked promising turns out to be not so\ngood and the topic can be dropped from \"pu\" in such a case.\n\nA topic that is in \"next\" is expected to be tweaked and fixed to\nperfection before it is merged to \"master\" (that's why \"master\"\ncan be expected to stay very stable).  Similarly to the above, I\ndo it with this:\n\n        git checkout master\n        git merge that-topic-branch\n        git branch -d that-topic-branch\n\nNote that being in \"next\" is not a guarantee to appear in the\nnext release (being in \"master\" is such a guarantee, unless it\nis later found seriously broken and reverted), nor even in any\nfuture release.  There even were cases that topics needed\nreverting a few commits in them before graduating to \"master\",\nor a topic that already was in \"next\" were entirely reverted\nfrom \"next\" because fatal flaws were found in them later.\n\n\n* Other people's trees, trusted lieutenants and credits.\n\nDocumentation/SubmittingPatches outlines to whom your proposed\nchanges should be sent.  As described in contrib/README, I would\ndelegate fixes and enhancements in contrib/ area to the primary\ncontributors of them.\n\nAlthough the following are included in git.git repository, they\nhave their own authoritative repository and maintainers:\n\n - git-gui/ comes from Shawn Pearce's git-gui project:\n\n        git://repo.or.cz/git-gui.git\n\n - gitk-git/ comes from Paul Mackerras's gitk project:\n\n        git://git.kernel.org/pub/scm/gitk/gitk.git\n\nI would like to thank everybody who helped to raise git into the\ncurrent shape.  Especially I would like to thank the git list\nregulars whose help I have relied on and expect to continue\nrelying on heavily:\n\n - Linus on general design issues.\n\n - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,\n   Ren辿 Scharfe, Jeff King and Johannes Sixt on general\n   implementation issues.\n\n - Shawn and Nicolas Pitre on pack issues.\n\n - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.\n\n - Paul Mackerras on gitk.\n\n - Eric Wong on git-svn.\n\n - Simon Hausmann on git-p4.\n\n - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta\n   on gitweb.\n\n - J. Bruce Fields on documentation (and countless others for\n   proofreading and fixing).\n\n - Alexandre Julliard on Emacs integration.\n\n - Charles Bailey for taking good care of git-mergetool (and Theodore\n   Ts'o for creating it in the first place).\n\n - David Aguilar for git-difftool.\n\n - Johannes Schindelin, Johannes Sixt and others for their effort\n   to move things forward on the Windows front.\n\n - People on non-Linux platforms for keeping their eyes on\n   portability; especially, Randal Schwartz, Theodore Ts'o,\n   Jason Riedy, Thomas Glanzmann, Brandon Casey, Jeff King,\n   Alex Riesen and countless others.\n\n* This document\n\nThe latest copy of this document is found in git.git repository,\non 'todo' branch, as MaintNotes.\n"},{"id":"113218","messageId":"2faad3050905070640v1718794dt2f5d2da3f06b3bb6@mail.gmail.com","threadId":"19219","inReplyTo":"7vocu5s824.fsf@alter.siamese.dyndns.org","subject":"Re: A note from the maintainer","fromName":"Baz","fromEmail":"brian.ewins@gmail.com","sentAt":"2009-05-07T13:40:58Z","receivedAt":"2009-05-07T13:40:58Z","isPatch":false,"sender":{"key":"brian.ewins@gmail.com","avatar":"https://gravatar.com/avatar/9ac03d89105e50a7151e695a1b4b1228151064ec3ac380a73b74ab397796baf7?d=mp&s=160"},"body":"Apologies for not quoting the mail I'm replying to, but gmail would\njust make the character encoding issues worse.\n\nJunio, Rene Scharfe's name appears incorrectly in the MaintNotes\nmessage - the mail was sent as iso-2022-jp. Previous editions of this\nmail (like the one on 4th March) were in utf-8. Maybe a consequence of\nthe recent change you made to your emacs setup?\n\nhttp://article.gmane.org/gmane.comp.version-control.git/115746\n\nJust mentioning it in case it causes problems with patch mails down the line.\n\nCheers,\nBaz\n"},{"id":"113230","messageId":"7vmy9oeuyt.fsf@alter.siamese.dyndns.org","threadId":"19219","inReplyTo":"2faad3050905070640v1718794dt2f5d2da3f06b3bb6@mail.gmail.com","subject":"Re: A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-07T16:30:50Z","receivedAt":"2009-05-07T16:30:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Baz <brian.ewins@gmail.com> writes:\n\n> Junio, Rene Scharfe's name appears incorrectly in the MaintNotes\n> message - the mail was sent as iso-2022-jp. Previous editions of this\n> mail (like the one on 4th March) were in utf-8. Maybe a consequence of\n> the recent change you made to your emacs setup?\n\nThanks for not just complaining but giving me a clue where to look into.\nI very much appreciate it.  Will find time to look into it before sending\nany more message with a non-ascii character.\n"}]}