* Re: [PATCH] gitweb: Consolidate escaping/validation of query string
From: Jakub Narebski @ 2006-09-23 22:41 UTC (permalink / raw)
To: git
In-Reply-To: <ef4csl$7vk$1@sea.gmane.org>
Jakub Narebski wrote:
> I'd rather have new esc_param() or esc_param_value() quote like escape
> subroutine from CGI::Util, with the esception of _not_ escaping '/'
> (it makes funny bookmark, and lot less readable query string), and rename
> current esc_param() to esc_query_string() or esc_params().
Or just esc_url()
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Kill git-resolve.sh
From: Jakub Narebski @ 2006-09-23 22:39 UTC (permalink / raw)
To: git
In-Reply-To: <7v64fensge.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Seriously, is anyone still using this thing? It's collecting dust and
>> blocking the name for something potentially useful like a tool for
>> user-friendly marking of resolved conflicts or resolving index conflicts.
>>
>> We've loved you when Git was young, now thank you and please go away. ;-)
>>
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>
> I've always wanted to do this at some point. Perhaps add a big
> red warning to git-resolve.sh right now and say "after the next
> 'master' release this will go away" to its stdout for a few
> weeks to find out who screams?
>
> On a very related note, we should prepare plan to deprecate
> merge-recursive.py. My preference is:
>
> (1) rename merge-recursive.py to merge-recursive-old.py,
> make it available as "recursive-old" strategy.
>
> install git-merge-recur as git-merge-recursive.
> Calling for "recur" or "recursive" strategy gets the
> same thing from this point on.
>
> (2) remove merge-recur synonym once people who are using
> "USE_RECUR_FOR_RECURSIVE" or "merge.twohead = recur"
> to use the bleeding edge migrate.
>
> and I think step (1) can happen fairly soon. Maybe immediately
> after the next release from the "master".
>
> Perhaps that is the good timing to remove git-resolve.sh as
> well. Or maybe immediately before that release? I dunno, and I
> do not think anybody cares really much.
On the fairly unrelated note, would the next release be 1.4.3, or would it
be 1.5.0 (the packed refs, the new index format, ...)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Consolidate escaping/validation of query string
From: Jakub Narebski @ 2006-09-23 22:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060923221841.18063.56589.stgit@rover>
Petr Baudis wrote:
> Consider:
>
> http://repo.or.cz/?p=glibc-cvs.git;a=tree;h=2609cb0411389325f4ee2854cc7159756eb0671e;hb=2609cb0411389325f4ee2854cc7159756eb0671e
>
> (click on the funny =__ify file)
Aaargh? Why this name?
> We ought to handle anything in filenames and I actually see no reason why
> we don't, modulo very little missing escaping that this patch hopefully
> also fixes.
>
> I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
> buggy and [?=] just feels better escaped. ;-) YMMV.
First of all, before introduction href() subroutine we escaped (using
esc_param) the _whole_ generated query string. Now we need to escape
only value part (as we can assume that parameter names are correct;
they are taken from limited pre-defined set).
I'd rather have new esc_param() or esc_param_value() quote like escape
subroutine from CGI::Util, with the esception of _not_ escaping '/'
(it makes funny bookmark, and lot less readable query string), and rename
current esc_param() to esc_query_string() or esc_params().
Perhaps we should have also esc_arg() for things like title attribute
of <a> (link) element (or other element) and filename="..." part of
Content-disposition: HTTP header.
By the way, the validate_input() should be split into separate subroutines:
validate_ref() for validating hash, hash_base, hash_parent, hash_parent_base,
and validate_path() for validating project, file_name and file_parent
parameters.
We should _never_ use esc_html except during the output, or just before output.
It certainly shouldn't take place in parse_* subroutine (or in the fake parse
like in git_blobdiff)!
P.S. gitweb was tested I think with filenames wirh spaces. Perhaps we should
add some other test file to gitweb/test, with '=', '@', '$', '?', '*', ' ', '\n'
etc.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Deprecate git-resolve.sh
From: Petr Baudis @ 2006-09-23 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64fensge.fsf@assigned-by-dhcp.cox.net>
Seriously, is anyone still using this thing? It's collecting dust and
blocking the name for something potentially useful like a tool for
user-friendly marking of resolved conflicts or resolving index conflicts.
We've loved you when Git was young, now thank you and please go away. ;-)
This makes git-resolve.sh print a big deprecation warning and sleep a bit
for extra annoyance. It should be removed completely after the next release.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I won't touch git-merge-recursive.py because I really have no clue how
those fancy merge drivers work.
git-resolve.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-resolve.sh b/git-resolve.sh
index a7bc680..729ec65 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -5,6 +5,10 @@ #
# Resolve two trees.
#
+echo 'WARNING: This command is DEPRECATED and will be removed very soon.' >&2
+echo 'WARNING: Please use git-merge or git-pull instead.' >&2
+sleep 2
+
USAGE='<head> <remote> <merge-message>'
. git-sh-setup
^ permalink raw reply related
* [PATCH] gitweb: Consolidate escaping/validation of query string
From: Petr Baudis @ 2006-09-23 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Consider:
http://repo.or.cz/?p=glibc-cvs.git;a=tree;h=2609cb0411389325f4ee2854cc7159756eb0671e;hb=2609cb0411389325f4ee2854cc7159756eb0671e
(click on the funny =__ify file)
We ought to handle anything in filenames and I actually see no reason why
we don't, modulo very little missing escaping that this patch hopefully
also fixes.
I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
buggy and [?=] just feels better escaped. ;-) YMMV.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 32 +++++++++++---------------------
1 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2c6b197..bd47985 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -212,19 +212,9 @@ if (defined $project) {
}
}
+# We have to handle those containing any characters:
our $file_name = $cgi->param('f');
-if (defined $file_name) {
- if (!validate_input($file_name)) {
- die_error(undef, "Invalid file parameter");
- }
-}
-
our $file_parent = $cgi->param('fp');
-if (defined $file_parent) {
- if (!validate_input($file_parent)) {
- die_error(undef, "Invalid file parent parameter");
- }
-}
our $hash = $cgi->param('h');
if (defined $hash) {
@@ -305,7 +295,7 @@ sub evaluate_path_info {
$action ||= "blob_plain";
}
$hash_base ||= validate_input($refname);
- $file_name ||= validate_input($pathname);
+ $file_name ||= $pathname;
} elsif (defined $refname) {
# we got "project.git/branch"
$action ||= "shortlog";
@@ -416,7 +406,7 @@ # quote unsafe chars, but keep the slash
# correct, but quoted slashes look too horrible in bookmarks
sub esc_param {
my $str = shift;
- $str =~ s/([^A-Za-z0-9\-_.~();\/;?:@&=])/sprintf("%%%02X", ord($1))/eg;
+ $str =~ s/([^A-Za-z0-9\-_.~()\/:@])/sprintf("%%%02X", ord($1))/eg;
$str =~ s/\+/%2B/g;
$str =~ s/ /\+/g;
return $str;
@@ -1289,7 +1279,7 @@ sub git_header_html {
if (defined $action) {
$title .= "/$action";
if (defined $file_name) {
- $title .= " - $file_name";
+ $title .= " - " . esc_html($file_name);
if ($action eq "tree" && $file_name !~ m|/$|) {
$title .= "/";
}
@@ -2439,7 +2429,7 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
+ open ($fd, "-|", git_cmd(), "blame", '-l', '--', $file_name, $hash_base)
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -3081,12 +3071,12 @@ sub git_blobdiff {
if (defined $file_name) {
if (defined $file_parent) {
$diffinfo{'status'} = '2';
- $diffinfo{'from_file'} = $file_parent;
- $diffinfo{'to_file'} = $file_name;
+ $diffinfo{'from_file'} = esc_html($file_parent);
+ $diffinfo{'to_file'} = esc_html($file_name);
} else { # assume not renamed
$diffinfo{'status'} = '1';
- $diffinfo{'from_file'} = $file_name;
- $diffinfo{'to_file'} = $file_name;
+ $diffinfo{'from_file'} = esc_html($file_name);
+ $diffinfo{'to_file'} = esc_html($file_name);
}
} else { # no filename given
$diffinfo{'status'} = '2';
@@ -3135,7 +3125,7 @@ sub git_blobdiff {
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
- -content_disposition => qq(inline; filename="${file_name}.patch"));
+ -content_disposition => qq(inline; filename=") . quotemeta($file_name) . qq(.patch"));
print "X-Git-Url: " . $cgi->self_url() . "\n\n";
@@ -3585,7 +3575,7 @@ XML
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
next;
}
- my $file = validate_input(unquote($7));
+ my $file = esc_html(unquote($7));
$file = decode("utf8", $file, Encode::FB_DEFAULT);
print "$file<br/>\n";
}
^ permalink raw reply related
* Re: [PATCH] Kill git-resolve.sh
From: Junio C Hamano @ 2006-09-23 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060923195530.5570.23774.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Seriously, is anyone still using this thing? It's collecting dust and
> blocking the name for something potentially useful like a tool for
> user-friendly marking of resolved conflicts or resolving index conflicts.
>
> We've loved you when Git was young, now thank you and please go away. ;-)
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
I've always wanted to do this at some point. Perhaps add a big
red warning to git-resolve.sh right now and say "after the next
'master' release this will go away" to its stdout for a few
weeks to find out who screams?
On a very related note, we should prepare plan to deprecate
merge-recursive.py. My preference is:
(1) rename merge-recursive.py to merge-recursive-old.py,
make it available as "recursive-old" strategy.
install git-merge-recur as git-merge-recursive.
Calling for "recur" or "recursive" strategy gets the
same thing from this point on.
(2) remove merge-recur synonym once people who are using
"USE_RECUR_FOR_RECURSIVE" or "merge.twohead = recur"
to use the bleeding edge migrate.
and I think step (1) can happen fairly soon. Maybe immediately
after the next release from the "master".
Perhaps that is the good timing to remove git-resolve.sh as
well. Or maybe immediately before that release? I dunno, and I
do not think anybody cares really much.
^ permalink raw reply
* Re: [PATCH] Remove branch by putting a null sha1 into the ref file.
From: Junio C Hamano @ 2006-09-23 21:49 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200609231322.30214.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> You are right, so what about moving ".git/refs/heads/frotz"
> to ".git/deleted-refs/heads/frotz.ref"
> or ".git/deleted-refs/heads/frotz~ref" (because "~" is forbidden in ref
> names).
But wouldn't it bring up the issue of locking among deleters,
updaters/creators, and traversers?
If we choose to use packed-refs.lock as the "set of all refs"
lock, the whole sequence would become something like this. Note
that this tries to make readers lockless but I am sure there are
nasty race condition issues. I am not sure what we would want
to do about them.
= Looking up a ref $frotz.
- check if .git/$frotz exists, and use it if it does.
- check if .git/deleted-refs/$frotz~ref exists, and return "no
such ref" if it does.
- find $frotz in .git/packed-refs.
= Looping over refs.
- grab all .git/refs/ and subtract all .git/deleted-refs/
- walk .git/packed-refs and the result from the above in
parallel as in the current code.
= Storing a new value in ref $frotz.
- acquire .git/packed-refs.lock
- lock .git/$frotz.lock.
- write into .git/$frotz.lock.
- create or update .git/logs/$frotz as needed.
- if .git/deleted-refs/$frotz~ref exists, unlink it.
- rename .git/$frotz.lock to .git/$frotz to unlock it.
- unlink .git/packed-refs.lock
= Deleting a ref $frotz.
- acquire .git/packed-refs.lock
- look up $frotz; if it does not exist either barf or return
silent (haven't thought it through yet).
- create .git/deleted-refs/$frotz~ref.
- remove .git/logs/$frotz
- unlink .git/packed-refs.lock
= Packing refs, with optional pruning.
- lock .git/packed-refs.lock
- loop over refs:
- write it out to .git/packed-refs.lock unless a symref.
- if it is a loose one (not a symref), remember it for pruning.
- if pruning:
- remove the entire .git/deleted-refs/ hierarchy
- remove the remembered ones
- rename .git/packed-refs.lock to .git/packed-refs
^ permalink raw reply
* [PATCH 4/4 (take 4)] Add test for the default merges in fetch.
From: Santi Béjar @ 2006-09-23 20:55 UTC (permalink / raw)
To: git
In-Reply-To: <87ac4qfgvc.fsf@gmail.com>
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
t/t5510-fetch.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index e71581a..c7faffe
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -27,6 +27,16 @@ test_expect_success "clone and setup chi
echo "URL: ../one/.git/"
echo "Pull: refs/heads/master:refs/heads/one"
} >.git/remotes/one
+ cd .. &&
+ git clone . three &&
+ cd three &&
+ git repo-config branch.master.remote two
+ git repo-config branch.master.merge refs/heads/one
+ {
+ echo "URL: ../two/.git/"
+ echo "Pull: refs/heads/master:refs/heads/two"
+ echo "Pull: refs/heads/one:refs/heads/one"
+ } >.git/remotes/two
'
test_expect_success "fetch test" '
@@ -41,4 +51,17 @@ test_expect_success "fetch test" '
test "z$mine" = "z$his"
'
+test_expect_success "fetch test for-merge" '
+ cd "$D" &&
+ cd three &&
+ git fetch &&
+ test -f .git/refs/heads/two &&
+ test -f .git/refs/heads/one &&
+ {
+ echo -e "not-for-merge branch \047master\047 of ../two/"
+ echo -e " branch \047one\047 of ../two/"
+ } > expected &&
+ cut -f 2- .git/FETCH_HEAD > actual &&
+ diff expected actual'
+
test_done
--
1.4.2.1.g279b
^ permalink raw reply related
* [PATCH 3/4 (take 4)] fetch: get the remote branches to merge from the branch properties
From: Santi Béjar @ 2006-09-23 20:53 UTC (permalink / raw)
To: git
In-Reply-To: <87ac4qfgvc.fsf@gmail.com>
If in branch "foo" and this in config:
[branch "foo"]
merge=bar
"git fetch": fetch from the default repository and program the "bar"
branch to be merged with pull.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Documentation/config.txt | 4 ++++
git-parse-remote.sh | 37 +++++++++++++++++++++++++++++--------
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 04c5094..98c1f3e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -122,6 +122,10 @@ apply.whitespace::
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
+branch.<name>.merge::
+ When in branch <name>, it tells `git fetch` the default remote branch
+ to be merged.
+
pager.color::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 6999816..c325ef7 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -92,9 +92,22 @@ get_remote_default_refs_for_push () {
# Subroutine to canonicalize remote:local notation.
canon_refs_list_for_fetch () {
- # Leave only the first one alone; add prefix . to the rest
+ # If called from get_remote_default_refs_for_fetch
+ # leave the branches in branch.${curr_branch}.merge alone,
+ # or the first one otherwise; add prefix . to the rest
# to prevent the secondary branches to be merged by default.
- dot_prefix=
+ merge_branches=
+ if test "$1" = "-d"
+ then
+ shift ; remote="$1" ; shift
+ if test "$remote" = "$(get_default_remote)"
+ then
+ curr_branch=$(git-symbolic-ref HEAD | \
+ sed -e 's|^refs/heads/||')
+ merge_branches=$(git-repo-config \
+ --get-all "branch.${curr_branch}.merge")
+ fi
+ fi
for ref
do
force=
@@ -107,6 +120,18 @@ canon_refs_list_for_fetch () {
expr "z$ref" : 'z.*:' >/dev/null || ref="${ref}:"
remote=$(expr "z$ref" : 'z\([^:]*\):')
local=$(expr "z$ref" : 'z[^:]*:\(.*\)')
+ dot_prefix=.
+ if test -z "$merge_branches"
+ then
+ merge_branches=$remote
+ dot_prefix=
+ else
+ for merge_branch in $merge_branches
+ do
+ [ "$remote" = "$merge_branch" ] &&
+ dot_prefix= && break
+ done
+ fi
case "$remote" in
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -126,7 +151,6 @@ canon_refs_list_for_fetch () {
die "* refusing to create funny ref '$local_ref_name' locally"
fi
echo "${dot_prefix}${force}${remote}:${local}"
- dot_prefix=.
done
}
@@ -137,7 +161,7 @@ get_remote_default_refs_for_fetch () {
'' | config-partial | branches-partial)
echo "HEAD:" ;;
config)
- canon_refs_list_for_fetch \
+ canon_refs_list_for_fetch -d "$1" \
$(git-repo-config --get-all "remote.$1.fetch") ;;
branches)
remote_branch=$(sed -ne '/#/s/.*#//p' "$GIT_DIR/branches/$1")
@@ -145,10 +169,7 @@ get_remote_default_refs_for_fetch () {
echo "refs/heads/${remote_branch}:refs/heads/$1"
;;
remotes)
- # This prefixes the second and later default refspecs
- # with a '.', to signal git-fetch to mark them
- # not-for-merge.
- canon_refs_list_for_fetch $(sed -ne '/^Pull: */{
+ canon_refs_list_for_fetch -d "$1" $(sed -ne '/^Pull: */{
s///p
}' "$GIT_DIR/remotes/$1")
;;
--
1.4.2.1.g279b
^ permalink raw reply related
* [PATCH 2/4 (take 4)] Add t5510 to test per branch configuration affecting git-fetch.
From: Santi Béjar @ 2006-09-23 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <87ac4qfgvc.fsf@gmail.com>
From: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
I hope the attribution is ok.
t/t5510-fetch.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
new file mode 100755
index 0000000..e71581a
--- /dev/null
+++ b/t/t5510-fetch.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+# Copyright (c) 2006, Junio C Hamano.
+
+test_description='Per branch config variables affects "git fetch".
+
+'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+test_expect_success setup '
+ echo >file original &&
+ git add file &&
+ git commit -a -m original'
+
+test_expect_success "clone and setup child repos" '
+ git clone . one &&
+ cd one &&
+ echo >file updated by one &&
+ git commit -a -m "updated by one" &&
+ cd .. &&
+ git clone . two &&
+ cd two &&
+ git repo-config branch.master.remote one &&
+ {
+ echo "URL: ../one/.git/"
+ echo "Pull: refs/heads/master:refs/heads/one"
+ } >.git/remotes/one
+'
+
+test_expect_success "fetch test" '
+ cd "$D" &&
+ echo >file updated by origin &&
+ git commit -a -m "updated by origin" &&
+ cd two &&
+ git fetch &&
+ test -f .git/refs/heads/one &&
+ mine=`git rev-parse refs/heads/one` &&
+ his=`cd ../one && git rev-parse refs/heads/master` &&
+ test "z$mine" = "z$his"
+'
+
+test_done
--
1.4.2.1.g279b
^ permalink raw reply related
* [PATCH 1/4 (take 4)] fetch: default remote repository from branch properties
From: Santi Béjar @ 2006-09-23 20:50 UTC (permalink / raw)
To: git
In-Reply-To: <87ac4qfgvc.fsf@gmail.com>
If in branch "foo" and this in config:
[branch "foo"]
remote=bar
"git fetch" = "git fetch bar"
"git pull" = "git pull bar"
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Documentation/config.txt | 3 +++
git-fetch.sh | 9 ++++-----
git-parse-remote.sh | 6 ++++++
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bb2fbc3..04c5094 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -119,6 +119,9 @@ apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
+branch.<name>.remote::
+ When in branch <name>, it tells `git fetch` which remote to fetch.
+
pager.color::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-fetch.sh b/git-fetch.sh
index 09a5d6c..50ad101 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -68,11 +68,10 @@ done
case "$#" in
0)
- test -f "$GIT_DIR/branches/origin" ||
- test -f "$GIT_DIR/remotes/origin" ||
- git-repo-config --get remote.origin.url >/dev/null ||
- die "Where do you want to fetch from today?"
- set origin ;;
+ origin=$(get_default_remote)
+ test -n "$(get_remote_url ${origin})" ||
+ die "Where do you want to fetch from today?"
+ set x $origin ; shift ;;
esac
remote_nick="$1"
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 187f088..6999816 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -68,6 +68,12 @@ get_remote_url () {
esac
}
+get_default_remote () {
+ curr_branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
+ origin=$(git-repo-config --get "branch.$curr_branch.remote")
+ echo ${origin:-origin}
+}
+
get_remote_default_refs_for_push () {
data_source=$(get_data_source "$1")
case "$data_source" in
--
1.4.2.1.g279b
^ permalink raw reply related
* Re: [RFC/PATCH] gitweb: Add committags support
From: Junio C Hamano @ 2006-09-23 20:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef44r4$km0$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> The idea of doing committag parsing, and preserving replacements
> from matching committag and being subject to HTML escaping by using
> reference to string has it's merits.
>
> I'd have to think about it.
Good. My obviously buggy illustration would be easier to read
with this patch ;-).
--- gomi 2006-09-23 13:47:52.000000000 -0700
+++ gomi 2006-09-23 13:48:23.000000000 -0700
@@ -2,7 +2,7 @@
my @input = (@_);
my @output;
for (@input) {
- if (!ref $_) {
+ if (ref $_) {
push @output, $_;
next;
}
@@ -19,6 +19,9 @@
}
$_ = $post;
}
+ if ($_ ne '') {
+ push @output, $_;
+ }
}
return @output;
}
^ permalink raw reply
* [PATCH 0/4 (take 4)] Fetch: branch properties for fetch.
From: Santi Béjar @ 2006-09-23 20:49 UTC (permalink / raw)
To: git
Hi *,
This patch series implements the following branch properties for fetch:
- default repository to fetch
- default remotes branches to merge from the default repository
and adds some tests.
It passes all the tests.
Santi
---
Documentation/config.txt | 7 +++++
git-fetch.sh | 9 +++---
git-parse-remote.sh | 43 ++++++++++++++++++++++++------
t/t5510-fetch.sh | 67 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 113 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [RFC][PATCH] gitweb: Make the Git logo link target to point to the homepage
From: Junio C Hamano @ 2006-09-23 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef43do$fm1$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> - "<a href=\"http://www.kernel.org/pub/software/scm/git/docs/\" title=\"git documentation\">" .
>> + "<a href=\"" . esc_html($githelp_url) .
>> + "\" title=\"" . esc_html($githelp_label) .
>> + "\">" .
>
> Why not use $cgi->a_begin({-href=>esc_param($githelp_url), -title=>$githelp_label});
> or just plain $cgi->a and $cgi->img?
Be my guest and send in a proper patch please.
I was merely demonstrating my preference on how definition of
default values and actual use of them are separated.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Jakub Narebski @ 2006-09-23 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <7veju2s6bi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> True. Without looking at Jakub's code under discussion, off the
> top of my head, I wonder if we can do something like this:
The code was to analyse log message line after line, doing loop
over all committags, building list (well, hash to be more exact)
of _exact_ replacements (e.g. in the case of commit_id/commitsha
committag we use exact hash as the replaced part, not generic
regexp to find a sha1).
The idea of doing committag parsing, and preserving replacements
from matching committag and being subject to HTML escaping by using
reference to string has it's merits.
I'd have to think about it.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Junio C Hamano @ 2006-09-23 19:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060923121134.GM13132@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Also, there is a fundamental limitation for the multi-word patterns that
> they won't work if the line wraps at that point in the log message. This
> will likely be a problem especially for the msgids, because those are
> very long and are very likely to cause a linewrap immediately before.
>
> By the way, I don't think taking just 40-digits sha1s is very useful,
> since that's insanely long and besides the linewrap issue, a lot of
> people just shorten that to some 8 to 12 digits now - I'd use {8-40}
> instead (the enforced minimum is 4 in the Git autocompletion code but we
> shouldn't encourage people to write so ambiguous sha1s to persistent
> records).
True. Without looking at Jakub's code under discussion, off the
top of my head, I wonder if we can do something like this:
(1) take the whole commit log message, not line by line, into a
Perl variable, say $log. Note that this is _before_ HTML
escaping.
(2) each enabled tag-marking sub are expected to take a list of
string or ref as its parameter. The first one in the chain
takes a single parameter which is ($log). You call all the
enabled ones, in some order, and feed the return value from
the previous one as the input to the next one.
(3) a tag-marking sub are expected to inspect the list it
received as its input parameter, and build its return value
by looking at each element in the list:
(3-1) if the element is not a string, pass it down as-is
in the output list.
(3-2) if the element is a string, do the pattern match,
and output one or more elements in the output list.
Literal string you did not care about are placed as
string for later taggers to be processed, the links you
generate are placed as a ref to string.
For example, commit_id tag-marker might look like this:
sub tag_marker_commit_id {
my @input = (@_);
my @output;
for (@input) {
if (!ref $_) {
push @output, $_;
next;
}
while ($_ ne '' && m/(.*?)\b([0-9a-fA-F]{6,})\b(.*)/s) {
my ($pre, $sha1, $post) = ($1, $2, $3);
if (!is_a_commit_id($sha1)) {
push @output, "$pre$sha1";
}
else {
my $subst =
href(action => 'commit', hash => $2);
push @output, $1;
push @output, \$subst;
}
$_ = $post;
}
}
return @output;
}
(4) when you finished calling the chain, you would have a list
of string and ref. You html quote the strings and pass
the ref's (which are supposed to be already HTML) as is,
and concatenate the result:
sub markup_all {
my ($log) = @_;
my @current = $log;
for my $tag_marker (@tag_markers) {
@current = $tag_marker->(@current);
}
return join('',
map {
(ref $_) ? $$_ : esc_html($_)
} @current);
}
Hmm?
^ permalink raw reply
* [PATCH] Kill git-resolve.sh
From: Petr Baudis @ 2006-09-23 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Seriously, is anyone still using this thing? It's collecting dust and
blocking the name for something potentially useful like a tool for
user-friendly marking of resolved conflicts or resolving index conflicts.
We've loved you when Git was young, now thank you and please go away. ;-)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
.gitignore | 1
Documentation/git-resolve.txt | 36 --------------
Documentation/git.txt | 3 -
Makefile | 2 -
git-resolve.sh | 108 -----------------------------------------
5 files changed, 1 insertions(+), 149 deletions(-)
diff --git a/.gitignore b/.gitignore
index 0ffe14a..f89bbc6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -92,7 +92,6 @@ git-repo-config
git-request-pull
git-rerere
git-reset
-git-resolve
git-rev-list
git-rev-parse
git-revert
diff --git a/Documentation/git-resolve.txt b/Documentation/git-resolve.txt
deleted file mode 100644
index 4e57c2b..0000000
--- a/Documentation/git-resolve.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-git-resolve(1)
-==============
-
-NAME
-----
-git-resolve - Merge two commits
-
-
-SYNOPSIS
---------
-'git-resolve' <current> <merged> <message>
-
-DESCRIPTION
------------
-Given two commits and a merge message, merge the <merged> commit
-into <current> commit, with the commit log message <message>.
-
-When <current> is a descendant of <merged>, or <current> is an
-ancestor of <merged>, no new commit is created and the <message>
-is ignored. The former is informally called "already up to
-date", and the latter is often called "fast forward".
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org> and
-Dan Holmsand <holmsand@gmail.com>.
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the gitlink:git[7] suite
-
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 744c38d..a2efd17 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -336,9 +336,6 @@ gitlink:git-rerere[1]::
gitlink:git-reset[1]::
Reset current HEAD to the specified state.
-gitlink:git-resolve[1]::
- Merge two commits.
-
gitlink:git-revert[1]::
Revert an existing commit.
diff --git a/Makefile b/Makefile
index 58848e4..6a7c408 100644
--- a/Makefile
+++ b/Makefile
@@ -169,7 +169,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-resolve.sh git-revert.sh git-sh-setup.sh \
+ git-revert.sh git-sh-setup.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
diff --git a/git-resolve.sh b/git-resolve.sh
deleted file mode 100755
index a7bc680..0000000
--- a/git-resolve.sh
+++ /dev/null
@@ -1,108 +0,0 @@
-#!/bin/sh
-#
-# Copyright (c) 2005 Linus Torvalds
-#
-# Resolve two trees.
-#
-
-USAGE='<head> <remote> <merge-message>'
-. git-sh-setup
-
-dropheads() {
- rm -f -- "$GIT_DIR/MERGE_HEAD" \
- "$GIT_DIR/LAST_MERGE" || exit 1
-}
-
-head=$(git-rev-parse --verify "$1"^0) &&
-merge=$(git-rev-parse --verify "$2"^0) &&
-merge_name="$2" &&
-merge_msg="$3" || usage
-
-#
-# The remote name is just used for the message,
-# but we do want it.
-#
-if [ -z "$head" -o -z "$merge" -o -z "$merge_msg" ]; then
- usage
-fi
-
-dropheads
-echo $head > "$GIT_DIR"/ORIG_HEAD
-echo $merge > "$GIT_DIR"/LAST_MERGE
-
-common=$(git-merge-base $head $merge)
-if [ -z "$common" ]; then
- die "Unable to find common commit between" $merge $head
-fi
-
-case "$common" in
-"$merge")
- echo "Already up-to-date. Yeeah!"
- dropheads
- exit 0
- ;;
-"$head")
- echo "Updating from $head to $merge"
- git-read-tree -u -m $head $merge || exit 1
- git-update-ref -m "resolve $merge_name: Fast forward" \
- HEAD "$merge" "$head"
- git-diff-tree -p $head $merge | git-apply --stat
- dropheads
- exit 0
- ;;
-esac
-
-# We are going to make a new commit.
-git var GIT_COMMITTER_IDENT >/dev/null || exit
-
-# Find an optimum merge base if there are more than one candidates.
-LF='
-'
-common=$(git-merge-base -a $head $merge)
-case "$common" in
-?*"$LF"?*)
- echo "Trying to find the optimum merge base."
- G=.tmp-index$$
- best=
- best_cnt=-1
- for c in $common
- do
- rm -f $G
- GIT_INDEX_FILE=$G git-read-tree -m $c $head $merge \
- 2>/dev/null || continue
- # Count the paths that are unmerged.
- cnt=`GIT_INDEX_FILE=$G git-ls-files --unmerged | wc -l`
- if test $best_cnt -le 0 -o $cnt -le $best_cnt
- then
- best=$c
- best_cnt=$cnt
- if test "$best_cnt" -eq 0
- then
- # Cannot do any better than all trivial merge.
- break
- fi
- fi
- done
- rm -f $G
- common="$best"
-esac
-
-echo "Trying to merge $merge into $head using $common."
-git-update-index --refresh 2>/dev/null
-git-read-tree -u -m $common $head $merge || exit 1
-result_tree=$(git-write-tree 2> /dev/null)
-if [ $? -ne 0 ]; then
- echo "Simple merge failed, trying Automatic merge"
- git-merge-index -o git-merge-one-file -a
- if [ $? -ne 0 ]; then
- echo $merge > "$GIT_DIR"/MERGE_HEAD
- die "Automatic merge failed, fix up by hand"
- fi
- result_tree=$(git-write-tree) || exit 1
-fi
-result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
-echo "Committed merge $result_commit"
-git-update-ref -m "resolve $merge_name: In-index merge" \
- HEAD "$result_commit" "$head"
-git-diff-tree -p $head $result_commit | git-apply --stat
-dropheads
^ permalink raw reply related
* Re: [RFC][PATCH] gitweb: Make the Git logo link target to point to the homepage
From: Jakub Narebski @ 2006-09-23 19:54 UTC (permalink / raw)
To: git
In-Reply-To: <7virjes7dq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> - "<a href=\"http://www.kernel.org/pub/software/scm/git/docs/\" title=\"git documentation\">" .
> + "<a href=\"" . esc_html($githelp_url) .
> + "\" title=\"" . esc_html($githelp_label) .
> + "\">" .
Why not use $cgi->a_begin({-href=>esc_param($githelp_url), -title=>$githelp_label});
or just plain $cgi->a and $cgi->img?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC][PATCH] gitweb: Make the Git logo link target to point to the homepage
From: Petr Baudis @ 2006-09-23 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virjes7dq.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Sep 23, 2006 at 09:36:01PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Tue, Sep 19, 2006 at 11:27:25PM CEST, I got a letter
> > where Petr Baudis <pasky@suse.cz> said that...
> >> It provides more useful information for causual Git users than the Git docs
> >> (especially about where to get Git and such).
> >>
> >> Signed-off-by: Petr Baudis <pasky@suse.cz>
> >
> > Ping? This is the only gitweb patch still in my stg stack. I guess
> > noone really cares strongly either way since there were no comments.
>
> I did not care either way, but I did not like either of these
> hardcoded strings in the code, and felt that if we are touching
> that part of the code we also should be making real improvement
> at the same time ;-).
>
> Doing something like this would let us update it easier, and
> let people override with GITWEB_CONFIG if they want to.
Reasonable.
Acked-by: Petr Baudis <pasky@suse.cz>
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [RFC][PATCH] gitweb: Make the Git logo link target to point to the homepage
From: Junio C Hamano @ 2006-09-23 19:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <20060923125746.GJ8259@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Tue, Sep 19, 2006 at 11:27:25PM CEST, I got a letter
> where Petr Baudis <pasky@suse.cz> said that...
>> It provides more useful information for causual Git users than the Git docs
>> (especially about where to get Git and such).
>>
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>
> Ping? This is the only gitweb patch still in my stg stack. I guess
> noone really cares strongly either way since there were no comments.
I did not care either way, but I did not like either of these
hardcoded strings in the code, and felt that if we are touching
that part of the code we also should be making real improvement
at the same time ;-).
Doing something like this would let us update it easier, and
let people override with GITWEB_CONFIG if they want to.
---
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d06181..ce90178 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -51,6 +51,9 @@ our $logo = "++GITWEB_LOGO++";
# URI of GIT favicon, assumed to be image/png type
our $favicon = "++GITWEB_FAVICON++";
+our $githelp_url = "http://git.or.cz/";
+our $githelp_label = "git homepage";
+
# source of projects list
our $projects_list = "++GITWEB_LIST++";
@@ -1335,7 +1338,9 @@ EOF
print "</head>\n" .
"<body>\n" .
"<div class=\"page_header\">\n" .
- "<a href=\"http://www.kernel.org/pub/software/scm/git/docs/\" title=\"git documentation\">" .
+ "<a href=\"" . esc_html($githelp_url) .
+ "\" title=\"" . esc_html($githelp_label) .
+ "\">" .
"<img src=\"$logo\" width=\"72\" height=\"27\" alt=\"git\" style=\"float:right; border-width:0px;\"/>" .
"</a>\n";
print $cgi->a({-href => esc_param($home_link)}, $home_link_str) . " / ";
^ permalink raw reply related
* Re: [RFC][RESEND][PATCH] Allow fetching from multiple repositories at once
From: Junio C Hamano @ 2006-09-23 19:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, A Large Angry SCM, git
In-Reply-To: <Pine.LNX.4.63.0609232007550.25853@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The thing is, your patch optimizes for a very special case, which special
> case IMHO should be handled differently to begin with.
I share the feeling, and the usual URL while spelling out the
repository name but used only for the site name, because other
special parameters are used to override the repository path
within the site, is just too ugly.
^ permalink raw reply
* Re: [RFC][PATCH] for_each_ref() returning heads in wrong order
From: Junio C Hamano @ 2006-09-23 19:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: torvalds, git
In-Reply-To: <20060923160712.5890.73139.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Using the #next branch I've now hit a problem with git-fetch-pack
> master choosing refs/bases/master (I geuss created by StGIT) instead
> of refs/heads/master. The old upload-pack returned the refs in the order
> heads-tags-everything_else but the new one just goes for whatever order
> readdir() returns them in (modulo merging with packed refs). I actually
> can't see the difference that caused this right now, though.
I think it is the other way around (the new one sorts, the old
one doesn't). fetch-pack lets for_each_ref() to pick, but the
wrapper git-fetch I think prepends refs/ and refs/heads as
needed, so if you explicitly say heads/master I do not think you
have a problem.
However, I see a bit bigger problem here. I think rev-parse
would not complain "master" is ambiguous in your repository,
because it has a fixed list of prefixes ("", refs, refs/tags,
refs/heads, refs/remotes, refs/remotes/%/HEAD) it uses to DWIM
in sha1_file.c::get_sha1_basic(), and refs/bases is not part of
the prefixes.
I suspect we should fix connect.c::count_refspec_match(), which
currently is just a strict tail match, to use the same list of
prefix.
^ permalink raw reply
* Re: [RFC][RESEND][PATCH] Allow fetching from multiple repositories at once
From: Petr Baudis @ 2006-09-23 19:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0609232007550.25853@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sat, Sep 23, 2006 at 08:14:28PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> Hmmm. Did you test if this makes things better? If so, could you test with
> one proxy repo on the server? I bet that this would be even more
> efficient.
I didn't test it but it _has_ to... ;-))
I will try to do some real benchmarks (repo.or.cz might come handy
here again) but I don't know when will I get to it. I will try the proxy
setup as well.
> And the proxy repo would be updated best by a hook, not a cronjob.
You would have a race window there.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [RFC][RESEND][PATCH] Allow fetching from multiple repositories at once
From: Petr Baudis @ 2006-09-23 19:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef3vb6$69d$1@sea.gmane.org>
Dear diary, on Sat, Sep 23, 2006 at 08:45:01PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > This patch enables fetching multiple repositories at once over the Git
> > protocol (and SSH, and locally if git-fetch-pack is your cup of coffee
> > there). This is done especially for the xorg people who have tons of
> > repositories and dislike pulls much slower than they were used to with CVS.
> > I'm eager to hear how this affects the situation.
> [...]
>
> I see that objects got to the one shared object database. Where the heads
> (refs) go to? Separate projects have separate ref spaces, even if they share
> object database...
git-fetch-pack actually does not save the refs at all, that's the job of
the porcelain (either git-fetch or cg-fetch). git-fetch-pack just emits
the refs list on stdout. See the script in a followup for an example of
a multirepo-aware porcelain wrapper.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Make cvsexportcommit work with filenames containing spaces.
From: Junio C Hamano @ 2006-09-23 19:03 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200609231427.55721.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> Why patch? Well this patch works around (i.e. not perfect) a mismatch between
> what patch eats and git submits. They are not totally, compatible, and I'm
> not sure who to blame yet. git emits diff's without timestamps, and what
> matters to patch, without a TAB before the file timestamp. When patch sees a
> header like "+++ filename with spaces.txt" it patches "filename". When it
> sees "+++ filename with spaces.txt<TAB>" if patches "filename with
> spaces.txt". The real fix would ofcourse be in git diff or patch sometime in
> the future.
Ah, it might be because our diff output do not have trailing TAB
(and timestamp) and if CVS uses GNU patch that would be confused
and not detect the file being patched.
Interestingly, I did a two-patch series to address that issue
separately. But that is not even in "next" yet.
More interestingly, the version of "GNU patch" that cannot grok
our patch (without trailing TAB) for a file that has SP in its
name is on my home machine where your patched cvsexportcommit
works. I do not know if GNU patch on the other machine does.
Will collect necessary info and follow up.
^ permalink raw reply
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