{"thread":{"id":"22075","subject":"A note from the maintainer","startedAt":"2010-01-01T00:09:43Z","lastAt":"2010-01-01T00:09:43Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"130647","messageId":"7vzl4yptx4.fsf@alter.siamese.dyndns.org","threadId":"22075","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-01T00:09:43Z","receivedAt":"2010-01-01T00:09:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Welcome to git development community.\n\nThis message is written by the maintainer and talks about how Git\nproject is managed, and how you can work with it.\n\n* IRC and Mailing list\n\nMembers of the development community can sometimes be found on #git\nIRC channel on Freenode.  Its log is available at:\n\n        http://colabti.org/irclogger/irclogger_log/git\n\nThe development is primarily done on the Git mailing list If you have\npatches, please send them to the list address (git@vger.kernel.org).\nfollowing Documentation/SubmittingPatches.  You don't have to be\nsubscribed to send messages there, and the convention is to Cc:\neverybody involved, so you don't even have to say \"Please Cc: me, I am\nnot subscribed\".\n\nIf you sent a patch and you did not hear any response from anybody for\nseveral days, it could be that your patch was totally uninteresting, but\nit also is possible that it was simply lost in the noise.  Please do not\nhesitate to send a reminder message politely in such a case.  Messages\ngetting lost in the noise is a sign that people involved don't have enough\nmental/time bandwidth to process them right at the moment, and it often\nhelps to wait until the list traffic becomes calmer before sending such a\nreminder.\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 to\ncontain TODO list for me, but I am not good at maintaining such a list and\nit is in an abandoned state.  The branch mostly is used to keep some\nhelper scripts I use to maintain git and the regular \"What's cooking\"\nmessages these days.\n\nThe \"html\" and \"man\" are autogenerated documentation from the tip of the\n\"master\" branch; the tip of \"html\" is extracted to be visible at\nkernel.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 found in the\n\"todo\" branch as dodoc.sh, if you are interested.  It is a demonstration\nof how to use a post-update hook to automate a task after pushing into a\nrepository.\n\nThere are four branches in git.git repository that track the source tree\nof git: \"master\", \"maint\", \"next\", and \"pu\".  I may add more maintenance\nbranches (e.g. \"maint-1.6.3\") if we have hugely backward incompatible\nfeature updates in the future to keep an older release alive; I may not,\nbut the distributed nature of git means any volunteer can run a\nstable-tree like that herself.\n\nThe \"master\" branch is meant to contain what are very well tested and\nready to be used in a production setting.  There could occasionally be\nminor breakages or brown paper bag bugs but they are not expected to be\nanything major, and more importantly quickly and trivially fixable.  Every\nnow and then, a \"feature release\" is cut from the tip of this branch and\nthey typically are named with three dotted decimal digits.  The last such\nrelease was 1.6.6 done on Dec 23rd 2009.  You can expect that the tip of\nthe \"master\" branch is always more stable than any of the released\nversions.\n\nWhenever a feature release is made, \"maint\" branch is forked off from\n\"master\" at that point.  Obvious, safe and urgent fixes after a feature\nrelease are applied to this branch and maintenance releases are cut from\nit.  The maintenance releases are named with four dotted decimal, named\nafter the feature release they are updates to; the last such release was\n1.6.5.7.  New 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\".  A new\ndevelopment, either initiated by myself or more often by somebody who\nfound his or her own itch to scratch, does not usually happen on \"master\",\nhowever.  Instead, a separate topic branch is forked from the tip of\n\"master\", and it first is tested in isolation; I may make minimum fixups\nat this point.  Usually there are a handful such topic branches that are\nrunning ahead of \"master\" in git.git repository.  I do not publish the tip\nof these branches in my public repository, however, partly to keep the\nnumber of branches that downstream developers need to worry about low, and\nprimarily 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 broken\nin some areas (e.g. breaks the existing testsuite)\" and then with some\nmore work (either by the original contributor's effort or help from other\npeople on the list) becomes \"more or less done and can now be tested by\nwider audience\".  Luckily, most of them start out in the latter, better\nshape.\n\nThe \"next\" branch is to merge and test topic branches in the latter\ncategory.  In general, the branch always contains the tip of \"master\".  It\nmight not be quite rock-solid production ready, but is expected to work\nmore or less without major breakage.  I usually use \"next\" version of git\nfor my own work, so it cannot be _that_ broken to prevent me from\nintegrating and pushing the changes out.  The \"next\" branch is where new\nand exciting things take place.\n\nThe two branches \"master\" and \"maint\" are never rewound, and \"next\"\nusually will not be either (this automatically means the topics that have\nbeen merged into \"next\" are usually not rebased, and you can find the tip\nof topic branches you are interested in from the output of \"git log\nnext\"). You should be able to safely build on top of them.\n\nAfter a feature release is made from \"master\", however, \"next\" will be\nrebuilt from the tip of \"master\" using the surviving topics.  The commit\nthat replaces the tip of the \"next\" will usually have the identical tree,\nbut it will have different ancestry from the tip of \"master\".\n\nThe \"pu\" (proposed updates) branch bundles all the remainder of topic\nbranches.  The \"pu\" branch, and topic branches that are only in \"pu\", are\nsubject to rebasing in general.  By the above definition of how \"next\"\nworks, you can tell that this branch will contain quite experimental and\nobviously broken stuff.\n\nWhen a topic that was in \"pu\" proves to be in testable shape, it graduates\nto \"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 good and\nthe topic can be dropped from \"pu\" in such a case.\n\nA topic that is in \"next\" is expected to be polished to perfection before\nit is merged to \"master\" (that's why \"master\" can be expected to stay more\nstable than any released version).  Similarly to the above, I do it with\nthis:\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 next release\n(being in \"master\" is such a guarantee, unless it is later found seriously\nbroken and reverted), nor even in any future release.  There even were\ncases that topics needed reverting a few commits in them before graduating\nto \"master\", or 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 changes\nshould be sent.  As described in contrib/README, I would delegate fixes\nand enhancements in contrib/ area to the primary contributors of them.\n\nAlthough the following are included in git.git repository, they have their\nown 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 current\nshape.  Especially I would like to thank the git list regulars whose help\nI have relied on and expect to continue relying on heavily:\n\n - Linus on general design issues.\n\n - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿\n   Scharfe, Jeff King and Johannes Sixt on general implementation\n   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 on\n   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 to\n   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, Jason\n   Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and\n   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"}]}