From: Junio C Hamano <hidden> Date: 2016-08-12 19:55:57
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address [off-list ref]. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://public-inbox.org/git/http://marc.info/?l=githttp://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
is still available. An alternative
nntp://news.public-inbox.org/inbox.comp.version-control.git
will become usable once it catches up with old messages.
When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:
http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/githttp://colabti.org/irclogger/irclogger_log/git-devel
There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).
Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at [off-list ref].
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list [off-list ref]. This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:
- people triaging and fixing reported vulnerabilities
- people operating major git hosting sites with many users
- people packaging and distributing git to large numbers of people
where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.
* Repositories and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/cgit/git/git.githttps://kernel.googlesource.com/pub/scm/git/githttp://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:
https://git.github.io/htmldocs/git.html
* How various branches are used.
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 very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
The last such release was 2.9 done on June 13th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it. Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues. The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release). These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.9.3"
is the third maintenance release for the "2.9" series).
New features never go to the 'maint' branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master". Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".
The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen. There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch. This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more. The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work. When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".
* Other people's trees.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).
From: Eric Wong <hidden> Date: 2016-08-12 22:43:01
Junio C Hamano [off-list ref] wrote:
For those who prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
is still available. An alternative
nntp://news.public-inbox.org/inbox.comp.version-control.git
will become usable once it catches up with old messages.
Mostly caught up, I injected 33 more today which were
cross-posted (which tripped up some of my anti-spam rules) or
simply missed by gmane.
There may be more in some personal archives gmane doesn't
have...
I've also added NNTP links (including gmane) to the footer in
public-inbox.org/git
Some of the generated links have %40 in them which is the URI
escape for '@'. I'll make a change to keep the '@' unescaped to
lessen confusion.
Due to the use of SQLite as a stable store for NNTP article
numbers; public-inbox can also do partial matching (up to 100
results, currently) to help correct legitimate mistakes; but I
wouldn't rely on it too much:
public-inbox.org/git/Pine.LNX.4.58.0504150753440
From: Jeff King <hidden> Date: 2016-08-13 08:10:30
On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:
Junio C Hamano [off-list ref] wrote:
quoted
For those who prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
is still available. An alternative
nntp://news.public-inbox.org/inbox.comp.version-control.git
will become usable once it catches up with old messages.
Mostly caught up, I injected 33 more today which were
cross-posted (which tripped up some of my anti-spam rules) or
simply missed by gmane.
There may be more in some personal archives gmane doesn't
have...
Is there an easy way to get _just_ the list of message-ids you are
storing (I know I can download the whole archive, but it's big)?
Then I can cross-reference with my archive. I doubt I'll have anything
significant that you don't. My archive of the early days was pulled from
gmane, though I have been collecting steadily via mailing list delivery
since 2007 or so.
-Peff
From: Eric Wong <hidden> Date: 2016-08-13 09:04:37
Jeff King [off-list ref] wrote:
On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:
quoted
Junio C Hamano [off-list ref] wrote:
quoted
is still available. An alternative
nntp://news.public-inbox.org/inbox.comp.version-control.git
will become usable once it catches up with old messages.
Mostly caught up, I injected 33 more today which were
cross-posted (which tripped up some of my anti-spam rules) or
simply missed by gmane.
There may be more in some personal archives gmane doesn't
have...
Is there an easy way to get _just_ the list of message-ids you are
storing (I know I can download the whole archive, but it's big)?
XHDR (or HDR) over NNTP should do it (that's how I checked
against gmane):
--------8<-----
use Net::NNTP;
my $nntp = Net::NNTP->new($ENV{NNTPSERVER} || 'news.public-inbox.org');
my ($num, $first, $last) = $nntp->group('inbox.comp.version-control.git');
my $batch = 10000;
my $i;
for ($i = $first; $i < $last; $i += $batch) {
my $j = $i + $batch - 1;
$j = $last if $j > $last;
my $num2mid = $nntp->xhdr('Message-ID', "$i-$j");
for my $n ($i..$j) {
defined(my $mid = $num2mid->{$n}) or next;
print "$mid\n";
}
}
# and I forgot to optimize XHDR/HDR further in public-inbox-nntpd.
# Oh well, it seems to work, at least.
Then I can cross-reference with my archive. I doubt I'll have anything
significant that you don't. My archive of the early days was pulled from
gmane, though I have been collecting steadily via mailing list delivery
since 2007 or so.
What's odd is there's some messages with two Message-ID fields
from gmane from the old days, too. I'll dig a bit another time.
From: Jeff King <hidden> Date: 2016-08-13 11:14:56
On Sat, Aug 13, 2016 at 09:04:32AM +0000, Eric Wong wrote:
quoted
Is there an easy way to get _just_ the list of message-ids you are
storing (I know I can download the whole archive, but it's big)?
XHDR (or HDR) over NNTP should do it (that's how I checked
against gmane):
--------8<-----
use Net::NNTP;
my $nntp = Net::NNTP->new($ENV{NNTPSERVER} || 'news.public-inbox.org');
my ($num, $first, $last) = $nntp->group('inbox.comp.version-control.git');
my $batch = 10000;
my $i;
for ($i = $first; $i < $last; $i += $batch) {
my $j = $i + $batch - 1;
$j = $last if $j > $last;
my $num2mid = $nntp->xhdr('Message-ID', "$i-$j");
for my $n ($i..$j) {
defined(my $mid = $num2mid->{$n}) or next;
print "$mid\n";
}
}
Thanks, that's perfect.
I collected the message-ids from my archive. Interestingly, I had a
dozen or so that did not have message-ids at all. I think most of them
are from patches that put the "From " line in the body, like this one:
http://public-inbox.org/git/20070311033833.GB10781@spearce.org/
and then they got corrupted on a round-trip through one of the bad mbox
formats (probably downloading from gmane, I'd guess; the export there
uses mbox, and I use maildir myself, so it probably got split badly
years ago). Anyway, public-inbox seems to get this case right, which is
good.
I had several hundred message ids that you didn't. About half of them
were spam or other junk. I weeded them out manually (mostly by picking
through the subjects, so possibly there's some error). The end result is
279 messages that I think are legitimate that you don't have.
I'll send them to you off-list, as the mbox is about 300K, which the
list will reject.
-Peff
From: Eric Wong <hidden> Date: 2016-08-14 08:37:02
Jeff King [off-list ref] wrote:
I collected the message-ids from my archive. Interestingly, I had a
dozen or so that did not have message-ids at all. I think most of them
are from patches that put the "From " line in the body, like this one:
http://public-inbox.org/git/20070311033833.GB10781@spearce.org/
and then they got corrupted on a round-trip through one of the bad mbox
formats (probably downloading from gmane, I'd guess; the export there
uses mbox, and I use maildir myself, so it probably got split badly
years ago). Anyway, public-inbox seems to get this case right, which is
good.
Yes, I was somewhat careful to check for proper mboxes from gmane;
I just missed entire ranges :x
What's also interesting about the thread you highlighed is the
extra '<>' when you started that thread; and I have a bug where
I strip off an extra '>' which needs to be fixed...
I wonder if I should make "editorial" changes to fixup user bugs,
but then there's also bunch of messages which are replies to <y>
because git-send-email had usability problems back in the day...
I had several hundred message ids that you didn't. About half of them
were spam or other junk. I weeded them out manually (mostly by picking
through the subjects, so possibly there's some error). The end result is
279 messages that I think are legitimate that you don't have.
I'll send them to you off-list, as the mbox is about 300K, which the
list will reject.
Thanks, should all be imported.
The one which started the thread belonging to
[off-list ref] was really iffy,
but I kept it; as well as an "unsubscribe" one; I guess those
people are shamed for life :)
git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4
is totally legit, but doesn't seem to show up properly,
so there's another bug I need to fix. For the moment, the
following also works:
public-inbox.org/git/b75bb577d76487bc9aebf0656d4e03eff22049f4/
(but I guess it was reposted as [off-list ref]
From: Eric Wong <hidden> Date: 2016-08-14 09:21:23
Eric Wong [off-list ref] wrote:
Thanks, should all be imported.
Oops, missed one which was missing X-Mailing-List (causing
it to not get imported) and had "X-No-Archive: yes" set;
which meant I couldn't get it from gmane this year.
Hmm... XNAY defeats the point of public-inbox (and probably the
point of public-to-all mailing lists); so I don't think it's
worth honoring.
From: Jeff King <hidden> Date: 2016-08-14 12:19:33
On Sun, Aug 14, 2016 at 01:27:06AM +0000, Eric Wong wrote:
What's also interesting about the thread you highlighed is the
extra '<>' when you started that thread; and I have a bug where
I strip off an extra '>' which needs to be fixed...
Oh, that's interesting. It's not in the message that started the thread;
the bug is in the in-reply-to headers of the patches themselves. I don't
remember what I was using to send patches back then. It might have been
send-email, and I suspect I did:
git send-email --in-reply-to='<whatever>'
after cutting-and-pasting '<whatever>' from the cover letter.
I wonder if I should make "editorial" changes to fixup user bugs,
but then there's also bunch of messages which are replies to <y>
because git-send-email had usability problems back in the day...
I wouldn't go too far in editorial changes. I made a few when skimming
the messages I just sent for spam, and dropped some empty messages, or
"unsubscribe me" ones. But it's not worth the human effort to go back
and scrub list archives from 10 years ago.
Fixing up an extra "<>" is easily done once in your parsing scripts,
though, and I'd be surprised if I'm the only one to have made that
mistake.
The one which started the thread belonging to
[off-list ref] was really iffy,
I think I exercised editorial control over similar "your software is now
listed in our archive!" messages in what I sent. But yeah, there's going
to be some spam and some cruft in the archive. It's just a fact of life.
The solution is good searching and organizing tools to find the signal
you're looking for, not to make sure the noise hits zero.
git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4
is totally legit, but doesn't seem to show up properly,
Heh, yeah, I saw that one (and I think it broke some of my initial
scripting, which foolishly assumed nobody had message-ids with spaces in
them).
-Peff
From: Jeff King <hidden> Date: 2016-08-14 12:23:57
On Sun, Aug 14, 2016 at 02:12:34AM +0000, Eric Wong wrote:
Eric Wong [off-list ref] wrote:
quoted
Thanks, should all be imported.
Oops, missed one which was missing X-Mailing-List (causing
it to not get imported) and had "X-No-Archive: yes" set;
which meant I couldn't get it from gmane this year.
Hmm... XNAY defeats the point of public-inbox (and probably the
point of public-to-all mailing lists); so I don't think it's
worth honoring.
I didn't even think to look for that header. It looks like it's
basically all one guy. I would argue that it should not be honored for
the git dev list, if only because those emails are a record of the
provenance of patches. The Signed-off-by is a certification that the
patch is OK to submit, but it's presumably worth more with an audit
trail including the email headers.
(Also, I have always found it a little silly to post publicly with a
"please don't anybody record this!" header).
-Peff
From: Philip Oakley <hidden> Date: 2016-08-14 15:01:01
From: "Eric Wong" <redacted>
Yes, I was somewhat careful to check for proper mboxes from gmane;
I just missed entire ranges :x
There were a number of messages that were listed by gmane as being in the
various Git for Windows lists such as msysgit, especially when the messages
went to both lists (as the issue had common cause) that failed to get onto
the regualr gmane list.
Are these something that has been included?
Philip
A quick search on a possible message gave
https://public-inbox.org/git/55BF6808.1000500@web.de/ which has no parent,
but that parent actually only went to the msysgit list, so no real surprise
there, but I do remember some other cases that were on list - I just can't
find them at the moment :-(.
From: Eric Wong <hidden> Date: 2016-08-14 22:52:23
Philip Oakley [off-list ref] wrote:
From: "Eric Wong" <redacted>
quoted
Yes, I was somewhat careful to check for proper mboxes from gmane;
I just missed entire ranges :x
There were a number of messages that were listed by gmane as being in the
various Git for Windows lists such as msysgit, especially when the messages
went to both lists (as the issue had common cause) that failed to get onto
the regualr gmane list.
Are these something that has been included?
If they were on both lists, yes, gmane seems to miss some of
those messages, unfortunately.
Philip
A quick search on a possible message gave
https://public-inbox.org/git/55BF6808.1000500@web.de/ which has no parent,
but that parent actually only went to the msysgit list, so no real surprise
there, but I do remember some other cases that were on list - I just can't
find them at the moment :-(.
If a message was only posted exclusively on other lists, it
should stay there and it's archives. public-inbox provides a
way to lookup external messages by Message-ID for this reason.
Is there a way to lookup messages by Message-ID from the msysgit
archives? I could add it to the existing list of alternate
Message-ID lookup services:
https://public-inbox.org/meta/20160814054731.26194-1-e@80x24.org/
GoogleGroups doesn't seem usable without JavaScript at all,
unfortunately :<
I don't think the msysgit archives would be too large and I
wouldn't mind hosting them myself. But, users on GoogleGroups
may not be used to our conventions and not appreciate having
their unobfuscated addresses exposed or reply-to-all...
I will probably add an option to support centralized lists to
public-inbox sometime, though. I don't like centralization,
but completely inaccessible archives are worse.