{"thread":{"id":"6188","subject":"A note from the maintainer","startedAt":"2007-01-02T03:31:33Z","lastAt":"2007-01-02T03:47:46Z","messageCount":2,"participants":["Junio C Hamano","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30648","messageId":"7v4pra14ve.fsf@assigned-by-dhcp.cox.net","threadId":"6188","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T03:31:33Z","receivedAt":"2007-01-02T03:31:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It has been a while since I sent this message out the last time,\nand there seem to be some new people on the git list.\n\nThis message talks about how git.git is managed, and how you can\nwork with it.\n\n\n* IRC and Mailing list\n\nMany active members of development community hang around on #git\nIRC channel.  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\nThe development however is primarily done on this mailing list\nyou are reading right now.  If you have patches, please send\nthem to the list, following Documentation/SubmittingPatches.\n\nI usually read all patches posted to the list, and follow almost\nall the discussions on the list, unless the topic is about an\nobscure corner that I do not personally use.  But I am obviously\nnot perfect.  If you sent a patch that you did not hear from\nanybody for three days, that is a very good indication that it\nwas dropped on the floor --- please do not hesitate to remind\nme.\n\n\nThe list from time to time gets messages that either\n\n - state something incorrect, with a certain authoritative tone,\n   without doing minimum homework.\n\n - try to rehash issues that have been ruled some time ago\n   without bringing anything new to the table,\n\nI used to try responding to such messages quickly with pointers\nto archived list messages and/or the name of the commit object\nthat settled the issue, in order to save other readers from\nwasting time on them, but that has been a huge timesink for me,\nso I'll stop doing so and simply ignore them.\n\nThis does not apply to messages from new people (the definition\nof new is rather subjective --- if I cannot connect your name\nwith a specific contribution you made to the git community, you\nare still new); I would welcome questions and comments from new\npeople on the list.  They are good sources for us to learn which\nparts of git's concepts are harder to learn and which\ndocumentation can be improved.\n\n\nThe list is available at a few public sites as well:\n\n\thttp://marc.theaimsgroup.com/?l=git\n\thttp://news.gmane.org/gmane.comp.version-control.git\n\tnntp://news.gmane.org/gmane.comp.version-control.git\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.4 done on Nov 14th last year.\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.4.3.  Usually new development will never go to this branch.\nThis branch is also pulled into \"master\" to propagate the fixes\nforward.\n\nA trivial and safe enhancement goes directly on top of \"master\".\nA new development, either initiated by myself or more often by\nsomebody found his or her own itch to scratch, does not usually\nhappen on \"master\", however.  Instead, it is forked into a\nseparate topic branch from the tip of \"master\", and first tested\nin isolation; I may make minimum fixups at this point.  Usually\nthere are a handful such topic branches that are running ahead\nof \"master\" in git.git repository.  I do not publish the tip of\nthese branches in my public repository, however, partly to keep\nthe number 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.\n\nWhen a topic that was in \"pu\" proves to be in testable shape, it\ngraduates to \"next\".  I do this with:\n\n\tgit checkout next\n        git merge 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\".  I do this with:\n\n\tgit checkout master\n        git merge 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, unless it\nis later found seriously broken and reverted), or even in _any_\nfuture release.  There even was a case that a topic needed a few\nreverting before graduating to \"master\".\n"},{"id":"30651","messageId":"20070102034746.GB27690@spearce.org","threadId":"6188","inReplyTo":"7v4pra14ve.fsf@assigned-by-dhcp.cox.net","subject":"Re: A note from the maintainer","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-02T03:47:46Z","receivedAt":"2007-01-02T03:47:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> I usually read all patches posted to the list, and follow almost\n> all the discussions on the list, unless the topic is about an\n> obscure corner that I do not personally use.  But I am obviously\n> not perfect.  If you sent a patch that you did not hear from\n> anybody for three days, that is a very good indication that it\n> was dropped on the floor --- please do not hesitate to remind\n> me.\n\nThough a contributor should probably check the `maint`, `master`,\n`next` or `pu` branches of git.git before sending a reminder.\n\nOften we find that you have accepted a patch without comment (as\nthe patch is obviously correct and nobody else had a reason to\ncomment on it).  In this case the patch will just appear in one of\nthe git.git branches, with no email indicating that.\n\n-- \nShawn.\n"}]}