{"thread":{"id":"27177","subject":"A Note from the Maintainer","startedAt":"2011-04-25T21:05:38Z","lastAt":"2011-04-25T21:05:38Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166331","messageId":"7vvcy2hwil.fsf@alter.siamese.dyndns.org","threadId":"27177","inReplyTo":null,"subject":"A Note from the Maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-25T21:05:38Z","receivedAt":"2011-04-25T21:05:38Z","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* Mailing list and the community\n\nThe development is primarily done on the Git mailing list. Help\nrequests, feature proposals, bug reports and patches should be sent to\nthe list address <git@vger.kernel.org>.  You don't have to be\nsubscribed to send messages.  The convention on the list is to keep\neverybody involved on Cc:, so it is unnecessary to ask \"Please Cc: me,\nI am not subscribed\".\n\nBefore sending patches, please read Documentation/SubmittingPatches\nand Documentation/CodingGuidelines to familiarize yourself with the\nproject convention.\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,\nbut it also is possible that it was simply lost in the noise.  Please\ndo not hesitate to send a reminder message in such a case.  Messages\ngetting lost in the noise is a sign that people involved don't have\nenough mental/time bandwidth to process them right at the moment, and\nit often helps to wait until the list traffic becomes calmer before\nsending such a reminder.\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 gmane\nnewsgroup to \"jump to\" the article.\n\nSome members of the development community can sometimes also be found\non the #git IRC channel on Freenode.  Its log is available at:\n\n        http://colabti.org/irclogger/irclogger_log/git\n\n* Reporting bugs\n\nWhen you think git does not behave as you expect, please do not stop your\nbug report with just \"git does not work\".  \"I tried to do X but it did not\nwork\" is not much better, neither is \"I tried to do X and git did Y, which\nis broken\".  It often is that what you expect is _not_ what other people\nexpect, and chances are that what you expect is very different from what\npeople who have worked on git have expected (otherwise, the behavior\nwould have been changed to match that expectation long time ago).\n\nPlease remember to always state\n\n - what you wanted to do;\n\n - what you did (the version of git and the command sequence to reproduce\n   the behavior);\n\n - what you saw happen;\n\n - what you expected to see; and\n\n - how the last two are different.\n\nSee http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further\nhints.\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 (there are a\nfew other mirrors I push into at sourceforge and github as well).\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: \"html\", \"man\", and \"todo\".\n\nThe \"html\" and \"man\" are auto-generated documentation from the tip of\nthe \"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 links to\ndocumentation of older releases.\n\nThe \"todo\" branch was originally meant to contain a TODO list for me,\nbut is mostly used to keep some helper scripts I use to maintain git.\nFor example, the script to maintain the two documentation branches are\nfound there as dodoc.sh, which may be a good demonstration of how to\nuse 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\".\n\nThe \"master\" branch is meant to contain what are very well tested and\nready to be used in a production setting.  Every now and then, a \"feature\nrelease\" is cut from the tip of this branch and they typically are named\nwith three dotted decimal digits.  The last such release was 1.7.5 done on\nApr 24, 2011.  You can expect that the tip of the \"master\" branch is\nalways more stable than any of the released versions.\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.7.4.5.  New features never go to this branch.  This branch is also\nmerged into \"master\" to propagate the fixes forward.\n\nA new development does not usually happen on \"master\". When you send a\nseries of patches, after review on the mailing list, a separate topic\nbranch is forked from the tip of \"master\" and your patches are queued\nthere, and kept out of \"master\" while people test it out.  The quality of\ntopic branches are judged primarily by the mailing list discussions.\n\nTopic branches that are in good shape are merged to the \"next\" branch. In\ngeneral, the \"next\" branch always contains the tip of \"master\".  It might\nnot be quite rock-solid production ready, but is expected to work more or\nless without major breakage. The \"next\" branch is where new and exciting\nthings take place. A topic that is in \"next\" is expected to be polished to\nperfection before it is merged to \"master\" (that's why \"master\" can be\nexpected to stay more stable than any released version).\n\nThe \"pu\" (proposed updates) branch bundles all the remaining topic\nbranches. The topics on the branch are not complete, well tested, nor well\ndocumented and need further work. When a topic that was in \"pu\" proves to\nbe in testable shape, it is merged to \"next\".\n\nYou can run \"git log --first-parent master..pu\" to see what topics are\ncurrently in flight.  Sometimes, an idea that looked promising turns out\nto be not so good and the topic can be dropped from \"pu\" in such a case.\n\nThe two branches \"master\" and \"maint\" are never rewound, and \"next\"\nusually will not be either.  After a feature release is made from\n\"master\", however, \"next\" will be rebuilt from the tip of \"master\"\nusing the topics that didn't make the cut in the feature release.\n\nNote that being in \"next\" is not a guarantee to appear in the next\nrelease, nor even in any future release.  There were cases that topics\nneeded reverting a few commits in them before graduating to \"master\", or a\ntopic that already was in \"next\" was reverted from \"next\" because fatal\nflaws were found in it after it was merged.\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 git-gui project, maintained by Pat Thoyts:\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 Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,\n   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes\n   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,\n   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and\n   implementation issues and reviews on the mailing list.\n\n - Shawn and Nicolas Pitre on pack issues.\n\n - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on\n   cvsserver and cvsimport.\n\n - Paul Mackerras on gitk.\n\n - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.\n\n - Simon Hausmann and Pete Wyckoff on git-p4.\n\n - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on\n   gitweb.\n\n - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on\n   documentation (and countless others for proofreading and fixing).\n\n - Alexandre Julliard on Emacs integration.\n\n - David Aguilar and Charles Bailey for taking good care of git-mergetool\n   (and Theodore Ts'o for creating it in the first place) and git-difftool.\n\n - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their\n   effort to move things forward on the Windows front.\n\n - People on non-Linux platforms for keeping their eyes on portability;\n   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,\n   Brandon Casey, Jeff King, 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"}]}