* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Junio C Hamano @ 2006-12-28 2:41 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228022855.GF16612@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> The section is really for those who are upgrading from ancient
> versions, but the title of the section implies (at least to me)
> that these changes aren't something important.
True. How about "Something important you should already know
but just in case" ;-)?
^ permalink raw reply
* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Shawn Pearce @ 2006-12-28 2:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz583goc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >>
> >> -- >8 --
> >>
> >> Major changes that are not news
> >> -------------------------------
> >
> > If these major changes aren't news, what are they?
>
> Exactly as described in the part you did not quote:
>
> There were a handful big changes that happened before this major
> release.
>
> This section is for people who are upgrading from ancient
> versions.
>
> In other words, they are only to help people who were not paying
> enough attention to earlier releases.
OK, yet again I don't quite quote enough. Or read enough. ;-)
But maybe you can title the section
Major changes since 1.2.x
? Or whatever version preceeded when we started to add that stuff?
The section is really for those who are upgrading from ancient
versions, but the title of the section implies (at least to me)
that these changes aren't something important.
Just my (nearly worthless against the Euro) two US pennies...
--
Shawn.
^ permalink raw reply
* Re: Why git-merge-resolve in git-am?
From: Junio C Hamano @ 2006-12-28 2:28 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228022038.GE16612@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Good reasons, but all are strictly historical. So there's actually
> no technical reason we can't use merge-recursive here in git-am.
A very early version of recursive was unusable (it did not pay
attention to the merge base the caller gave it and tried to
always compute it by itself), but that was fixed sometime later.
I do not recall offhand C version still has that fix (I think it
does but you should double check); as long ias it honors the
merge base the caller computed, it should be Ok to replace
resolve with recursive. Go wild.
^ permalink raw reply
* Re: Why git-merge-resolve in git-am?
From: Shawn Pearce @ 2006-12-28 2:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6uk3h2p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Why does git-am use git-merge-resolve while git-rebase -m uses
> > git-merge-recursive?
>
> The use of merge-resolve by am predates merge-resolve became
> usable by at least six weeks, and longer before merge-resolve
> became really stable for about an extra month after.
>
> Even after it stabilized merge-recursive was way slower than
> merge-resove until it was rewritten in C for another nine
> months.
Good reasons, but all are strictly historical. So there's actually
no technical reason we can't use merge-recursive here in git-am.
Basically I'm trying to improve the merge conflict hunks in
`git-am -3`. merge-recursive now recognizes GITHEAD_* but
merge-one-file doesn't (and can't). Switching to merge-recursive
and setting GITHEAD_* would get that case fixed in git-rebase
without -m.
--
Shawn.
^ permalink raw reply
* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Junio C Hamano @ 2006-12-28 2:20 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228020305.GD16612@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>>
>> -- >8 --
>>
>> Major changes that are not news
>> -------------------------------
>
> If these major changes aren't news, what are they?
Exactly as described in the part you did not quote:
There were a handful big changes that happened before this major
release.
This section is for people who are upgrading from ancient
versions.
In other words, they are only to help people who were not paying
enough attention to earlier releases.
^ permalink raw reply
* Re: Why git-merge-resolve in git-am?
From: Junio C Hamano @ 2006-12-28 2:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228014525.GC16612@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Why does git-am use git-merge-resolve while git-rebase -m uses
> git-merge-recursive?
The use of merge-resolve by am predates merge-resolve became
usable by at least six weeks, and longer before merge-resolve
became really stable for about an extra month after.
Even after it stabilized merge-recursive was way slower than
merge-resove until it was rewritten in C for another nine
months.
^ permalink raw reply
* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Shawn Pearce @ 2006-12-28 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvejw3iaq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> -- >8 --
>
> Major changes that are not news
> -------------------------------
If these major changes aren't news, what are they? Chopped liver?
I'm highly confused by the section header.
--
Shawn.
^ permalink raw reply
* Why git-merge-resolve in git-am?
From: Shawn Pearce @ 2006-12-28 1:45 UTC (permalink / raw)
To: git
Why does git-am use git-merge-resolve while git-rebase -m uses
git-merge-recursive?
Can we just change git-am to use git-merge-recursive instead?
For one thing its faster, for another it supports the GITHEAD_*
feature for naming the hunks in a conflict.
--
Shawn.
^ permalink raw reply
* An early draft of v1.5.0 release notes (2nd ed)
From: Junio C Hamano @ 2006-12-28 1:45 UTC (permalink / raw)
To: git
In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net>
This incorporates comments from the list (thanks). Maybe I
should park this in 'todo' branch so that people can review the
updates more easily.
-- >8 --
Major changes that are not news
-------------------------------
There were a handful big changes that happened before this major
release.
This section is for people who are upgrading from ancient
versions. Some of them are one-way street upgrades -- once you
use the feature your repository cannot be used with ancient git.
- There is a new configuration variable core.legacyheaders that
changes the format of loose objects to more efficient to pack
and send out of the repository over git native protocol.
However, this format cannot be read by git older than v1.4.2;
people fetching from your repository using older clients over
dumb transports (e.g. http) will also be affected. This is
not enabled by default.
- Another configuration repack.usedeltabaseoffset further
allows packfile to be created in more space efficient format,
which cannot be read by git older than v1.4.3. This is not
enabled by default.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native client can fetch
from a repository that packed its tags, but older dumb
transports cannot. This is done by an explicit user action,
either by use of "git pack-refs --prune" command or by use of
"git gc" command.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
this may surprise old timer users.
- 'git archive' superseded 'git tar' in v1.4.3;
- 'git cvsserver' was new invention in v1.3.0;
- 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
seriously enhanced during v1.4.0 timeperiod.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- reflog is an v1.4.0 invention.
Updates in v1.5.0 since v1.4.4 series
-------------------------------------
* Index manipulation
- git-add is to add contents to the index (aka "staging area"
for the next commit), whether the file the contents happen to
be is an existing one or a newly created one.
- git-add without any argument does not add everything
anymore. Use 'git-add .' instead. Also you can add
otherwise ignored files with an -f option.
- git-add tries to be more friendly to users by offering an
interactive mode.
- git-commit <path> used to refuse to commit if <path> was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset <tree> <paths>... can be used to revert index
entries for selected paths.
- git-update-index is much less visible.
* Repository layout and objects transfer
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
created clones (the latter is still supported).
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree;
i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
used to track branches from the origin. New branches that
appear on the origin side after a clone is made are also
tracked automatically.
- git-branch and git-show-branch know remote tracking branches.
- git-push can now be used to delete a remote branch or a tag.
This requires the updated git on the remote side.
- git-push more agressively keeps the transferred objects
packed. Earlier we recommended to monitor amount of loose
objects and repack regularly, but you should repack when you
accumulated too many small packs this way as well. Updated
git-count-objects helps you with this.
* Reflog
- Reflog records the history of where the tip of each branch
was at each moment. This facility is enabled by default for
repositories with working trees, and can be accessed with the
"branch@{time}" and "branch@{Nth}" notation.
- "git show-branch" learned showing the reflog data with the
new --reflog option.
- The commits referred to by reflog entries are now protected
against pruning. The new command "git reflog expire" can be
used to truncate older reflog entries and entries that refer
to commits that have been pruned away previously with older
versions of git.
Existing repositories that have been using reflog may get
complaints from fsck-objects; please run "git reflog expire
--all" first to remove reflog entries that refer to commits
that are no longer in the repository before attempting to
repack it.
- git-branch knows how to rename branches and moves existing
reflog data from the old branch to the new one.
* Packed refs
- Repositories with hundreds of tags have been paying large
overhead, both in storage and in runtime. A new command,
git-pack-refs, can be used to "pack" them in more efficient
representation.
- Clones and fetches over dumb transports are now aware of
packed refs and can download from repositories that use
them.
* Configuration
- configuration related to colorize setting are consolidated
under color.* namespace (older diff.color.*, status.color.*
are still supported).
* Less external dependency
- We no longer require the "merge" program from the RCS suite.
All 3-way file-level merges are now done internally.
- The original implementation of git-merge-recursive which was
in Python has been removed; we have C implementation of it
now.
- git-shortlog is no longer a Perl script. It no longer
requires output piped from git-log; it can accept revision
parameters directly on the command line.
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects. This will continue to be the
case. However, a non UTF-8 commit encoding _must_ be
explicitly set with i18n.commitencoding in the repository
where a commit is made; otherwise git-commit-tree will
complain if the log message does not look like a valid UTF-8
string.
- The value of i18n.commitencoding in the originating
repository is recorded in the commit object on the "encoding"
header, if it is not UTF-8. git-log and friends notice this,
and reencodes the message to the log output encoding when
displaying, if they are different. The log output encoding
is determined by "git log --encoding=<encoding>",
i18n.logoutputencoding configuration, or i18n.commitencoding
configuration, in the decreasing order of preference, and
defaults to UTF-8.
* User support
- Quite a lot of documentation updates.
- Bash completion scripts have been updated heavily.
- Better error messages for often used Porcelainish commands.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Nicolas Pitre @ 2006-12-28 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst H. von Brand, git
In-Reply-To: <7vbqlo4zg8.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Dec 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> > ...
> >> And what happens to the people who can't/won't display UTF-8? This is a
> >> both a project wide configuration (how does stuff get saved) + a user/local
> >> configuration (how to display stuff).
> > ...
> > Maybe i18n.displayencoding set to latin1 is what you are after?
> > I think it might make sense...
>
> I've done this and will be pushing the result out in 'next'
> shortly, with a new test. I find the result mostly sensible.
Shouldn't the LANG environment variable be used for this purpose
instead?
Nicolas
^ permalink raw reply
* [PATCH 2/2] Use branch names in 'git-rebase -m' conflict hunks.
From: Shawn O. Pearce @ 2006-12-28 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <35ce346ffc16a7c294a8a1e69e604dfec81d288f.1167270210.git.spearce@spearce.org>
If a three-way merge in git-rebase generates a conflict then we
should take advantage of git-merge-recursive's ability to include
the branch name of each side of the conflict hunk by setting the
GITHEAD_* environment variables.
In the case of rebase there aren't really two clear branches; we
have the branch we are rebasing onto, and we have the branch we are
currently rebasing. Since most conflicts will be arising between
the user's current branch and the branch they are rebasing onto
we assume the stuff that isn't in the current commit is the "onto"
branch and the stuff in the current commit is the "current" branch.
This assumption may however come up wrong if the user resolves one
conflict in such a way that it conflicts again on a future commit
also being rebased. In this case the user's prior resolution will
appear to be in the "onto" part of the hunk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-rebase.sh | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index b99f1e3..1f00cb0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -80,10 +80,18 @@ continue_merge () {
call_merge () {
cmt="$(cat $dotest/cmt.$1)"
echo "$cmt" > "$dotest/current"
- git-merge-$strategy "$cmt^" -- HEAD "$cmt"
+ hd=$(git-rev-parse --verify HEAD)
+ cmt_name=$(git-symbolic-ref HEAD)
+ msgnum=$(cat $dotest/msgnum)
+ end=$(cat $dotest/end)
+ eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
+ eval GITHEAD_$hd='"$(cat $dotest/onto_name)"'
+ export GITHEAD_$cmt GITHEAD_$hd
+ git-merge-$strategy "$cmt^" -- "$hd" "$cmt"
rv=$?
case "$rv" in
0)
+ unset GITHEAD_$cmt GITHEAD_$hd
return
;;
1)
@@ -316,6 +324,7 @@ fi
mkdir -p "$dotest"
echo "$onto" > "$dotest/onto"
+echo "$onto_name" > "$dotest/onto_name"
prev_head=`git-rev-parse HEAD^0`
echo "$prev_head" > "$dotest/prev_head"
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 1/2] Teach git-reset to let others override its reflog entry.
From: Shawn O. Pearce @ 2006-12-28 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When git-rebase invokes `git reset --hard` to rewind the user's
branch prior to starting to reapply each commit this is showing
up in the reflog as a simple `git reset --hard <cmt>` but its not
clear to the end-user inspecting the log why there is a reset.
The new --reflog-action for git-reset behaves like the same option
to git-merge; it can be used by the caller to override the message
entry in the reflog and is intended to be used only when git-reset
is acting as plumbing, not porcelain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-reset.txt | 5 +++++
git-rebase.sh | 4 ++--
git-reset.sh | 8 ++++++--
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 4f42478..7eaa186 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -45,6 +45,11 @@ OPTIONS
switched to. Any changes to tracked files in the working tree
since <commit> are lost.
+--reflog-action=<action>::
+ This is used internally when `git-rebase` calls this command
+ to reset the current branch prior to merging the rebased
+ commits onto it.
+
<commit>::
Commit to make the current HEAD.
diff --git a/git-rebase.sh b/git-rebase.sh
index ece3142..b99f1e3 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -174,7 +174,7 @@ do
else
die "No rebase in progress?"
fi
- git reset --hard ORIG_HEAD
+ git reset --reflog-action="rebase: abort" --hard ORIG_HEAD
exit
;;
--onto)
@@ -293,7 +293,7 @@ fi
# Rewind the head to "$onto"; this saves our current head in ORIG_HEAD.
echo "First, rewinding head to replay your work on top of it..."
-git-reset --hard "$onto"
+git-reset --hard --reflog-action="rebase: rewind to $onto_name" "$onto"
# If the $onto is a proper descendant of the tip of the branch, then
# we just fast forwarded.
diff --git a/git-reset.sh b/git-reset.sh
index 2379db0..7ef6789 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -6,7 +6,7 @@ USAGE='[--mixed | --soft | --hard] [<commit-ish>] [ [--] <paths>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
-update= reset_type=--mixed
+rloga= update= reset_type=--mixed
unset rev
while case $# in 0) break ;; esac
@@ -15,6 +15,9 @@ do
--mixed | --soft | --hard)
reset_type="$1"
;;
+ --reflog-action=*)
+ rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+ ;;
--)
break
;;
@@ -81,7 +84,8 @@ then
else
rm -f "$GIT_DIR/ORIG_HEAD"
fi
-git-update-ref -m "reset $reset_type $*" HEAD "$rev"
+test "$rloga" = '' && rloga="reset $reset_type $*"
+git-update-ref -m "$rloga" HEAD "$rev"
update_ref_status=$?
case "$reset_type" in
--
1.4.4.3.gd2e4
^ permalink raw reply related
* Re: http git and curl 7.16.0
From: Shawn Pearce @ 2006-12-28 1:42 UTC (permalink / raw)
To: Horst H. von Brand
Cc: Junio C Hamano, Nick Hengeveld, George Sherwood, skimo, git
In-Reply-To: <200612280135.kBS1ZL5v004756@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> I tried to chop down a tig repo a few commits from the top for checking out
> the crash I'm seeing (only when pulling from a remote repo by HTTP, and it
> is not up to date here) by doing:
>
> cp -r tig tig.tst
> cd tig.tst
> git reset --hard HEAD~3
> git prune
>
> But now git-pull /doesn't/ fetch anything, so I see no crash. What am I
> doing wrong here?
Another ref points at the same commit as what ORIG_HEAD points at,
so there wasn't anything to fetch as you already had that commit.
Its probably a tag, a ref under refs/remotes, or another branch...
--
Shawn.
^ permalink raw reply
* Re: http git and curl 7.16.0
From: Horst H. von Brand @ 2006-12-28 1:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Horst H. von Brand, Nick Hengeveld, George Sherwood, skimo, git
In-Reply-To: <7vlkkt5d49.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> > Sven Verdoolaege <skimo@kotnet.org> wrote:
> >> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:
> >> > I seem to be having a problem doing an http checkout with git built
> >> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a
> >> > clone, I get:
> > ...
> >> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
> >> > error: Unable to start request error: Could not interpret heads/master
> >> > as something to pull
> >> >
> >> > If I rebuild git against curl 7.15.5 then I get:
> >> [..]
> >> > and the checkout finishes.
> >> >
> >> > Has any one else seen this?
> >
> >> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.
> >> It worked fine with curl 7.15.0.
> >
> > It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while
> > it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.
> >
> > Furthermore, with new curl pulling from HTTP repos when there are updates
> > gives double free errors and a crash.
>
> Hmmm. Could somebody please run http-fetch under gdb and see
> where it breaks? The exact command line you need to use would
> be obtainable by running "sh -x git-clone" once.
It crashes the kernel for me here :-(
I tried to chop down a tig repo a few commits from the top for checking out
the crash I'm seeing (only when pulling from a remote repo by HTTP, and it
is not up to date here) by doing:
cp -r tig tig.tst
cd tig.tst
git reset --hard HEAD~3
git prune
But now git-pull /doesn't/ fetch anything, so I see no crash. What am I
doing wrong here?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: Separate HTTP header output
From: Shawn Pearce @ 2006-12-28 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v7iwc4xu9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> which means it does not omit generating the body anyway no
> matter what "sub http_header" did...
>
> Or is there some Perl magic that makes a return from sub named
> *_header magically terminate the execution of the caller?
No magic. Bad patch. Your assessment of the patch is correct;
it is not avoiding the body generation for a HEAD request.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: Separate HTTP header output
From: Junio C Hamano @ 2006-12-28 1:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612272357.56532.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Always return just after HTTP header is sent when asking only about
> headers (HTTP request method 'HEAD'); first appeared in git_rss.
>
> While at it uniquify style of http_header(...) calls, formerly
> "print $cgi->header(...)", and remove default HTTP status, '200 OK'.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This one is fairly generic, and if considered worthy, I think
> can be accepted without much ado.
Maybe I am missing something fundamental, but I cannot see how
this affects anything whatsoever...
> +## functions printing HTTP or HTML: header, footer, error page
> +
> +sub http_header {
> + my @header = @_;
> +
> + print $cgi->header(@header);
> +
> + # Optimization: skip generating the body if client asks only
> + # for HTTP header (e.g. cache validation).
> + return if ($cgi->request_method() eq 'HEAD');
> +}
Ok, so this explicitly written "return" returns when it is a
HEAD request not GET. Otherwise the control falls out of the
end of the function. Either way you return undef.
Then the caller does...
> @@ -1709,8 +1719,11 @@ sub git_header_html {
> } else {
> $content_type = 'text/html';
> }
> - print $cgi->header(-type=>$content_type, -charset => 'utf-8',
> - -status=> $status, -expires => $expires);
> + http_header(
> + -type => $content_type,
> + -charset => 'utf-8',
> + -status => $status,
> + -expires => $expires);
> print <<EOF;
> <?xml version="1.0" encoding="utf-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
which means it does not omit generating the body anyway no
matter what "sub http_header" did...
Or is there some Perl magic that makes a return from sub named
*_header magically terminate the execution of the caller?
Puzzled...
^ permalink raw reply
* Re: [RFC/PATCH 6/6] gitweb: Make possible to run under mod_perl without ParseHeaders
From: Jakub Narebski @ 2006-12-28 1:12 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: git
In-Reply-To: <20061228010311.GD6558@localhost>
Robert Fitzsimons wrote:
>> @@ -1854,7 +1976,8 @@ EOF
>> $cgi->hidden(-name => "a") . "\n" .
>> $cgi->hidden(-name => "h") . "\n" .
>> $cgi->popup_menu(-name => 'st', -default => 'commit',
>> - -values => ['commit', 'author', 'committer', 'pickaxe']) .
>> + -values => ['commit', 'author', 'committer',
>> + gitweb_check_feature('pickaxe') ? 'pickaxe' : ()]) .
>> $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
>> " search:\n",
>> $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
>
> This should be a separate patch.
I'm sorry, somehow I missed this.
Besides, it would be better to assign return value to some
variable, to avoid calling gitweb_check_feature again...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH 6/6] gitweb: Make possible to run under mod_perl without ParseHeaders
From: Robert Fitzsimons @ 2006-12-28 1:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612280106.24331.jnareb@gmail.com>
> @@ -1854,7 +1976,8 @@ EOF
> $cgi->hidden(-name => "a") . "\n" .
> $cgi->hidden(-name => "h") . "\n" .
> $cgi->popup_menu(-name => 'st', -default => 'commit',
> - -values => ['commit', 'author', 'committer', 'pickaxe']) .
> + -values => ['commit', 'author', 'committer',
> + gitweb_check_feature('pickaxe') ? 'pickaxe' : ()]) .
> $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
> " search:\n",
> $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
This should be a separate patch.
Robert
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-28 0:49 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <7vtzzh5dnv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> ...
>> And what happens to the people who can't/won't display UTF-8? This is a
>> both a project wide configuration (how does stuff get saved) + a user/local
>> configuration (how to display stuff).
> ...
> Maybe i18n.displayencoding set to latin1 is what you are after?
> I think it might make sense...
I've done this and will be pushing the result out in 'next'
shortly, with a new test. I find the result mostly sensible.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Jakub Narebski @ 2006-12-28 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <200612271312.15877.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
Jakub Narebski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Junio C Hamano wrote:
>>>>
>>>> - The commits referred to by reflog entries are now protected
>>>> against pruning. The new command "git reflog expire" can be
>>>> used to truncate older reflog entries and entries that refer
>>>> to commits that have been pruned away previously.
>>>>
>>>> Existing repositories that have been using reflog may get
>>>> complaints from fsck-objects; please run "git reflog expire
>>>> --all" first to remove reflog entries that refer to commits
>>>> that are no longer in the repository before attempting to
>>>> repack it.
[...]
> I'd rather use "git reflog expire --pruned" to remove reflog entries
> which refer to commits which are no longer in the repository; I don't
> know, perhaps "git reflog expire --all" does that: but there is no
> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
> but 1.4.4.3). So most probably it is just the case of adding an alias
> to reflog expire option.
Thanks for adding Documentation/git-reflog.txt. Nevertheless it didn't
add the information that "git reflog expire" removes reflog entries that
refer to commits that are no longer in the repository (see attached patch).
I'm not sure if such technical information should be in git-reflog(1),
but does only second, current sha1 in reflog line matters for prune?
And does expiring rewrite reflog (previous sha1, making always previous
sha1 (first sha1 in reflog line) always to refer some commit in earlier
reflog line, or before first reflog line), or only delete lines?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
[-- Attachment #2: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries --]
[-- Type: text/plain, Size: 1327 bytes --]
>From c39e864dec5fc5542e9dd14235a48fa2bb77ed6a Mon Sep 17 00:00:00 2001
From: Jakub Narebski <jnareb@gmail.com>
Date: Thu, 28 Dec 2006 01:30:05 +0100
Subject: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries
Add information to Documentation/git-reflog.txt that "expire" subcommand
also removes entries which refer to commits that are no longer in
repository.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-reflog.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 55a24d3..04ea51a 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -22,11 +22,12 @@ updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
`expire-unreachable` time and are not reachable from the current
-tip, are removed from the reflog. This is typically not used
+tip, are removed from the reflog. Entries which refer to
+commits that are no longer in the repository are pruned
+regardless of their age. This command is typically not used
directly by the end users -- instead, see gitlink:git-gc[1].
-
OPTIONS
-------
--
1.4.4.3
^ permalink raw reply related
* [PATCH/RFC 5/6] gitweb: Make possible to run under mod_perl without SetupEnv
From: Jakub Narebski @ 2006-12-27 23:49 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Make possible to run gitweb under mod_perl without need to set up CGI
environmental variables (i.e. "PerlOptions -SetupEnv" in mod_perl 2.0,
"PerlSetupEnv Off" in mod_perl 1.0).
Actually ModPerl::Registry / Apache::Registry populates %ENV hash,
without need to actually set environmental variables.
Pass the request variable $r to CGI constructor if CGI.pm module is
new enough (at least CGI version 2.93, and at least 3.11 for mod_perl
2.0).
Replace $ENV{'PATH_INFO'} by $r->path_info() if we use mod_perl.
Replace $ENV{'SERVER_NAME'} by $r->server()->server_hostname() if we
use mod_perl.
Uniquify using of %ENV to $ENV{'NAME'}, while at it.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch appears to be unnecessary, at least for now, because
mod_perl Registry populates %ENV hash (and does not need to set
envirionmental variables). Still, it prepares the way for future
running gitweb as mod_perl handler, and not under Registry.
Perhaps the cleanup part of this patch should be put into separate
patch...
gitweb/gitweb.perl | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9983e9e..2900ae6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -32,11 +32,16 @@ BEGIN {
# use appropriate mod_perl modules (conditional use)
if (MP_GEN == 2) {
require Apache2::RequestRec;
+ require Apache2::ServerRec;
+ require Apache2::Response;
require Apache2::Const;
+ Apache2::RequestRec->import();
+ Apache2::ServerRec->import();
Apache2::Const->import(-compile => qw(:common :http));
} elsif (MP_GEN == 1) {
require Apache;
require Apache::Constants;
+ import Apache;
Apache::Constants->import(qw(:common :http));
}
@@ -48,7 +53,15 @@ BEGIN {
my $r;
$r = shift @_ if MP_GEN;
-our $cgi = new CGI;
+our $cgi;
+if ((MP_GEN == 1 && $CGI::VERSION >= 2.93) ||
+ (MP_GEN == 2 && $CGI::VERSION >= 3.11)) {
+ # CGI.pm is new enough
+ $cgi = new CGI($r);
+} else {
+ $cgi = new CGI;
+}
+
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
@@ -70,7 +83,8 @@ our $home_link_str = "++GITWEB_HOME_LINK_STR++";
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
our $site_name = "++GITWEB_SITENAME++"
- || ($ENV{'SERVER_NAME'} || "Untitled") . " Git";
+ || (($r ? $r->server()->server_hostname() : $ENV{'SERVER_NAME'})
+ || "Untitled") . " Git";
# filename of html text to include at top of each page
our $site_header = "++GITWEB_SITE_HEADER++";
@@ -403,7 +417,7 @@ if (defined $searchtype) {
# now read PATH_INFO and use it as alternative to parameters
sub evaluate_path_info {
return if defined $project;
- my $path_info = $ENV{"PATH_INFO"};
+ my $path_info = $r ? $r->path_info() : $ENV{'PATH_INFO'};
return if !$path_info;
$path_info =~ s,^/+,,;
return if !$path_info;
--
1.4.4.3
^ permalink raw reply related
* [RFC/PATCH 6/6] gitweb: Make possible to run under mod_perl without ParseHeaders
From: Jakub Narebski @ 2006-12-28 0:06 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Add mod_perl version of http_header, setting headers directly (both
for mod_perl 2.0 and 1.0); bits of code taken from CGI and CGI::Util
modules. While at it add cache validation via $r->meets_conditions()
in mod_perl code.
Separate HTTP redirection into http_redirect subroutine and add
mod_perl version, setting headers directly.
All this is meant to allow gitweb to run under ModPerl::Registry (for
mod_perl 2.0) / Apache::Registry (for mod_perl 1.0) without need for
Apache to parse headers (without ParseHeaders), which should speed up
gitweb a bit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch tries to add HTTP headers directly, allowing Apache to not
need to parse headers (without ParseHeaders), which should speed
up gitweb a bit. It also makes use of mod_perl meets_expectation
method to respond to If-Modified-Since: and If-None-Match: requests
for cache validation. Current state is a bit of mess as it is now.
Comments (and patches) appreciated.
It is not benchmarked because ApacheBench went crazy, showing *negative*
waiting time. Probably I did something wrong...
Not checked for warnings, only slightly tested: definitely an RFC.
gitweb/gitweb.perl | 137 +++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 130 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2900ae6..12f1cb2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -35,13 +35,17 @@ BEGIN {
require Apache2::ServerRec;
require Apache2::Response;
require Apache2::Const;
+ require APR::Date;
Apache2::RequestRec->import();
Apache2::ServerRec->import();
Apache2::Const->import(-compile => qw(:common :http));
+ APR::Date->import();
} elsif (MP_GEN == 1) {
require Apache;
require Apache::Constants;
+ require Apache::File;
import Apache;
+ import Apache::File;
Apache::Constants->import(qw(:common :http));
}
@@ -1727,11 +1731,129 @@ sub blob_mimetype {
sub http_header {
my @header = @_;
- print $cgi->header(@header);
+ if (MP_GEN) {
+ my %header = @header;
+ my $cache_validator;
+
+ ## special cases ##
+ # -status
+ $r->status_line($header{-status})
+ if $header{-status};
+ delete $header{-status} if exists $header{-status};
+ # -type and -charset
+ if ($header{-type} || $header{-charset}) {
+ my $type = $header{-type} || 'text/html';
+ $type .= "; charset=$header{-charset}"
+ if $type =~ m!^text/! and $type !~ /\bcharset\b/ and $header{-charset};
+
+ $r->content_type($type);
+ }
+ delete $header{-type} if exists $header{-type};
+ delete $header{-charset} if exists $header{-charset};
+ # -content_encoding
+ $r->content_encoding($header{-content_encoding})
+ if $header{-content_encoding};
+ delete $header{-content_encoding} if exists $header{-content_encoding};
+ # -expires
+ if ($header{-expires}) {
+ my $expires = CGI::Util::expires($header{-expires}, 'http');
+ if (MP_GEN == 1) {
+ $r->header_out('Expires', $expires);
+ } else {
+ $r->headers_out->add('Expires', $expires);
+ }
+ }
+ delete $header{-expires} if exists $header{-expires};
+ # -last_modified
+ if ($header{-last_modified}) {
+ $cache_validator ||= 1;
+ if (MP_GEN == 1) {
+ $r->header_out('Last-Modified', $header{-last_modified});
+ } else {
+ $r->set_last_modified(APR::Date::parse_http($header{-last_modified}));
+ }
+ }
+ delete $header{-last_modified} if exists $header{-last_modified};
+
+ ## other headers ##
+ while (my ($key, $value) = each %header) {
+ $key =~ s/^-//; # -content_disposition -> content_disposition
+ $key =~ s/_/-/; # content_disposition -> content-disposition
+ $key =~ s/(\w)(\w*)/\u$1$2/g;
+ # content-disposition -> Content-Disposition
+
+ if (MP_GEN == 1) {
+ $r->header_out($key, $value);
+ } else {
+ $r->headers_out->add($key, $value);
+ }
+ }
+ $cache_validator ||= (exists $header{-ETag} || exists $header{-etag});
+
+ ## send headers / flush ##
+ if (MP_GEN == 1) {
+ $r->send_http_headers();
+
+ ## validate cache ##
+ if ($cache_validator &&
+ (my $rc = $r->meets_conditions()) != Apache::Constant::OK) {
+ return $rc;
+ }
+ } else {
+ $r->rflush();
+
+ ## validate cache ##
+ if ($cache_validator &&
+ (my $rc = $r->meets_conditions()) != Apache2::Const::OK) {
+ return $rc;
+ }
+ }
+ } else {
+ print $cgi->header(@header);
+ }
# Optimization: skip generating the body if client asks only
# for HTTP header (e.g. cache validation).
- return if ($cgi->request_method() eq 'HEAD');
+ if (MP_GEN == 2) {
+ return Apache2::Const::OK if $r->header_only();
+ } elsif (MP_GEN == 1) {
+ return Apache::Constant::OK if $r->header_only();
+ } else {
+ return if ($cgi->request_method() eq 'HEAD');
+ }
+}
+
+sub http_redirect {
+ my @params = @_;
+ my %params;
+ if (@params % 2 == 0) {
+ %params = @params;
+ }
+ my $uri = $params{-uri} || $params{-url} || $params{-location}
+ || $params[0] || $cgi->self_url;
+ my $status = $params{-status};
+
+ if (MP_GEN == 1) {
+ $r->header_out('Location', $uri);
+ if (defined $status) {
+ $r->status_line($status);
+ } else {
+ $r->status(Apache::Constant::REDIRECT);
+ }
+
+ $r->send_http_headers();
+ } elsif (MP_GEN == 2) {
+ $r->headers_out->add('Location', $uri);
+ if (defined $status) {
+ $r->status_line($status);
+ } else {
+ $r->status(Apache2::Const::REDIRECT);
+ }
+
+ $r->rflush();
+ } else {
+ print $cgi->redirect(@params);
+ }
}
sub git_header_html {
@@ -1854,7 +1976,8 @@ EOF
$cgi->hidden(-name => "a") . "\n" .
$cgi->hidden(-name => "h") . "\n" .
$cgi->popup_menu(-name => 'st', -default => 'commit',
- -values => ['commit', 'author', 'committer', 'pickaxe']) .
+ -values => ['commit', 'author', 'committer',
+ gitweb_check_feature('pickaxe') ? 'pickaxe' : ()]) .
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
@@ -3901,10 +4024,10 @@ sub git_object {
die_error('404 Not Found', "Not enough information to find object");
}
- print $cgi->redirect(-uri => href(action=>$type, -full=>1,
- hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name),
- -status => '302 Found');
+ http_redirect(-uri => href(action=>$type, -full=>1,
+ hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name),
+ -status => '302 Found');
}
sub git_blobdiff {
--
1.4.4.3
^ permalink raw reply related
* [PATCH/RFC 4/6] gitweb: Prepare for mod_perl specific support
From: Jakub Narebski @ 2006-12-27 23:04 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Prepare gitweb for mod_perl specific support in CGI compatibility mode
(Apache::Registry/ModPerl::Registry or Apache::PerlRun/ModPerl::PerlRun)
by storing request (an argument to a handler) in $r variable, for later
use.
The idea is to have gitweb run as CGI script, under mod_perl 1.0 and under
mod_perl 2.0 without modifications, while being able to make use of mod_perl
capabilities.
Define MP_GEN constant and set it to 0 if mod_perl is not available,
to 1 if running under mod_perl 1.0, and 2 for mod_perl 2.0. It is later used
in BEGIN block to load appropriate mod_perl modules; for now the one
in which request is defined, and the one with status and HTTP constants.
Based on "Porting Apache:: Perl Modules from mod_perl 1.0 to 2.0" document
http://perl.apache.org/docs/2.0/user/porting/porting.html
chapter "Making Code Conditional on Running mod_perl Version".
Use "if (MP_GEN)" for checking if gitweb is run under mod_perl; later
on we will use "if ($r)" for that.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
A bit of RFC, because I'm not sure if "my $r" or "our $r" should be
used (in script which makes use of subroutines; under Registry those
would end as nested subroutines).
Perhaps we should import everything?
gitweb/gitweb.perl | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3888563..9983e9e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -18,10 +18,36 @@ use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ':utf8';
+# Set the constant MP_GEN to 0 if mod_perl is not available,
+# to 1 if running under mod_perl 1.0
+# and 2 for mod_perl 2.0
+use constant {
+ MP_GEN => ($ENV{'MOD_PERL'}
+ ? ( exists $ENV{'MOD_PERL_API_VERSION'} and
+ $ENV{'MOD_PERL_API_VERSION'} >= 2 ) ? 2 : 1
+ : 0),
+};
+
BEGIN {
- CGI->compile() if $ENV{MOD_PERL};
+ # use appropriate mod_perl modules (conditional use)
+ if (MP_GEN == 2) {
+ require Apache2::RequestRec;
+ require Apache2::Const;
+ Apache2::Const->import(-compile => qw(:common :http));
+ } elsif (MP_GEN == 1) {
+ require Apache;
+ require Apache::Constants;
+ Apache::Constants->import(qw(:common :http));
+ }
+
+ # precompile CGI for mod_perl
+ CGI->compile() if MP_GEN;
}
+# mod_perl request
+my $r;
+$r = shift @_ if MP_GEN;
+
our $cgi = new CGI;
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
--
1.4.4.3
^ permalink raw reply related
* [PATCH 2/6] gitweb: Add mod_perl version string to "generator" meta header
From: Jakub Narebski @ 2006-12-27 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Add mod_perl version string (the value of $ENV{'MOD_PERL'} if it is
set) to "generator" meta header.
The purpose of this is to identify version of gitweb, now that
codepath may differ for gitweb run as CGI script, run under
mod_perl 1.0 and run under mod_perl 2.0.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
For example mod_perl 2.0 sets MOD_PERL to something like
"mod_perl/2.0.1".
This patch was created because further patches make gitweb to
have different codepath for mod_perl; so mod_perl version string
was added to "generator" meta header in HTML header.
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index aaee217..bb1d66c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1724,6 +1724,8 @@ sub git_header_html {
-charset => 'utf-8',
-status => $status,
-expires => $expires);
+ # the environmental variable MOD_PERL has 'mod_perl/VERSION' value if set
+ my $mod_perl_version = $ENV{'MOD_PERL'} ? " $ENV{'MOD_PERL'}" : '';
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -1732,7 +1734,7 @@ sub git_header_html {
<!-- git core binaries version $git_version -->
<head>
<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
-<meta name="generator" content="gitweb/$version git/$git_version"/>
+<meta name="generator" content="gitweb/$version git/$git_version$mod_perl_version"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
--
1.4.4.3
^ permalink raw reply related
* [PATCH 3/6] gitweb: Precompile CGI routines for mod_perl
From: Jakub Narebski @ 2006-12-27 23:00 UTC (permalink / raw)
To: git
In-Reply-To: <200612272355.31923.jnareb@gmail.com>
Following advice from CGI(3pm) man page, precompile all CGI routines
for mod_perl, in the BEGIN block.
If you want to compile without importing use the compile() method
instead:
use CGI();
CGI->compile();
This is particularly useful in a mod_perl environment, in which you
might want to precompile all CGI routines in a startup script, and then
import the functions individually in each mod_perl script.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Could help. I'm a bit unsure.
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bb1d66c..3888563 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -18,6 +18,10 @@ use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ':utf8';
+BEGIN {
+ CGI->compile() if $ENV{MOD_PERL};
+}
+
our $cgi = new CGI;
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
--
1.4.4.3
^ 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