* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-27 23:10 UTC (permalink / raw)
To: git
In-Reply-To: <bab6a2ab0901271504j73dce7afjf8436c3c7c83b770@mail.gmail.com>
To expand further, here's the output from the command line when this happened.
~/Development/github(jetty)$ git push pjhyett jetty
fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
error: pack-objects died with strange error
error: failed to push some refs to 'git@github.com:pjhyett/github.git'
~/Development/github(jetty)$ git fsck --full
warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains
zero-padded file modes
warning in tree 56fe2a1a3da446606aadf8861feccd592b636a34: contains
zero-padded file modes
warning in tree 99e2a89db2aa9846fc2491b3e4ccd8861e8d3283: contains
zero-padded file modes
warning in tree a6e532d7451bc4aadab86ade84df69180fab4765: contains
zero-padded file modes
dangling blob 43611213c3eff91e5fe071cf2907f69a99b630b2
dangling commit b28b3ecd85a04ecbd1dcb8aedc6886a465f6ab18
dangling commit 13a70c8687527936d2c375f0f7aefe71142de3c7
dangling commit 2aa94c1199cb332f58b70c6ce19d8de3c45c6f3c
dangling blob 61b910e7a97600691fd279e4db3662e751fb5fb7
dangling commit c4f19e16208d59666323ae0575435720be9b865d
dangling commit 19245f5d77aa449eebb4a0521b5ff4f6ce1865ab
dangling commit 122995fb7c9a7e459b0801e0647eb918bea878bf
dangling commit 7d51e3926b8720d1c7cad19aeb35d6ab4af755fd
dangling commit 1162dd21370439416967a34915832125e4975239
dangling blob 8c630b66927f6022a72e457be308de5c9ad9f4e6
dangling blob 827d4d8855fe6a3a7856ea35cd641192140f2dcd
dangling commit c9824506855d6cad9b52df115aa267d70872c2cc
dangling blob fb9bbfc3aa17c5d1ae4e15c862bd874e3476fcfc
dangling commit 46a4b39245a58ad867010f272991d6233db6288b
dangling commit d6bf5f30853fecea745559dc3a718113f3619634
dangling blob d4d66fc4c3a2cbc94d8ed9cb30a6b56daa86e58f
dangling commit b4f8d7766e8905e5ac6d6cfeeaf7370a716c24a2
Very odd that the bad object didn't appear in the fsck output.
I was able to fix the error by copying a non-corrupted version of the
object back into .git/objects and then running a git fetch.
-PJ
^ permalink raw reply
* Re: [PATCH v2 0/6] rebase simplifications
From: Johannes Schindelin @ 2009-01-27 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9c1hyp.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 27 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > Changes vs v1:
> >
> > removed the "rnyn" blurt (which probably marsk me as Alpine user...)
> >
> > removed the SHELL_PATH handling; it is a miracle to me why it works, but
> > I'd rather not meddle with the magic now that you pointed it out
> >
> > Moved test_commit and test_merge into test-lib.sh
> >
> > Fixed the quoting in test_commit and test_merge
> >
> > AFAIR that's all...
Oh, I forgot the ${2:-...} thing...
> Thanks; looks much nicer (not just relative to v1 but compared to the
> original).
Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Johannes Schindelin @ 2009-01-27 23:11 UTC (permalink / raw)
To: Steven Noonan; +Cc: Geoffrey Lee, git
In-Reply-To: <f488382f0901271501y2cf6dd84idc96e14aea1693e5@mail.gmail.com>
Hi,
On Tue, 27 Jan 2009, Steven Noonan wrote:
> On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 27 Jan 2009, Geoffrey Lee wrote:
> >
> >> On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
> >> <stephen@exigencecorp.com> wrote:
> >> > It kind of works on my Vista 64-bit system--I do not see the shell
> >> > extensions in the native Windows Explorer (which is 64 bit), but I
> >> > do see the shell extensions in an Explorer replacement I use
> >> > (Xplorer2) that is 32-bit.
> >> >
> >> > I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt
> >> > tab replacement (Joe), which is 32-bit, works great with 32-bit
> >> > programs but cannot remove focus from 64-bit programs (IE, Windows
> >> > Explorer, etc.). Ironically, very few of the programs I use are
> >> > 64-bit, so I get by with the alt tab replacement.
> >>
> >> Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
> >> extensions. At least now I know I'm not going crazy. :)
> >
> > How could it? You cannot have 32-bit code and 64-bit code running in the
> > same process. At least not with x86_64 (AFAIK).
>
> Correct, this is also my biggest gripe with how x86_64 is implemented.
> Thank you, AMD!
Come on, at least it is not Itanium.
Ciao,
Dscho
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Steven Noonan @ 2009-01-27 23:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geoffrey Lee, git
In-Reply-To: <alpine.DEB.1.00.0901280010530.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 3:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 27 Jan 2009, Steven Noonan wrote:
>
>> On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Tue, 27 Jan 2009, Geoffrey Lee wrote:
>> >
>> >> On Tue, Jan 27, 2009 at 10:24 AM, Stephen Haberman
>> >> <stephen@exigencecorp.com> wrote:
>> >> > It kind of works on my Vista 64-bit system--I do not see the shell
>> >> > extensions in the native Windows Explorer (which is 64 bit), but I
>> >> > do see the shell extensions in an Explorer replacement I use
>> >> > (Xplorer2) that is 32-bit.
>> >> >
>> >> > I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt
>> >> > tab replacement (Joe), which is 32-bit, works great with 32-bit
>> >> > programs but cannot remove focus from 64-bit programs (IE, Windows
>> >> > Explorer, etc.). Ironically, very few of the programs I use are
>> >> > 64-bit, so I get by with the alt tab replacement.
>> >>
>> >> Thanks! It seems that 64-bit explorer.exe will not load 32-bit shell
>> >> extensions. At least now I know I'm not going crazy. :)
>> >
>> > How could it? You cannot have 32-bit code and 64-bit code running in the
>> > same process. At least not with x86_64 (AFAIK).
>>
>> Correct, this is also my biggest gripe with how x86_64 is implemented.
>> Thank you, AMD!
>
> Come on, at least it is not Itanium.
>
True, but x86_64 had so much potential, and Itanium was doomed from the start.
http://www.emulators.com/docs/nx05_vx64.htm -- This guy has it right.
- Steven
^ permalink raw reply
* Re: [PATCH 0/2] Fix two issues found by valgrind
From: Junio C Hamano @ 2009-01-27 23:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901280005180.3586@pacific.mpi-cbg.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> Okay, not tons of issues. But at least it was worth the hassle.
Thanks.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Johannes Schindelin @ 2009-01-27 23:37 UTC (permalink / raw)
To: PJ Hyett; +Cc: git
In-Reply-To: <bab6a2ab0901271510y1e3e6912t82ff16e0f912d4b6@mail.gmail.com>
Hi,
On Tue, 27 Jan 2009, PJ Hyett wrote:
> To expand further, here's the output from the command line when this happened.
>
> ~/Development/github(jetty)$ git push pjhyett jetty
> fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
> error: pack-objects died with strange error
> error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>
> ~/Development/github(jetty)$ git fsck --full
> warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains
> zero-padded file modes
> warning in tree 56fe2a1a3da446606aadf8861feccd592b636a34: contains
> zero-padded file modes
> warning in tree 99e2a89db2aa9846fc2491b3e4ccd8861e8d3283: contains
> zero-padded file modes
> warning in tree a6e532d7451bc4aadab86ade84df69180fab4765: contains
> zero-padded file modes
> dangling blob 43611213c3eff91e5fe071cf2907f69a99b630b2
> dangling commit b28b3ecd85a04ecbd1dcb8aedc6886a465f6ab18
> dangling commit 13a70c8687527936d2c375f0f7aefe71142de3c7
> dangling commit 2aa94c1199cb332f58b70c6ce19d8de3c45c6f3c
> dangling blob 61b910e7a97600691fd279e4db3662e751fb5fb7
> dangling commit c4f19e16208d59666323ae0575435720be9b865d
> dangling commit 19245f5d77aa449eebb4a0521b5ff4f6ce1865ab
> dangling commit 122995fb7c9a7e459b0801e0647eb918bea878bf
> dangling commit 7d51e3926b8720d1c7cad19aeb35d6ab4af755fd
> dangling commit 1162dd21370439416967a34915832125e4975239
> dangling blob 8c630b66927f6022a72e457be308de5c9ad9f4e6
> dangling blob 827d4d8855fe6a3a7856ea35cd641192140f2dcd
> dangling commit c9824506855d6cad9b52df115aa267d70872c2cc
> dangling blob fb9bbfc3aa17c5d1ae4e15c862bd874e3476fcfc
> dangling commit 46a4b39245a58ad867010f272991d6233db6288b
> dangling commit d6bf5f30853fecea745559dc3a718113f3619634
> dangling blob d4d66fc4c3a2cbc94d8ed9cb30a6b56daa86e58f
> dangling commit b4f8d7766e8905e5ac6d6cfeeaf7370a716c24a2
>
> Very odd that the bad object didn't appear in the fsck output.
>
> I was able to fix the error by copying a non-corrupted version of the
> object back into .git/objects and then running a git fetch.
Hmm. The only thing I could think of is that the pack-objects used by
your git-daemon is somehow not at the right version...
Do you have copies of the "corrupt" objects?
Ciao,
Dscho
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-27 23:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: PJ Hyett, git
In-Reply-To: <alpine.DEB.1.00.0901280034310.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 27 Jan 2009, PJ Hyett wrote:
>
> > To expand further, here's the output from the command line when this happened.
> >
> > ~/Development/github(jetty)$ git push pjhyett jetty
> > fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
> > error: pack-objects died with strange error
> > error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>
> Hmm. The only thing I could think of is that the pack-objects used by
> your git-daemon is somehow not at the right version...
No, that's pack-objects on the client.
Its freaking weird. I don't know why a server side upgrade would
cause this on the client side.
FWIW, in 1.6.1 the only mention of those bad object messages
is inside revision.c. I can't see why we'd get one of those
by itself. I would have expected messages from deeper down
too, like from sha1_file.c.
--
Shawn.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-27 23:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, PJ Hyett, git
In-Reply-To: <20090127233939.GD1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Tue, 27 Jan 2009, PJ Hyett wrote:
>>
>> > To expand further, here's the output from the command line when this happened.
>> >
>> > ~/Development/github(jetty)$ git push pjhyett jetty
>> > fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
>> > error: pack-objects died with strange error
>> > error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>>
>> Hmm. The only thing I could think of is that the pack-objects used by
>> your git-daemon is somehow not at the right version...
>
> No, that's pack-objects on the client.
>
> Its freaking weird. I don't know why a server side upgrade would
> cause this on the client side.
>
> FWIW, in 1.6.1 the only mention of those bad object messages
> is inside revision.c. I can't see why we'd get one of those
> by itself. I would have expected messages from deeper down
> too, like from sha1_file.c.
As we do not know what version github used to run (or for that matter what
custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
and did some comparison. The client side pack_object() learned to take
alternates on the server side into account to avoid pushing objects that
the target repository has through its alternates, so it is not totally
unexpected the client side changes its behaviour depending on what the
server does.
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Geoffrey Lee @ 2009-01-27 23:59 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901272350360.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 2:51 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> How could it? You cannot have 32-bit code and 64-bit code running in the
> same process. At least not with x86_64 (AFAIK).
Yeah it seems obvious now, but I had gotten used to 64-bit Windows
being able to run 32-bit apps so seamlessly that I didn't think about
it.
-Geoffrey Lee
^ permalink raw reply
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1233062946-22395-1-git-send-email-giuseppe.bilotta@gmail.com>
On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
> When PATH_INFO is defined, static files such as the defalt CSS or the
default
> shortcut icon are not accessible beyond the summary page (e.g. in
> shortlog or commit view).
>
> Fix this by adding a <base> tag pointing to the script base URL.
By the way, I have thought that it would conflict with use path_info
for 'blob_plain' action to have links work in document... but I forgot
that then we do not use gitweb HTML header...
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> Of course, last time I forgot that the BASE href is supposed to be
> absolute. While Opera apparently has no problem with it being relative,
> other browsers such as Firefox are stricter about it.
Errrr... I think you are talking about _full_ vs. _absolute_, not
_absolute_ vs. _relative_, see below.
>
> gitweb/gitweb.perl | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 931db4f..411b1f6 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2901,6 +2901,14 @@ sub git_header_html {
> <meta name="robots" content="index, nofollow"/>
> <title>$title</title>
> EOF
> +# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
Errr... could you please break this line to not have it overly long?
> + if ($ENV{'PATH_INFO'}) {
> + my $base = $my_url;
Hmmm...
our $my_url = $cgi->url(); # = $cgi->url(-full);
our $my_uri = $cgi->url(-absolute => 1);
> + my $sname = $ENV{'SCRIPT_NAME'};
> + $base =~ s,\Q$sname\E$,,;
> + $base .= "/";
I don't think that is required; neither of $my_url and $my_uri ends
with '/' after stripping path info:
our $path_info = $ENV{"PATH_INFO"};
if ($path_info) {
$my_url =~ s,\Q$path_info\E$,,;
$my_uri =~ s,\Q$path_info\E$,,;
}
and if BASE is a document, then relative URLs are resolved using
dirname of BASE, I guess, as
http://www.w3.org/TR/html401/struct/links.html#edef-BASE
contains in example:
<BASE href="http://www.aviary.com/products/intro.html">
See also RFC1808 (Relative Uniform Resource Locators), section
4. Resolving Relative URLs:
Step 6: The last segment of the base URL's path (anything
following the rightmost slash "/", or the entire path if no
slash is present) is removed and the embedded URL's path is
appended in its place.[...]
Besides, if you strip SCRIPT_NAME, then you are left with document
root; this means that if git-logo.png etc. are in the same directory
as gitweb.cgi, they won't be found. For example for me it doesn't
work correctly (I have git-logo.png along gitweb.cgi, which is in
/cgi-bin/gitweb/... and thanks to symlinks also in /gitweb/).
By the way, according to documentation $cgi->url() should *not*
contain path_info; you have to use $cgi->url(-path_info=>1) for
that... strange.
> + print "<base href=\"$base\"/>\n";
Just in case, to be compatible with both XHML and HTML, we should use
+ print "<base href=\"$base\" />\n";
...if not for the fact that surrounding code doesn't use this way...
> + }
> # print out each stylesheet that exist
> if (defined $stylesheet) {
> #provides backwards capability for those people who define style sheet in a config file
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-28 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7v1vuo1f6d.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>> On Tue, 27 Jan 2009, PJ Hyett wrote:
>>>
>>> > To expand further, here's the output from the command line when this happened.
>>> >
>>> > ~/Development/github(jetty)$ git push pjhyett jetty
>>> > fatal: bad object e13a86261c6e710af8fd4b5fb093b28b8583d820
>>> > error: pack-objects died with strange error
>>> > error: failed to push some refs to 'git@github.com:pjhyett/github.git'
>>>
>>> Hmm. The only thing I could think of is that the pack-objects used by
>>> your git-daemon is somehow not at the right version...
>>
>> No, that's pack-objects on the client.
>>
>> Its freaking weird. I don't know why a server side upgrade would
>> cause this on the client side.
>>
>> FWIW, in 1.6.1 the only mention of those bad object messages
>> is inside revision.c. I can't see why we'd get one of those
>> by itself. I would have expected messages from deeper down
>> too, like from sha1_file.c.
>
> As we do not know what version github used to run (or for that matter what
> custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
> and did some comparison. The client side pack_object() learned to take
> alternates on the server side into account to avoid pushing objects that
> the target repository has through its alternates, so it is not totally
> unexpected the client side changes its behaviour depending on what the
> server does.
Our servers were upgraded from 1.5.5.1 if that helps.
-PJ
^ permalink raw reply
* Re: [PATCHv2] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1232973937-23875-1-git-send-email-giuseppe.bilotta@gmail.com>
On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
> It's sick that $cgi->url() has no way to print the script base url
> without path_info information (or that, if it has, it's very well
> hidden).
Actually:
http://localhost/cgi-bin/gitweb/printenv.cgi/path/info?query=a;string=b;c=c;c=a
url(-absolute=>1) = /cgi-bin/gitweb/printenv.cgi
url(-relative=>1) = /cgi-bin/gitweb/printenv.cgi
url(-full=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi
url(-path_info=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi/path/info
url(-query=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi?query=a;string=b;c=c;c=a
url(-base=>1) = http://localhost
$ENV{'SCRIPT_NAME'} = /cgi-bin/gitweb/printenv.cgi
$ENV{'PATH_INFO'} = /path/info
With CGI.pm version 3.10
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv2] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 0:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901280120.38985.jnareb@gmail.com>
On Wed, Jan 28, 2009 at 1:20 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
>
>> It's sick that $cgi->url() has no way to print the script base url
>> without path_info information (or that, if it has, it's very well
>> hidden).
>
> Actually:
>
> http://localhost/cgi-bin/gitweb/printenv.cgi/path/info?query=a;string=b;c=c;c=a
>
> url(-absolute=>1) = /cgi-bin/gitweb/printenv.cgi
> url(-relative=>1) = /cgi-bin/gitweb/printenv.cgi
> url(-full=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi
> url(-path_info=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi/path/info
> url(-query=>1) = http://localhost/cgi-bin/gitweb/printenv.cgi?query=a;string=b;c=c;c=a
> url(-base=>1) = http://localhost
>
> $ENV{'SCRIPT_NAME'} = /cgi-bin/gitweb/printenv.cgi
> $ENV{'PATH_INFO'} = /path/info
Yeah, but all of these have the script name in it, I was looking for
one without the script name. But more about this in the other reply.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: PJ Hyett @ 2009-01-28 0:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7v1vuo1f6d.fsf@gitster.siamese.dyndns.org>
> As we do not know what version github used to run (or for that matter what
> custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
> and did some comparison. The client side pack_object() learned to take
> alternates on the server side into account to avoid pushing objects that
> the target repository has through its alternates, so it is not totally
> unexpected the client side changes its behaviour depending on what the
> server does.
The only custom code we've written was a patch to git-daemon to map
pjhyett/github.git to a sharded location (eg.
/repositories/1/1e/df/a0/pjhyett/github.git) instead of the default.
The new alternates code in 1.6.1 sounds like that could be the issue.
-PJ
^ permalink raw reply
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 0:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <200901280114.59388.jnareb@gmail.com>
On Wed, Jan 28, 2009 at 1:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
>
>> When PATH_INFO is defined, static files such as the defalt CSS or the
> default
>
>> shortcut icon are not accessible beyond the summary page (e.g. in
>> shortlog or commit view).
>>
>> Fix this by adding a <base> tag pointing to the script base URL.
>
> By the way, I have thought that it would conflict with use path_info
> for 'blob_plain' action to have links work in document... but I forgot
> that then we do not use gitweb HTML header...
>
>>
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> Of course, last time I forgot that the BASE href is supposed to be
>> absolute. While Opera apparently has no problem with it being relative,
>> other browsers such as Firefox are stricter about it.
>
> Errrr... I think you are talking about _full_ vs. _absolute_, not
> _absolute_ vs. _relative_, see below.
No, I actually mean absolute vs relative in the URI sense, not in the
Perl/CGI sense.
http://www.example.com/ is absolute, / is relative
>> gitweb/gitweb.perl | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 931db4f..411b1f6 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -2901,6 +2901,14 @@ sub git_header_html {
>> <meta name="robots" content="index, nofollow"/>
>> <title>$title</title>
>> EOF
>> +# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
>
> Errr... could you please break this line to not have it overly long?
Ah yes, sorry.
>> + if ($ENV{'PATH_INFO'}) {
>> + my $base = $my_url;
>
> Hmmm...
>
> our $my_url = $cgi->url(); # = $cgi->url(-full);
> our $my_uri = $cgi->url(-absolute => 1);
>> + my $sname = $ENV{'SCRIPT_NAME'};
>> + $base =~ s,\Q$sname\E$,,;
>> + $base .= "/";
>
> I don't think that is required; neither of $my_url and $my_uri ends
> with '/' after stripping path info:
>
> our $path_info = $ENV{"PATH_INFO"};
> if ($path_info) {
> $my_url =~ s,\Q$path_info\E$,,;
> $my_uri =~ s,\Q$path_info\E$,,;
> }
>
> and if BASE is a document, then relative URLs are resolved using
> dirname of BASE, I guess, as
> http://www.w3.org/TR/html401/struct/links.html#edef-BASE
> contains in example:
> <BASE href="http://www.aviary.com/products/intro.html">
>
> See also RFC1808 (Relative Uniform Resource Locators), section
> 4. Resolving Relative URLs:
>
> Step 6: The last segment of the base URL's path (anything
> following the rightmost slash "/", or the entire path if no
> slash is present) is removed and the embedded URL's path is
> appended in its place.[...]
Ah, good point, I had missed this part, so we can actually keep the
script name in the url. Good.
> Besides, if you strip SCRIPT_NAME, then you are left with document
> root; this means that if git-logo.png etc. are in the same directory
> as gitweb.cgi, they won't be found. For example for me it doesn't
> work correctly (I have git-logo.png along gitweb.cgi, which is in
> /cgi-bin/gitweb/... and thanks to symlinks also in /gitweb/).
They won't be found only if you have gitweb.cgi as directory index. In
that case you obviously need a rewrite rule at the server level
anyway. The one I use is
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* gitweb.cgi/$0 [L,PT]
tha means 'server static files and turn anything else into pathinfo
for gitweb.cgi'
We probably want to document that. Notice that it's an issue
regardless of this particular patch.
> By the way, according to documentation $cgi->url() should *not*
> contain path_info; you have to use $cgi->url(-path_info=>1) for
> that... strange.
I think there's a bug in CGI.pm when the script is the directory index.
>> + print "<base href=\"$base\"/>\n";
>
> Just in case, to be compatible with both XHML and HTML, we should use
>
> + print "<base href=\"$base\" />\n";
> ...if not for the fact that surrounding code doesn't use this way...
That's the reason why I kept it that way, yes.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 0:52 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When PATH_INFO is defined, static files such as the default CSS or the
shortcut icon are not accessible beyond the summary page (e.g. in
shortlog or commit view).
Fix this by adding a <base> tag pointing to the script's own URL.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..55e3081 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,11 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we
+# set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ print "<base href=\"$my_url\" />\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:55 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <cb7bb73a0901271643g7c3a8c42qff6025187ab3c081@mail.gmail.com>
On Wed, 28 Jan 2009, Giuseppe Bilotta wrote:
> On Wed, Jan 28, 2009 at 1:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
> > > Of course, last time I forgot that the BASE href is supposed to be
> > > absolute. While Opera apparently has no problem with it being relative,
> > > other browsers such as Firefox are stricter about it.
> >
> > Errrr... I think you are talking about _full_ vs. _absolute_, not
> > _absolute_ vs. _relative_, see below.
>
> No, I actually mean absolute vs relative in the URI sense, not in the
> Perl/CGI sense.
>
> http://www.example.com/ is absolute, / is relative
No, "/" is not relative, it is absolute, because it begins with '/'.
See RFC 1808 (Relative Uniform Resource Locators):
2.2. BNF for Relative URLs
[...]
URL = ( absoluteURL | relativeURL ) [ "#" fragment ]
absoluteURL = generic-RL | ( scheme ":" *( uchar | reserved ) )
generic-RL = scheme ":" relativeURL
relativeURL = net_path | abs_path | rel_path
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
(which means that CGI.pm -full is 'net_path', and -absolute is
'abs_path', and -relative is 'rel_path')
[...]
4. Resolving Relative URLs
[...]
Step 4: If the embedded URL path is preceded by a slash "/", the
path is not relative and we skip to Step 7.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-28 0:58 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <200901280155.26399.jnareb@gmail.com>
Jakub Narebski wrote:
> On Wed, 28 Jan 2009, Giuseppe Bilotta wrote:
> > On Wed, Jan 28, 2009 at 1:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > > On Tue, 27 Jan 2009, Giuseppe Bilotta wrote:
>
> > > > Of course, last time I forgot that the BASE href is supposed to be
> > > > absolute. While Opera apparently has no problem with it being relative,
> > > > other browsers such as Firefox are stricter about it.
> > >
> > > Errrr... I think you are talking about _full_ vs. _absolute_, not
> > > _absolute_ vs. _relative_, see below.
> >
> > No, I actually mean absolute vs relative in the URI sense, not in the
> > Perl/CGI sense.
> >
> > http://www.example.com/ is absolute, / is relative
>
> No, "/" is not relative, it is absolute, because it begins with '/'.
Ooops, sorry, I mistook absolute _path_ for absolute _URL_.
Nevertheless path beginning with "/" inherits only net_loc (host).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Linus Torvalds @ 2009-01-28 1:00 UTC (permalink / raw)
To: PJ Hyett; +Cc: git
In-Reply-To: <bab6a2ab0901271510y1e3e6912t82ff16e0f912d4b6@mail.gmail.com>
On Tue, 27 Jan 2009, PJ Hyett wrote:
>
> ~/Development/github(jetty)$ git fsck --full
> warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains zero-padded file modes
> ..
Ouch. This is unrelated to your issue, but I'm wondering what project
contains these invalid trees, and how they were created.
Zero-padded tree entries can cause "object aliases", ie two trees that
have logically the same contents end up with different data (due to
different amounts of padding) and thus different SHA1's. It shouldn't be
serious per se, but it's somethign that really shouldn't happen.
What project does it come from, and how did such a tree get generated?
Linus
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 1:06 UTC (permalink / raw)
To: PJ Hyett; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <bab6a2ab0901271634x7201130bx4a565bd8bea6967b@mail.gmail.com>
PJ Hyett <pjhyett@gmail.com> writes:
>> As we do not know what version github used to run (or for that matter what
>> custom code it adds to 1.6.1), I guessed that the previous one was 1.6.0.6
>> and did some comparison. The client side pack_object() learned to take
>> alternates on the server side into account to avoid pushing objects that
>> the target repository has through its alternates, so it is not totally
>> unexpected the client side changes its behaviour depending on what the
>> server does.
>
> The only custom code we've written was a patch to git-daemon to map
> pjhyett/github.git to a sharded location (eg.
> /repositories/1/1e/df/a0/pjhyett/github.git) instead of the default.
>
> The new alternates code in 1.6.1 sounds like that could be the issue.
It could be.
With the old server, when project A has a forked project A1, and A1
borrows (via alternates) objects from A, pushing into A1 did not look at
refs in A's repository (this all happens on the server end).
With the new server, the server side also advertises the tips of A's
branches as commits that are fully connected, when the client side tries
to push into A1. Older clients ignored this advertisement, so when they
pushed into A1, because their push did not depend on what's in repository
A on the server end, did not get affected if repository A (not A1) is
corrupted. A new client talking to the server would be affected because
it believes what the server says.
Older client ignores this advertisement, so if you are seeing trouble
reports from people who use older clients, then you can dismiss this
conjecture as unrelated. But if you see the issue only from people with
new clients, this could be just exposing a repository corruption of A (not
A1) on the server end that people did not know about before.
^ permalink raw reply
* Re: [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Junio C Hamano @ 2009-01-28 1:07 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <1233103932-6325-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> When PATH_INFO is defined, static files such as the default CSS or the
> shortcut icon are not accessible beyond the summary page (e.g. in
> shortlog or commit view).
>
> Fix this by adding a <base> tag pointing to the script's own URL.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 931db4f..55e3081 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2901,6 +2901,11 @@ sub git_header_html {
> <meta name="robots" content="index, nofollow"/>
> <title>$title</title>
> EOF
> +# the stylesheet, favicon etc urls won't work correctly with path_info unless we
> +# set the appropriate base URL
> + if ($ENV{'PATH_INFO'}) {
> + print "<base href=\"$my_url\" />\n";
> + }
Perhaps this is a stupid question, but is $my_url already safe to include
in the output without any further quoting at this point in the codepath?
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Björn Steinbrink @ 2009-01-28 1:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: PJ Hyett, git
In-Reply-To: <alpine.LFD.2.00.0901271655090.3123@localhost.localdomain>
On 2009.01.27 17:00:54 -0800, Linus Torvalds wrote:
>
>
> On Tue, 27 Jan 2009, PJ Hyett wrote:
> >
> > ~/Development/github(jetty)$ git fsck --full
> > warning in tree 0d640d99b492b0c7db034e92d0460a7f84b22356: contains zero-padded file modes
> > ..
>
> Ouch. This is unrelated to your issue, but I'm wondering what project
> contains these invalid trees, and how they were created.
>
> Zero-padded tree entries can cause "object aliases", ie two trees that
> have logically the same contents end up with different data (due to
> different amounts of padding) and thus different SHA1's. It shouldn't be
> serious per se, but it's somethign that really shouldn't happen.
>
> What project does it come from, and how did such a tree get generated?
I guess that's still from their webinterface that allows to edit file
directly, without having a clone ofthe repo. The initial(?) version used
to create such broken objects. It also got the order of entries in a
tree object wrong IIRC. Back then, Scott and myself tracked that down on
#git, to their ruby(?) stuff that creates the objects. But maybe the
breakage is back?
Björn
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 1:32 UTC (permalink / raw)
To: PJ Hyett; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7vvds0z1c1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> PJ Hyett <pjhyett@gmail.com> writes:
> ...
>> The new alternates code in 1.6.1 sounds like that could be the issue.
>
> It could be.
>
> With the old server, when project A has a forked project A1, and A1
> borrows (via alternates) objects from A, pushing into A1 did not look at
> refs in A's repository (this all happens on the server end).
>
> With the new server, the server side also advertises the tips of A's
> branches as commits that are fully connected, when the client side tries
> to push into A1. Older clients ignored this advertisement, so when they
> pushed into A1, because their push did not depend on what's in repository
> A on the server end, did not get affected if repository A (not A1) is
> corrupted. A new client talking to the server would be affected because
> it believes what the server says.
>
> Older client ignores this advertisement, so if you are seeing trouble
> reports from people who use older clients, then you can dismiss this
> conjecture as unrelated. But if you see the issue only from people with
> new clients, this could be just exposing a repository corruption of A (not
> A1) on the server end that people did not know about before.
The extra "we also have these" advertisement happened as a result of this
discussion:
http://thread.gmane.org/gmane.comp.version-control.git/95072/focus=95256
I think I know what is going on.
Consider this sequence of events.
(0) Alice creates a project and pushes to public.
alice$ cd $HOME/existing-tarball-extract
alice$ git init
alice$ git add .
alice$ git push /pub/alice.git master
(1) Bob forks it.
bob$ git clone --bare --reference /pub/alice.git /pub/bob.git
(2) Bob clones his.
bob$ cd $HOME && git clone /pub/bob.git bob
(3) Alice works more and pushes
alice$ edit foo
alice$ git add foo
alice$ git commit -a -m 'more'
alice$ git push /pub/alice.git master
(4) Bob works more and tries to push to his.
bob$ cd $HOME/bob
bob$ edit bar
bob$ git add bar
bob$ git commit -a -m 'yet more'
bob$ git push /pub/bob.git master
Now, the new server advertises the objects reachable from alice's branch
tips as usable cut-off points for pack-objects bob will run when sending.
And new builtin-send-pack.c has new code that feeds "extra" refs as
^SHA1\n
to the pack-objects process.
The latest commit Alice created and pushed into her repository is one such
commit.
But the problem is that Bob does *NOT* have it. His "push" will run pack
object telling it that objects reachable from Alice's top commit do not
have to be sent, which was the whole point of doing this new "we also have
these" advertisement, but instead of ignoring that unknown commit,
pack-objects would say "Huh? I do not even know that commit" and dies.
This can and should be solved by client updates, as 1.6.1 server can work
with older client just fine.
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-28 1:35 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Jeff King
In-Reply-To: <e2b179460901270210q69fe1e42xb801553e4e9005e9@mail.gmail.com>
On Jan 27, 2009, at 4:10 AM, Mike Ralphson wrote:
> 2009/1/26 Perry Smith <pedzsan@gmail.com>:
>> Thanks guys. I picked up coreutils version 7. I didn't
>> install them but just moved ginstall over to /usr/local/bin.
>>
>> A few other comments: I had to add in the --without-tcltk flag. I
>> don't
>> have tcl installed but the config did not autodetect that it was
>> not present.
>
> Yup, I usually build with NO_TCLTK=YesPlease in my config.mak, which
> you can see from the link Peff posted.
>
> When you said 'out of tree builds' I thought you meant using the AIX
> defaults in the Makefile without running ./configure, but it seems
> not, you meant is a clone of the tree buildable by itself or are only
> release snapshots buildable. Sorry.
Sorry... I thought "out of tree" was a universal term.
Just to be sure we are on the same page. My directory structure has a
top/src/git-1.6.1
and top/build/git.1.6.1. The src/git-1.6.1 is the tar ball. The
build/git-1.6.1 starts out
empty. I cd into it and then do: ../../src/git-1.6.1/configure
<options> After this completes,
you can do "make".
About 90% of the open source configure / autoconf code out there can
do this with.
The other 10% you can not. I like it because when things die, its
easier to grep around
the source tree and I blow away the build directory and start back
over and I know that
I'm starting fresh.
>
>
> ./configure is (deliberately) a second-class citizen in the world of
> git, and may still get you a slightly suboptimal build compared with
> the defaults on platforms such as AIX... e.g. it doesn't test for
> performance-related switches such as INTERNAL_QSORT. If you have run
> configure, there's some file you need to blow away to get back to a
> non-autoconf world... is it config.mak.autogen?
>
> Despite that, your problem with --without-tcltk falling back to wish,
> but not falling back if that isn't installed does look like something
> we should fix, as per Peff's mail.
>
>> I can't tell if make test is happy or not. The output looks like
>> its happy
>> but the exit code is 2.
>>
>> Below is my "configure" script if anyone is interested.
>>
>> #!/usr/bin/env bash
>>
>> export CONFIG_SHELL=/usr/local/bin/bash
>> export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
>> export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
>> export CC=gcc
>> echo CONFIG_SHELL set to ${CONFIG_SHELL}
>>
>> ${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
>>
>> #
>> # Note that to install you need to do:
>> # make INSTALL=ginstall install
>> # to use GNU's install program
>
> I build with SHELL_PATH={path}/bash as well. If I don't, the test
> suite exits after t0000-basic.sh with an unexpected error despite
> passing all the tests.
>
> gmake -C t/ all
> gmake[1]: Entering directory `/usr/local/src/gitbuild/t'
> rm -f -r test-results
> gmake aggregate-results-and-cleanup
> gmake[2]: Entering directory `/usr/local/src/gitbuild/t'
> *** t0000-basic.sh ***
> * passed all remaining 40 test(s)
> FATAL: Unexpected exit with code 0
> gmake[2]: *** [t0000-basic.sh] Error 1
> gmake[2]: Leaving directory `/usr/local/src/gitbuild/t'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/usr/local/src/gitbuild/t'
> gmake: *** [test] Error 2
>
> Is that what you're seeing? There's many more test scripts than that
> 8-)
>
> With GIT_SKIP_TESTS='t3900 t3901 t5100.[12] t8005' (to omit some cases
> not handled by the version of iconv I have access to on all the AIX
> boxes I deploy to) the test suit runs to completion on AIX 5.3 for me.
Yea, part of my larger quest is to start a web site to provide AIX
builds
of open source images as installp images. I have not added iconv to the
mix yet because I fear bad interactions with GNU's and AIX's. In
theory, AIX's
commands should use AIX's library but it would not surprise me if
there are
a few AIX applications that are not built properly.
>
>
> BTW Are you running AIX's make or GNU make?
yes -- GNU's make and gcc 4.3.1
I just tried setting SHELL_PATH (and exporting it) and the make test
gets into
the second batch and then fails two tests. I assume the
GIT_SKIP_TESTS is
done:
make GIT_SKIP_TESTS=....test
I get further. But now test 10 of t0001.sh fails because test_cmp can
not be found.
Is that a GNU tool? (I didn't see it in git or coreutils.)
(I'll go searching for it...)
Thank you,
Perry
^ permalink raw reply
* [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Björn Steinbrink @ 2009-01-28 1:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <7vk58gz04l.fsf@gitster.siamese.dyndns.org>
Since 40c155ff14c, receive-pack on the remote also sends refs from its
alternates. Unfortunately, we don't filter commits that don't exist in the
local repository from that list. This made us pass those unknown commits
to pack-objects, causing it to fail with a "bad object" error.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
builtin-send-pack.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index a9fdbf9..10d7016 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -52,11 +52,15 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
* parameters by writing to the pipe.
*/
for (i = 0; i < extra->nr; i++) {
- memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42, "send-pack: send refs"))
- break;
+ if (!is_null_sha1(&extra->array[i][0]) &&
+ has_sha1_file(&extra->array[i][0])) {
+ memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
+ buf[0] = '^';
+ buf[41] = '\n';
+ if (!write_or_whine(po.in, buf, 42,
+ "send-pack: send refs"))
+ break;
+ }
}
while (refs) {
--
1.6.1.284.g5dc13.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox