{"thread":{"id":"6034","subject":"A note from the maintainer","startedAt":"2006-10-24T09:16:43Z","lastAt":"2006-10-24T09:37:23Z","messageCount":2,"participants":["Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29834","messageId":"7vk62qhy4k.fsf@assigned-by-dhcp.cox.net","threadId":"6034","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-24T09:16:43Z","receivedAt":"2006-10-24T09:16:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Since there seem to be many new people on the git list, I\nthought it might be worthwhile to talk about how git.git is\nmanaged, and how you can work with it.\n\n* Mailing list.\n\nThe development is primarily done on this mailing list you are\nreading right now.\n\nIf you have patches, please send them to the list, following\nDocumentation/SubmittingPatches.\n\nThe list is available at various public sites as well:\n\n\thttp://news.gmane.org/gmane.comp.version-control.git\n\thttp://marc.theaimsgroup.com/?l=git\n\nMany active members of development community hang around on #git\nIRC channel as well.  Its log is available at:\n\n\thttp://colabti.de/irclogger/irclogger_logs/git\n\n[jc: Does anybody know a shortcut for \"Today's\" page on this\n site?  It irritates me having to click the latest link on this\n page to get to the latest]\n\n\n* Repositories and branches.\n\nMy public git.git repository is at:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\nIt is mirrored at Pasky's repo.or.cz as well.\n\nThere are three branches in git.git repository that are not\nabout the source tree of git: \"todo\", \"html\" and \"man\".  The\nfirst one is meant to contain TODO list for me, but I am not\ngood at maintaining such a list so it is not as often updated as\nI would have liked.  It also contains some helper scripts I\nuse to maintain it.\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\thttp://www.kernel.org/pub/software/scm/git/docs/\n\nThe script to auto-maintain these two documentation branches are\nfound in \"todo\" branch as dodoc.sh script, if you are interested.\n\nThere are four branches in git.git repository that track the\nsource tree of git: \"master\", \"maint\", \"next\", and \"pu\".\n\nThe \"master\" branch is meant to contain what are reasonably\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.  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 v1.4.3 done on Oct 18th.\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 typically named with four dotted decimal, named after the\nfeature release they are updates to; the last such release was\nv1.4.3.2 was done tonight.  Usually new development will never\ngo to this branch.  This branch is also pulled into \"master\" to\npropagate 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 you\nfound your own itch to scratch, does not usually happen on\n\"master\", however.  Instead, it is forked into a separate topic\nbranch from the tip of \"master\", and first tested in isolation;\nI may make minimum fixups at this point.  Usually there are a\nhandful such topic branches that are running ahead of \"master\"\nin git.git repository.  I do not publish the tip of these\nbranches in my public repository, however, partly to keep the\nnumber of branches that downstream developers need to worry\nabout and primarily because I am lazy.\n\nI judge the quality of topic branches, taking advices from the\nmailing list discussions.  Some of them start out as \"good idea\nbut obviously is broken in some areas (e.g. breaks the existing\ntestsuite)\" and then with some more work (either by the original\ncontributor or help from other people on the list) becomes \"more\nor less done and can now be tested by wider audience\".  Luckily,\nmost of them start out in the latter, better shape.\n\nThe \"next\" branch is to merge and test topic branches in the\nlatter category with \"master\".  In general it should always\ncontain the tip of \"master\".  They may not be quite production\nready, but are expected to work more or less without major\nbreakage.  I usually use \"next\" version of git for my own work.\n\"next\" is where new and exciting things take place.\n\nThe above three branches, \"master\", \"maint\" and \"next\" are never\nrewound, so you should be able to safely track them (that means\nthe topics that have been merged into \"next\" are not rebased).\n\nThe \"pu\" (proposed updates) branch bundles all the remaining\ntopic branches.  The topic branches and \"pu\" are subject to\nrebasing in general.  Especially \"pu\" is almost always rewound\nto the tip of \"next\" and reconstructed to contain the remaining\ntopic branches.  What this means is that immediately after\ncloning from git.git, it is advisable to mark \"pu\" in your\nremotes/origin that it does not necessarily fast-forwards, like\nthis:\n\n\t$ cat .git/remotes/origin\n        URL: git://git.kernel.org/pub/scm/git/git.git\n        Pull: refs/heads/master:refs/heads/origin\n        Pull: refs/heads/maint:refs/heads/maint\n        Pull: refs/heads/next:refs/heads/next\n        Pull: +refs/heads/pu:refs/heads/pu\n\nWhen a topic that was in \"pu\" proves to be in testable shape, it\ngraduates to \"next\".  This is done by:\n\n\tgit checkout next\n        git pull . that-topic-branch\n\nSometimes, an idea that looked promising turns out to be not so\nhot 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\nto perfection before it is merged to \"master\".  It is done by:\n\n\tgit checkout master\n        git pull . that-topic-branch\n        git branch -d that-topic-branch\n\nHowever, being in \"next\" is not a guarantee to appear in the\nnext release (being in \"master\" _is_ such a guarantee), or even\nin _any_ future release.  There even was a case that a topic\nneeded a few reverting before graduating to \"master\".\n"},{"id":"29838","messageId":"ehkmrn$385$1@sea.gmane.org","threadId":"6034","inReplyTo":"7vk62qhy4k.fsf@assigned-by-dhcp.cox.net","subject":"Re: A note from the maintainer","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-24T09:37:23Z","receivedAt":"2006-10-24T09:37:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> * Mailing list.\n> \n> The development is primarily done on this mailing list you are\n> reading right now.\n> \n> If you have patches, please send them to the list, following\n> Documentation/SubmittingPatches.\n> \n> The list is available at various public sites as well:\n> \n>         http://news.gmane.org/gmane.comp.version-control.git\n>         http://marc.theaimsgroup.com/?l=git\n\nIt is also available via GMane NNTP (mail to news) interface as\n\n  nntp://news.gmane.org/gmane.comp.version-control.git\n\nso you can read it using your favourite news reader, without need\nto be subscribed to mailing list.\n\nIt is better to send patches via email, not via news as 1.) news reader are\nmore likely to munge whitespace, 2) mail<->news gateway might munge\nwhitespace on it's own, though.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}