From: Junio C Hamano <firstname.lastname@example.org> To: email@example.com Subject: A note from the maintainer Date: Mon, 01 Jan 2007 19:31:33 -0800 Message-ID: <firstname.lastname@example.org> (raw) It has been a while since I sent this message out the last time, and there seem to be some new people on the git list. This message talks about how git.git is managed, and how you can work with it. * IRC and Mailing list Many active members of development community hang around on #git IRC channel. Its log is available at: http://colabti.de/irclogger/irclogger_logs/git [jc: Does anybody know a shortcut for "Today's" page on this site? It irritates me having to click the latest link on this page to get to the latest] The development however is primarily done on this mailing list you are reading right now. If you have patches, please send them to the list, following Documentation/SubmittingPatches. I usually read all patches posted to the list, and follow almost all the discussions on the list, unless the topic is about an obscure corner that I do not personally use. But I am obviously not perfect. If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me. The list from time to time gets messages that either - state something incorrect, with a certain authoritative tone, without doing minimum homework. - try to rehash issues that have been ruled some time ago without bringing anything new to the table, I used to try responding to such messages quickly with pointers to archived list messages and/or the name of the commit object that settled the issue, in order to save other readers from wasting time on them, but that has been a huge timesink for me, so I'll stop doing so and simply ignore them. This does not apply to messages from new people (the definition of new is rather subjective --- if I cannot connect your name with a specific contribution you made to the git community, you are still new); I would welcome questions and comments from new people on the list. They are good sources for us to learn which parts of git's concepts are harder to learn and which documentation can be improved. The list is available at a few public sites as well: http://marc.theaimsgroup.com/?l=git http://news.gmane.org/gmane.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git * Repositories and branches. My public git.git repository is at: git://git.kernel.org/pub/scm/git/git.git/ It is mirrored at Pasky's repo.or.cz as well. There are three branches in git.git repository that are not about the source tree of git: "todo", "html" and "man". The first one is meant to contain TODO list for me, but I am not good at maintaining such a list so it is not as often updated as I would have liked. It also contains some helper scripts I use to maintain it. The "html" and "man" are autogenerated documentation from the tip of the "master" branch; the tip of "html" is extracted to be visible at kernel.org at: http://www.kernel.org/pub/software/scm/git/docs/ The script to auto-maintain these two documentation branches are found in "todo" branch as dodoc.sh script, if you are interested. There are four branches in git.git repository that track the source tree of git: "master", "maint", "next", and "pu". The "master" branch is meant to contain what are reasonably tested and ready to be used in a production setting. There could occasionally be minor breakages or brown paper bag bugs but they are not expected to be anything major. Every now and then, a "feature release" is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was v1.4.4 done on Nov 14th last year. Whenever a feature release is made, "maint" branch is forked off from "master" at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are typically named with four dotted decimal, named after the feature release they are updates to; the last such release was v188.8.131.52. Usually new development will never go to this branch. This branch is also pulled into "master" to propagate the fixes forward. A trivial and safe enhancement goes directly on top of "master". A new development, either initiated by myself or more often by somebody found his or her own itch to scratch, does not usually happen on "master", however. Instead, it is forked into a separate topic branch from the tip of "master", and first tested in isolation; I may make minimum fixups at this point. Usually there are a handful such topic branches that are running ahead of "master" in git.git repository. I do not publish the tip of these branches in my public repository, however, partly to keep the number of branches that downstream developers need to worry about and primarily because I am lazy. I judge the quality of topic branches, taking advices from the mailing list discussions. Some of them start out as "good idea but obviously is broken in some areas (e.g. breaks the existing testsuite)" and then with some more work (either by the original contributor or help from other people on the list) becomes "more or less done and can now be tested by wider audience". Luckily, most of them start out in the latter, better shape. The "next" branch is to merge and test topic branches in the latter category with "master". In general it should always contain the tip of "master". They may not be quite production ready, but are expected to work more or less without major breakage. I usually use "next" version of git for my own work. "next" is where new and exciting things take place. The above three branches, "master", "maint" and "next" are never rewound, so you should be able to safely track them (that means the topics that have been merged into "next" are not rebased). The "pu" (proposed updates) branch bundles all the remaining topic branches. The topic branches and "pu" are subject to rebasing in general. Especially "pu" is almost always rewound to the tip of "next" and reconstructed to contain the remaining topic branches. When a topic that was in "pu" proves to be in testable shape, it graduates to "next". I do this with: git checkout next git merge that-topic-branch Sometimes, an idea that looked promising turns out to be not so hot and the topic can be dropped from "pu" in such a case. A topic that is in "next" is _expected_ to be tweaked and fixed to perfection before it is merged to "master". I do this with: git checkout master git merge that-topic-branch git branch -d that-topic-branch However, being in "next" is not a guarantee to appear in the next release (being in "master" is such a guarantee, unless it is later found seriously broken and reverted), or even in _any_ future release. There even was a case that a topic needed a few reverting before graduating to "master".
next reply index Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-01-02 3:31 Junio C Hamano [this message] 2007-01-02 3:47 ` Shawn O. Pearce -- strict thread matches above, loose matches on Subject: below -- 2017-11-28 5:20 Junio C Hamano 2017-10-30 6:19 Junio C Hamano 2017-10-30 12:50 ` Johannes Schindelin 2017-08-04 16:54 Junio C Hamano 2017-07-13 23:43 Junio C Hamano 2017-06-24 23:24 Junio C Hamano 2017-03-24 21:19 Junio C Hamano 2017-03-20 21:39 Junio C Hamano 2017-02-24 19:29 Junio C Hamano 2016-11-29 21:24 Junio C Hamano 2016-10-03 22:31 Junio C Hamano 2016-09-03 2:17 Junio C Hamano 2016-09-03 10:26 ` Jakub Narębski 2016-09-07 16:16 ` Junio C Hamano 2016-08-12 19:55 Junio C Hamano 2016-08-12 22:42 ` Eric Wong 2016-08-13 8:10 ` Jeff King 2016-08-13 9:04 ` Eric Wong 2016-08-13 11:14 ` Jeff King 2016-08-14 1:27 ` Eric Wong 2016-08-14 2:12 ` Eric Wong 2016-08-14 12:23 ` Jeff King 2016-08-14 12:19 ` Jeff King 2016-08-14 15:00 ` Philip Oakley 2016-08-14 22:52 ` Eric Wong 2016-07-11 20:14 Junio C Hamano 2016-06-13 19:45 Junio C Hamano 2016-05-19 17:48 Junio C Hamano 2016-04-29 22:04 Junio C Hamano 2016-03-28 22:42 Junio C Hamano 2016-02-06 0:07 Junio C Hamano 2016-01-04 23:44 Junio C Hamano 2015-11-05 23:14 Junio C Hamano 2015-11-06 10:50 ` Xue Fuqiao 2015-11-06 17:38 ` Junio C Hamano 2015-09-28 23:20 Junio C Hamano 2015-08-28 21:12 Junio C Hamano 2015-07-15 21:43 Junio C Hamano 2015-04-30 19:51 Junio C Hamano 2015-05-08 14:46 ` Christian Couder 2015-05-08 16:25 ` Junio C Hamano 2015-03-23 21:38 Junio C Hamano 2015-03-06 23:33 Junio C Hamano 2015-02-05 22:53 Junio C Hamano 2014-11-26 23:09 Junio C Hamano 2013-03-13 20:26 Junio C Hamano 2013-01-28 20:48 Junio C Hamano 2013-01-01 0:27 Junio C Hamano 2012-12-10 23:16 Junio C Hamano 2012-10-21 22:10 Junio C Hamano 2012-10-08 20:08 Junio C Hamano 2012-09-18 23:14 Junio C Hamano 2012-08-20 3:16 Junio C Hamano 2012-06-19 23:53 Junio C Hamano 2012-03-06 7:10 Junio C Hamano 2012-01-27 21:31 [ANNOUNCE] Git 1.7.9 Junio C Hamano 2012-01-27 21:41 ` A note from the maintainer Junio C Hamano 2011-10-24 15:32 Junio C Hamano 2011-10-05 2:22 Junio C Hamano 2011-10-15 5:47 ` Martin von Zweigbergk 2011-10-16 7:24 ` Junio C Hamano 2011-08-24 23:51 Junio C Hamano 2011-04-25 21:05 A Note from the Maintainer Junio C Hamano 2011-01-31 5:51 A note from the maintainer Junio C Hamano 2010-09-19 1:28 Junio C Hamano 2010-07-21 22:18 Junio C Hamano 2010-02-13 1:24 Junio C Hamano 2010-01-01 0:09 Junio C Hamano 2009-07-29 21:15 Junio C Hamano 2009-05-07 7:09 Junio C Hamano 2009-05-07 13:40 ` Baz 2009-05-07 16:30 ` Junio C Hamano 2009-03-04 19:52 Junio C Hamano 2008-12-25 6:48 Junio C Hamano 2008-08-17 21:16 [ANNOUNCE] GIT 1.6.0 Junio C Hamano 2008-08-17 23:58 ` A note from the maintainer Junio C Hamano 2008-06-18 23:24 [ANNOUNCE] GIT 1.5.6 Junio C Hamano 2008-06-19 7:24 ` A note from the maintainer Junio C Hamano 2008-07-14 5:51 ` Junio C Hamano 2008-04-09 9:44 Junio C Hamano 2008-02-17 9:16 Junio C Hamano 2008-03-09 10:57 ` Junio C Hamano 2008-02-02 4:35 Junio C Hamano 2008-02-02 11:06 ` Jakub Narebski 2008-01-08 8:57 Junio C Hamano 2008-01-08 9:57 ` Jakub Narebski 2008-01-08 10:03 ` Junio C Hamano 2007-09-02 6:31 [ANNOUNCE] GIT 1.5.3 Junio C Hamano 2007-09-02 6:34 ` A note from the maintainer Junio C Hamano 2007-04-04 9:12 [ANNOUNCE] GIT 1.5.1 Junio C Hamano 2007-04-04 18:26 ` A note from the maintainer Junio C Hamano 2007-05-20 9:54 ` Junio C Hamano 2007-02-14 3:14 [ANNOUNCE] GIT 1.5.0 Junio C Hamano 2007-02-16 22:31 ` A note from the maintainer Junio C Hamano 2007-02-17 2:35 ` Johannes Schindelin 2007-02-23 6:03 ` Junio C Hamano 2006-10-24 9:16 Junio C Hamano 2006-10-24 9:37 ` Jakub Narebski
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
firstname.lastname@example.org mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox