* Re: [PATCH] for-each-ref: fix setup of option-parsing for --sort
From: Junio C Hamano @ 2007-11-10 18:58 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, Jakub Narebski, Jon Smirl, git
In-Reply-To: <1194713274-31200-1-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> The option value for --sort is already a pointer to a pointer to struct
> ref_sort, so just use it.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> On Nov 10, 2007 5:25 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Could you add a test for that too, please?
>
> Is this ok?
>
Testing "for that" would be kind of hard and semi pointless,
isn't it?
If it's mismatch of the expected number of times a pointer is
dereferenced between the caller and the callee, I'd imagine that
it will read from and write to random place in memory and would
lead to unpredictable behaviour. If you are lucky you would not
get expected results but if you are unlucky who knows what would
happen.
But the new test makes sure --sort takes intended effect, which
is a good thing.
Thanks.
> builtin-for-each-ref.c | 2 +-
> t/t6300-for-each-ref.sh | 22 ++++++++++++++++++++++
> 2 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
> index da8c794..e909e66 100644
> --- a/builtin-for-each-ref.c
> +++ b/builtin-for-each-ref.c
> @@ -847,7 +847,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
> OPT_GROUP(""),
> OPT_INTEGER( 0 , "count", &maxcount, "show only <n> matched refs"),
> OPT_STRING( 0 , "format", &format, "format", "format to use for the output"),
> - OPT_CALLBACK(0 , "sort", &sort_tail, "key",
> + OPT_CALLBACK(0 , "sort", sort_tail, "key",
> "field name to sort on", &opt_parse_sort),
> OPT_END(),
> };
> diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
> index d0809eb..c722635 100755
> --- a/t/t6300-for-each-ref.sh
> +++ b/t/t6300-for-each-ref.sh
> @@ -148,4 +148,26 @@ test_expect_success 'Check format "rfc2822" date fields output' '
> git diff expected actual
> '
>
> +cat >expected <<\EOF
> +refs/heads/master
> +refs/tags/testtag
> +EOF
> +
> +test_expect_success 'Verify ascending sort' '
> + git-for-each-ref --format="%(refname)" --sort=refname >actual &&
> + git diff expected actual
> +'
> +
> +
> +cat >expected <<\EOF
> +refs/tags/testtag
> +refs/heads/master
> +EOF
> +
> +test_expect_success 'Verify descending sort' '
> + git-for-each-ref --format="%(refname)" --sort=-refname >actual &&
> + git diff expected actual
> +'
> +
> +
> test_done
> --
> 1.5.3.5.623.g0a1d
^ permalink raw reply
* Re: [PATCH] Make GIT_INDEX_FILE apply to git-commit
From: Junio C Hamano @ 2007-11-10 18:45 UTC (permalink / raw)
To: Remi Vanicat; +Cc: git
In-Reply-To: <6b8a91420711101038t3b2ca647v422f81d9365dd05d@mail.gmail.com>
"Remi Vanicat" <vanicat@debian.org> writes:
> 2007/11/10, Junio C Hamano <gitster@pobox.com>:
>> Sounds sensible. Tests?
>>
>
> all test pass
Sorry for being too terse. I did not mean existing tests.
Additional tests to make sure your fix will not be broken by
other people who touch the codepath later are requested.
^ permalink raw reply
* Re: git-branch silently ignores --track on local branches
From: Junio C Hamano @ 2007-11-10 18:43 UTC (permalink / raw)
To: Wayne Davison; +Cc: git, Johannes Schindelin
In-Reply-To: <20071110174557.GC1036@blorf.net>
Wayne Davison <wayne@opencoder.net> writes:
> ... Is there
> a problem with local branches being supported when explicitly
> requested?
Maybe this one?
commit 6f084a56fcb3543d88d252bb49c1d2bbf2bd0cf3
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Tue Jul 10 18:50:44 2007 +0100
branch --track: code cleanup and saner handling of local branches
This patch cleans up some complicated code, and replaces it with a
cleaner version, using code from remote.[ch], which got extended a
little in the process. This also enables us to fix two cases:
The earlier "fix" to setup tracking only when the original ref started
with "refs/remotes" is wrong. You are absolutely allowed to use a
separate layout for your tracking branches. The correct fix, of course,
is to set up tracking information only when there is a matching
remote.<nick>.fetch line containing a colon.
Another corner case was not handled properly. If two remotes write to
the original ref, just warn the user and do not set up tracking.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a local branch does not have to be "fetched", the restriction
on "remote.<nick>.fetch" is sort of pointless.
Also why remote.<nick>.fetch needs a colon, I begin to wonder.
You can be keep fetching and merging from the same branch of the
same remote without keeping a remote tracking branch for that,
but the above "correct fix" forbids that.
Dscho, what were we smoking when we made this change?
^ permalink raw reply
* Re: [PATCH] Make GIT_INDEX_FILE apply to git-commit
From: Remi Vanicat @ 2007-11-10 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vode2mljf.fsf@gitster.siamese.dyndns.org>
2007/11/10, Junio C Hamano <gitster@pobox.com>:
> Sounds sensible. Tests?
>
all test pass
^ permalink raw reply
* Re: git packs
From: bob @ 2007-11-10 18:01 UTC (permalink / raw)
To: git
In-Reply-To: <20071110174559.GA2200@old.davidb.org>
It is fairly disappointing as far as indicating the problem. Here is
the entire report since it was so short.
============ Begin =================
Process: git [82703]
Path: git
Identifier: git
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: bash [261]
Date/Time: 2007-11-10 11:23:33.976 -0500
OS Version: Mac OS X 10.5 (9A581)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5fc00000
Crashed Thread: Unknown
Error Formulating Crash Report:
*** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value
(key: VMUSignaturePath)
0x9501626b
0x9586009b
0x9501604b
0x9501608a
0x900d65e8
0x00078308
0x00087eb8
0x0008800e
0x000850a2
0x00002d90
0x000093be
0x0000b57c
0x0000b0c9
0x919f8793
0x0000a7d0
0x919cc075
0x919cbf32
Backtrace not available
Unknown thread crashed with X86 Thread State (64-bit):
rax: 0x000000000000003b rbx: 0x00000001191c9338 rcx:
0x0000000000000392 rdx: 0x00000000aff4bc3b
rdi: 0x00007fff5fc00000 rsi: 0x0000000040000003 rbp:
0x00007fff5fbff180 rsp: 0x00007fff5fbff160
r8: 0x0000000000000000 r9: 0x058487f0858487f0 r10:
0x000000002cb27436 r11: 0x000000000ee2afe3
r12: 0x00000000181c84c0 r13: 0x00007fff5fbff1a0 r14:
0x000000010000000c r15: 0x0000000101000000
rip: 0x00007fff80543ca5 rfl: 0x0000000000010202 cr2:
0x00007fff5fc00000
Binary images description not available
============ end =================
Maybe there was another option to specifiy other than "-m64 -arch
x86_64".
On Nov 10, 2007, at 12:45 PM, David Brown wrote:
> On Sat, Nov 10, 2007 at 12:40:16PM -0500, bob wrote:
>
>> I am guessing that the "Bus error" is an Apple
>> problem and it did produce a crashreport. So,
>> I am going to submit it to Apple since it is easily
>> reproducible.
>
> The crash report is probably not all that useful to Apple, since it
> occurs
> in a program you have built. Perhaps you should send the stack
> trace from
> the crash report here and people might have some ideas about what
> might be
> the problem.
>
> David
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git-branch silently ignores --track on local branches
From: Wayne Davison @ 2007-11-10 17:45 UTC (permalink / raw)
To: git
I used to be able to create a branch that tracked master (or another
local branch) by using "git branch --track new-branch" from that
checked-out branch. However, this functionality was apparently
removed and now the --track option is silently ignored for local
branches. I'd love to have this functionality restored. Is there
a problem with local branches being supported when explicitly
requested?
..wayne..
^ permalink raw reply
* Re: git packs
From: David Brown @ 2007-11-10 17:45 UTC (permalink / raw)
To: bob; +Cc: git
In-Reply-To: <00593593-E943-4DA0-AA9B-FDBB866E7EFB@mac.com>
On Sat, Nov 10, 2007 at 12:40:16PM -0500, bob wrote:
> I am guessing that the "Bus error" is an Apple
> problem and it did produce a crashreport. So,
> I am going to submit it to Apple since it is easily
> reproducible.
The crash report is probably not all that useful to Apple, since it occurs
in a program you have built. Perhaps you should send the stack trace from
the crash report here and people might have some ideas about what might be
the problem.
David
^ permalink raw reply
* Re: git packs
From: bob @ 2007-11-10 17:40 UTC (permalink / raw)
To: git
In-Reply-To: <F6DD8DCD-416B-4DDF-B384-7213C9ED5565@mac.com>
I compiled git under MacOSX 10.4.10 withr:
A) -m64 -arch ppc64 on a dual G5
B) -m64 -arch x86_64 on the dual quad-core
In both case, the link phase failed because there
was no 64-bit version of libz, libssl, libiconv and
libcrypto to link with.
I then installed MacOSX 10.5 (Leopard) which
was just released last month on the dual
quad-core machine with -m64 -arch x86_64.
git compiled and linked successfully. However,
it failed in the "git add ." which was the
second command after "git init". The message
was fairly cryptic, "Bus error".
I am guessing that the "Bus error" is an Apple
problem and it did produce a crashreport. So,
I am going to submit it to Apple since it is easily
reproducible.
Anyway, those are the results.
I am now going to split out the jpg(s), pdf(s)
and (.mov) files from the repository and just
manage them external to the git repository
which will fix my git problem.
I will report again when I get git running on
Leopard.
^ permalink raw reply
* [PATCH] for-each-ref: fix setup of option-parsing for --sort
From: Lars Hjemli @ 2007-11-10 16:47 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: Jakub Narebski, Jon Smirl, git
The option value for --sort is already a pointer to a pointer to struct
ref_sort, so just use it.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On Nov 10, 2007 5:25 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Could you add a test for that too, please?
Is this ok?
builtin-for-each-ref.c | 2 +-
t/t6300-for-each-ref.sh | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index da8c794..e909e66 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -847,7 +847,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
OPT_GROUP(""),
OPT_INTEGER( 0 , "count", &maxcount, "show only <n> matched refs"),
OPT_STRING( 0 , "format", &format, "format", "format to use for the output"),
- OPT_CALLBACK(0 , "sort", &sort_tail, "key",
+ OPT_CALLBACK(0 , "sort", sort_tail, "key",
"field name to sort on", &opt_parse_sort),
OPT_END(),
};
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index d0809eb..c722635 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -148,4 +148,26 @@ test_expect_success 'Check format "rfc2822" date fields output' '
git diff expected actual
'
+cat >expected <<\EOF
+refs/heads/master
+refs/tags/testtag
+EOF
+
+test_expect_success 'Verify ascending sort' '
+ git-for-each-ref --format="%(refname)" --sort=refname >actual &&
+ git diff expected actual
+'
+
+
+cat >expected <<\EOF
+refs/tags/testtag
+refs/heads/master
+EOF
+
+test_expect_success 'Verify descending sort' '
+ git-for-each-ref --format="%(refname)" --sort=-refname >actual &&
+ git diff expected actual
+'
+
+
test_done
--
1.5.3.5.623.g0a1d
^ permalink raw reply related
* Re: [PATCH] for-each-ref: fix setup of option-parsing for --sort
From: Johannes Schindelin @ 2007-11-10 16:25 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git, Jakub Narebski, Jon Smirl
In-Reply-To: <1194710863-22868-1-git-send-email-hjemli@gmail.com>
Hi,
On Sat, 10 Nov 2007, Lars Hjemli wrote:
> The option value for --sort is already a pointer to a pointer to struct
> ref_sort, so just use it.
Could you add a test for that too, please?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] --pretty=format: on-demand format expansion
From: René Scharfe @ 2007-11-10 16:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Paul Mackerras, Git Mailing List,
Pierre Habouzit
In-Reply-To: <Pine.LNX.4.64.0711101605560.4362@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Sat, 10 Nov 2007, René Scharfe wrote:
>
>> [...] have cooked up a different one on top of a cleaned up version of
>> mine. It plays the dirty trick of reading expansions of repeated
>> placeholders from the strbuf..
>
> ... which would not work (likely even segfault) if you work with the same
> private data on different strbufs.
>
> But I guess it will not matter much in practice.
Only a single strbuf is used, and the function that copies the data
around, strbuf_adddup(), operates on a single strbuf, only. Copying
data between two strbufs using strbuf_add() etc. would be safe.
What one should *not* do is this:
strbuf_add(sb, sb->buf + offset, length);
This leads to problems when the buffer is realloc()ated by strbuf_add().
What other things can go wrong? A segfault would definitely matter..
Thanks,
René
^ permalink raw reply
* Re: [PATCH 2/2] --pretty=format: on-demand format expansion
From: Johannes Schindelin @ 2007-11-10 16:07 UTC (permalink / raw)
To: René Scharfe
Cc: Jeff King, Junio C Hamano, Paul Mackerras, Git Mailing List,
Pierre Habouzit
In-Reply-To: <47359221.7090707@lsrfire.ath.cx>
Hi,
On Sat, 10 Nov 2007, Ren? Scharfe wrote:
> [...] have cooked up a different one on top of a cleaned up version of
> mine. It plays the dirty trick of reading expansions of repeated
> placeholders from the strbuf..
... which would not work (likely even segfault) if you work with the same
private data on different strbufs.
But I guess it will not matter much in practice.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] for-each-ref: fix setup of option-parsing for --sort
From: Lars Hjemli @ 2007-11-10 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Jon Smirl
In-Reply-To: <9e4733910711100610y478c62cend1d9af84e0ecc08b@mail.gmail.com>
The option value for --sort is already a pointer to a pointer to struct
ref_sort, so just use it.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-for-each-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index da8c794..e909e66 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -847,7 +847,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix)
OPT_GROUP(""),
OPT_INTEGER( 0 , "count", &maxcount, "show only <n> matched refs"),
OPT_STRING( 0 , "format", &format, "format", "format to use for the output"),
- OPT_CALLBACK(0 , "sort", &sort_tail, "key",
+ OPT_CALLBACK(0 , "sort", sort_tail, "key",
"field name to sort on", &opt_parse_sort),
OPT_END(),
};
--
1.5.3.5.623.g0a1d
^ permalink raw reply related
* [PATCH] builtin-commit: fix --signoff
From: Johannes Schindelin @ 2007-11-10 15:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, krh
In-Reply-To: <Pine.LNX.4.64.0711101346120.4362@racer.site>
The Signed-off-by: line contained a spurious timestamp. The reason was
a call to git_committer_info(1), which automatically added the
timestamp.
Instead, fmt_ident() was taught to interpret an empty string for the
date (as opposed to NULL, which still triggers the default behavior)
as "do not bother with the timestamp", and builtin-commit.c uses it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 10 Nov 2007, Johannes Schindelin wrote:
> Will redo the patch.
And here it is.
builtin-commit.c | 29 ++++++++++++++++++-----------
ident.c | 10 +++++++---
t/t7500-commit.sh | 13 +++++++++++++
3 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e8bc4c4..a4d69ad 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -181,21 +181,28 @@ static int prepare_log_message(const char *index_file, const char *prefix)
die("could not open %s\n", git_path(commit_editmsg));
stripspace(&sb, 0);
- if (fwrite(sb.buf, 1, sb.len, fp) < sb.len)
- die("could not write commit template: %s\n",
- strerror(errno));
if (signoff) {
- const char *info, *bol;
-
- info = git_committer_info(1);
- strbuf_addch(&sb, '\0');
- bol = strrchr(sb.buf + sb.len - 1, '\n');
- if (!bol || prefixcmp(bol, sign_off_header))
- fprintf(fp, "\n");
- fprintf(fp, "%s%s\n", sign_off_header, git_committer_info(1));
+ struct strbuf sob;
+ int i;
+
+ strbuf_init(&sob, 0);
+ strbuf_addstr(&sob, sign_off_header);
+ strbuf_addstr(&sob, fmt_ident(getenv("GIT_COMMITTER_NAME"),
+ getenv("GIT_COMMITTER_EMAIL"), "", 1));
+ strbuf_addch(&sob, '\n');
+
+ for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
+ ; /* do nothing */
+ if (prefixcmp(sb.buf + i, sob.buf))
+ strbuf_addbuf(&sb, &sob);
+ strbuf_release(&sob);
}
+ if (fwrite(sb.buf, 1, sb.len, fp) < sb.len)
+ die("could not write commit template: %s\n",
+ strerror(errno));
+
strbuf_release(&sb);
if (in_merge && !no_edit)
diff --git a/ident.c b/ident.c
index 9b2a852..5be7533 100644
--- a/ident.c
+++ b/ident.c
@@ -224,13 +224,17 @@ const char *fmt_ident(const char *name, const char *email,
}
strcpy(date, git_default_date);
- if (date_str)
- parse_date(date_str, date, sizeof(date));
+ if (date_str) {
+ if (*date_str)
+ parse_date(date_str, date, sizeof(date));
+ else
+ date[0] = '\0';
+ }
i = copy(buffer, sizeof(buffer), 0, name);
i = add_raw(buffer, sizeof(buffer), i, " <");
i = copy(buffer, sizeof(buffer), i, email);
- i = add_raw(buffer, sizeof(buffer), i, "> ");
+ i = add_raw(buffer, sizeof(buffer), i, date[0] ? "> " : ">");
i = copy(buffer, sizeof(buffer), i, date);
if (i >= sizeof(buffer))
die("Impossibly long personal identifier");
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index abbf54b..13d5a0c 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -93,4 +93,17 @@ test_expect_success 'commit message from file should override template' '
commit_msg_is "standard input msg"
'
+cat > expect << EOF
+zort
+Signed-off-by: C O Mitter <committer@example.com>
+EOF
+
+test_expect_success '--signoff' '
+ echo "yet another content *narf*" >> foo &&
+ echo "zort" |
+ GIT_EDITOR=../t7500/add-content git commit -s -F - foo &&
+ git cat-file commit HEAD | sed "1,/^$/d" > output &&
+ git diff expect output
+'
+
test_done
--
1.5.3.5.1674.g6e7f7
^ permalink raw reply related
* [PATCH] test-lib.sh: move error line after error() declaration
From: Michele Ballabio @ 2007-11-10 14:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch removes a spurious "command not found" error
and actually makes the "Test script did not set test_description."
string follow the command line option "--no-color".
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
This is for the master branch.
t/test-lib.sh | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 603a8cd..90b6844 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -66,9 +66,6 @@ esac
tput sgr0 >/dev/null 2>&1 &&
color=t
-test "${test_description}" != "" ||
-error "Test script did not set test_description."
-
while test "$#" -ne 0
do
case "$1" in
@@ -77,8 +74,7 @@ do
-i|--i|--im|--imm|--imme|--immed|--immedi|--immedia|--immediat|--immediate)
immediate=t; shift ;;
-h|--h|--he|--hel|--help)
- echo "$test_description"
- exit 0 ;;
+ help=t; shift ;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t; shift ;;
-q|--q|--qu|--qui|--quie|--quiet)
@@ -124,6 +120,15 @@ say () {
say_color info "$*"
}
+test "${test_description}" != "" ||
+error "Test script did not set test_description."
+
+if test "$help" = "t"
+then
+ echo "$test_description"
+ exit 0
+fi
+
exec 5>&1
if test "$verbose" = "t"
then
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH 07/11] git-fetch: Limit automated tag following to only fetched objects
From: Andreas Ericsson @ 2007-11-10 14:10 UTC (permalink / raw)
To: CJ van den Berg; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <20071109121228.GA4241@prefect.vdbonline.net>
CJ van den Berg wrote:
> On Fri, Nov 09, 2007 at 06:06:31AM -0500, Shawn O. Pearce wrote:
>> We now redefine the rule to be: "tags are fetched if they refer
>> to an object that was just transferred; that is an object that is
>> new to your repository". This rule is quite simple to understand,
>> you only get a tag if you just got the object it refers to.
>
> With this new rule a retrospectively pushed tag will never be fetched,
> right? With our local work flow tags are only ever pushed retrospectively
> because the tagged commit has to first pass regression tests. So this would
> be a major regression for us.
>
Same for us. Deciding after something has been pushed that "ok, this version
works, let's make that one the release" is, I think, fairly common behaviour.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory
From: Johannes Schindelin @ 2007-11-10 14:10 UTC (permalink / raw)
To: Michel Marti; +Cc: git
In-Reply-To: <fh46vv$ooj$1@ger.gmane.org>
Hi,
please, please, please do not cull the Cc list. I consider it rude to
reply to _me_, but _address_ the mail to me, either the To: (preferred) or
the Cc: (not so preferred).
On Sat, 10 Nov 2007, Michel Marti wrote:
> Untracked files in the current dir don't include the relative path
> to the project-root, but changed/updated files do:
>
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: ../subdir/hello
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # world
>
> With the patch below (on top of your changes), the output becomes
>
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: hello
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # world
>
> Cheers,
>
> - Michel
>
> diff --git a/wt-status.c b/wt-status.c
> index 0d25362..2cdc8ce 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -133,8 +133,8 @@ static void wt_status_print_filepair(struct wt_status *s,
>
> strbuf_init(&onebuf, 0);
> strbuf_init(&twobuf, 0);
> - one = quote_path(p->one->path, -1, &onebuf, s->prefix);
> - two = quote_path(p->two->path, -1, &twobuf, s->prefix);
> + one = quote_path(p->one->path, strlen(p->one->path), &onebuf, s->prefix);
> + two = quote_path(p->two->path, strlen(p->two->path), &twobuf, s->prefix);
>
> color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
> switch (p->status) {
> @@ -233,7 +233,8 @@ static void wt_status_print_initial(struct wt_status *s)
> for (i = 0; i < active_nr; i++) {
> color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
> color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
> - quote_path(active_cache[i]->name, -1,
> + quote_path(active_cache[i]->name,
> + strlen(active_cache[i]->name),
> &buf, s->prefix));
> }
> if (active_nr)
>
This patch is wrong.
If you want to go that way, move the strlen() call _into_ quote_path(),
like I had it earlier.
But then we will have a double traversal of the strings again. That's
what I tried to avoid, but I missed one place:
In line 94, it says "... && off < len && ...". This should read something
like "((len < 0 && !in[off]) || off < len)" instead. Or maybe even "(len
< 0 || off < len)" and have an "} else if (in[off]) off++; else break;" in
the loop block.
Besides, you completely ignored the nice examples how other people
contribute their patches, with mail bodies that double as a commit
message, a diffstat, and with a test case.
Hth,
Dscho
^ permalink raw reply
* Re: gitweb, updating 'last changed' column on the project page
From: Jon Smirl @ 2007-11-10 14:10 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <200711101427.18215.jnareb@gmail.com>
On 11/10/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > It is sorted by committerdate, the sort is ascending. Did you expect
> > it to be descending, pick off the last entry instead of the first?
>
> Excerpts from git-for-each-ref(1):
>
> git-for-each-ref [--count=<count>]* (...) [--sort=<key>]* (...)
>
> <count>
> By default the command shows all refs that match <pattern>. This
> option makes it stop after showing that many refs.
>
> <key> A field name to sort on. Prefix - to sort in descending order of the
> value. When unspecified, refname is used. More than one sort keys
> can be given.
>
> So I expect --sort=-committerdate to sort by date of committing,
> descending, and --count=1 pick first one, which means most recent.
git has a bug, it is not implementing the - prefix. I am using git head.
jonsmirl@terra:~$ cd mpc5200b
jonsmirl@terra:~/mpc5200b$ git for-each-ref
--format="%(refname):%09%(committer)" --sort=-committerdate refs/heads
refs/heads/m24: Jon Smirl <jonsmirl@gmail.com> 1191362799 -0400
refs/heads/m25: Jon Smirl <jonsmirl@gmail.com> 1191472422 -0400
refs/heads/m26: Jon Smirl <jonsmirl@gmail.com> 1194382038 -0500
refs/heads/m28: Jon Smirl <jonsmirl@gmail.com> 1194385071 -0500
refs/heads/m29: Jon Smirl <jonsmirl@gmail.com> 1194674673 -0500
jonsmirl@terra:~/mpc5200b$ git for-each-ref
--format="%(refname):%09%(committer)" --sort=committerdate refs/heads
refs/heads/m24: Jon Smirl <jonsmirl@gmail.com> 1191362799 -0400
refs/heads/m25: Jon Smirl <jonsmirl@gmail.com> 1191472422 -0400
refs/heads/m26: Jon Smirl <jonsmirl@gmail.com> 1194382038 -0500
refs/heads/m28: Jon Smirl <jonsmirl@gmail.com> 1194385071 -0500
refs/heads/m29: Jon Smirl <jonsmirl@gmail.com> 1194674673 -0500
jonsmirl@terra:~/mpc5200b$ git --version
git version 1.5.3.5.1651.g30bf
jonsmirl@terra:~/mpc5200b$
>
> It looks like "your" gitweb sorts ascending instead... strange...
>
>
> How does git_get_last_activity subroutine in your gitweb.cgi looks like?
> Does it have '--sort=-commiterdate'? If it has, then I think it is some
> strange bug in git, if it doesn't it is strange modification of gitweb.
>
> HTH
> --
> Jakub Narebski
> Poland
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Simplify strchrnul() compat code
From: Andreas Ericsson @ 2007-11-10 14:04 UTC (permalink / raw)
To: René Scharfe
Cc: Junio C Hamano, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Jakub Narebski
In-Reply-To: <47359C44.6090903@lsrfire.ath.cx>
René Scharfe wrote:
>
> -#ifdef NO_STRCHRNUL
> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
This will break things for users of glibc-2.1.1 (the first release still
available from ftp://sources.redhat.com/pub/glibc/old-releases that
includes the strchrnul() function), since __GLIBC_PREREQ() was invented
after strchrnul() was introduced.
Replacing __GLIBC__ with __GLIBC_PREREQ (as in the original patch) will
solve it nicely. Users of glibc-2.1.1 will be the odd minority where
strchrnul() is available in their libc but not used.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH v4] user-manual: Add section "Why bisecting merge commits can be harder ..."
From: Steffen Prohaska @ 2007-11-10 13:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Benoit Sigoure, Andreas Ericsson, Johannes Sixt, git,
Steffen Prohaska
In-Reply-To: <B622E814-D7D1-4DC8-A724-666BA0A1220F@zib.de>
This commit adds a discussion of the challenge of bisecting
merge commits to the user manual. The original author is
Junio C Hamano <gitster@pobox.com>, who posted the text to
the mailing list <http://marc.info/?l=git&m=119403257315527&w=2>.
His email was adapted for the manual.
The discussion is added to "Rewriting history and maintainig
patch series". The text added requires good understanding of
merging and rebasing. Therefore it should not be placed too
early in the manual. Right after the section on "Problems with
rewriting history", the discussion of bisect gives another reason
for linearizing as much of the history as possible.
The text includes suggestions and fixes by
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> and
Benoit Sigoure <tsuna@lrde.epita.fr>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 98 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 98 insertions(+), 0 deletions(-)
Since PATCH v3: I moved the section to chapter 5. It's not longer in a separate
section titled "Advance Topics". I split the paragraph on merge C and
reordered some sentences. I took part the paragraph on "experienced users"
from Junio's last email.
Junio, you can take ownership of the commit when applying -- if you like. Most
of the text was written by you. Just mention me as the editor in the commit
message.
Steffen
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..8ddc19f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2554,6 +2554,104 @@ branches into their own work.
For true distributed development that supports proper merging,
published branches should never be rewritten.
+[[bisect-merges]]
+Why bisecting merge commits can be harder than bisecting linear history
+-----------------------------------------------------------------------
+
+This section discusses how gitlink:git-bisect[1] plays
+with differently shaped histories. The text is based upon
+an email by Junio C. Hamano to the git mailing list
+(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://marc.info/?l=git&m=119403257315527&w=2]).
+It was adapted for the user manual.
+
+Using gitlink:git-bisect[1] on a history with merges can be
+challenging. Bisecting through merges is not a technical
+problem. The real problem is what to do when the culprit turns
+out to be a merge commit. How to spot what really is wrong, and
+figure out how to fix it. The problem is not for the tool but
+for the human, and it is real.
+
+Imagine this history:
+
+................................................
+ ---Z---o---X---...---o---A---C---D
+ \ /
+ o---o---Y---...---o---B
+................................................
+
+Suppose that on the upper development line, the meaning of one
+of the functions that existed at Z was changed at commit X. The
+commits from Z leading to A change both the function's
+implementation and all calling sites that existed at Z, as well
+as new calling sites they add, to be consistent. There is no
+bug at A.
+
+Suppose that in the meantime the lower development line somebody
+added a new calling site for that function at commit Y. The
+commits from Z leading to B all assume the old semantics of that
+function and the callers and the callee are consistent with each
+other. There is no bug at B, either.
+
+Suppose further that the two development lines were merged at C
+and there was no textual conflict with this three way merge.
+The result merged cleanly.
+
+Now, during bisect you find that the merge C is broken. You
+started to bisect, because you found D is bad and you know Z was
+good. The breakage is understandable, as at C, the new calling
+site of the function added by the lower branch is not converted
+to the new semantics, while all the other calling sites that
+already existed at Z would have been converted by the merge. The
+new calling site has semantic adjustment needed, but you do not
+know that yet.
+
+You need to find out what is the cause of the breakage by looking
+at the merge commit C and the history leading to it. How would
+you do that?
+
+Both "git diff A C" and "git diff B C" would be an enormous patch.
+Each of them essentially shows the whole change on each branch
+since they diverged. The developers may have well behaved to
+create good commits that follow the "commit small, commit often,
+commit well contained units" mantra, and each individual commit
+leading from Z to A and from Z to B may be easy to review and
+understand, but looking at these small and easily reviewable
+steps alone would not let you spot the breakage. You need to
+have a global picture of what the upper branch did (and
+among many, one of them is to change the semantics of that
+particular function) and look first at the huge "diff A C"
+(which shows the change the lower branch introduces), and see if
+that huge change is consistent with what have been done between
+Z and A.
+
+On the other hand, if you did not merge at C but rebased the
+history between Z to B on top of A, you would have get this
+linear history:
+
+................................................................
+ ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
+................................................................
+
+Bisecting between Z and D* would hit a single culprit commit Y*
+instead. This tends to be easier to understand why it is broken.
+
+For this reason, many experienced git users, even when they are
+working on an otherwise merge-heavy project, keep the histories
+linear by rebasing their work on top of public upstreams before
+publishing.
+
+But if you already made a merge C instead of rebasing, all
+is not lost. In the illustrated case, you can easily rebase
+one parent branch on top of the other after the fact, just
+to understand the history and to make the history more
+easily to bisect. Even though the published history should
+not be rewound without consent with others in the project,
+nobody gets hurt if you rebased to create alternate history
+privately. After understanding the breakage and coming up
+with a fix on top of D*, you can discard that rebased
+history, and apply the same fix on top of D, as D* and D
+should have the identical trees.
+
[[advanced-branch-management]]
Advanced branch management
==========================
--
1.5.3.5.578.g886d
^ permalink raw reply related
* Re: [PATCH] builtin-commit: fix --signoff
From: Johannes Schindelin @ 2007-11-10 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, krh
In-Reply-To: <7vr6iyo4ff.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 10 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > if (signoff) {
> > ...
> > + strbuf_init(&sob, 0);
> > + strbuf_addstr(&sob, sign_off_header);
> > + strbuf_addstr(&sob, git_committer_info(1));
> > + p = strrchr(sob.buf, '>');
> > + if (p)
> > + strbuf_setlen(&sob, p + 1 - sob.buf);
> > + strbuf_addch(&sob, '\n');
> > +
> > + for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
> > + ; /* do nothing */
> > + if (prefixcmp(sb.buf + i, sob.buf))
> > + strbuf_addbuf(&sb, &sob);
> > }
>
> At this point doesn't this leak sob.buf?
Darn. I had a "strbuf_release(&sob);" there, but at some stage removed it
by mistake.
But there is more to be fixed. Rather than let git_committer_info() add
the timestamp, only to strip it away, is a waste.
Will redo the patch.
Ciao,
Dscho
^ permalink raw reply
* Re: gitweb, updating 'last changed' column on the project page
From: Jakub Narebski @ 2007-11-10 13:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910711100505n78459612xdaa12eaa880773d8@mail.gmail.com>
Jon Smirl wrote:
> On 11/10/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Saturday, 10 November 2007, Jon Smirl wrote:
>>> On 11/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>>>
>>>> [daedalus]$ git for-each-ref --format="%(refname):%09%(committer)" \
>>>> --sort=-committerdate refs/heads
>>>> refs/heads/m24: Jon Smirl <jonsmirl@gmail.com> 1191362799 -0400
>>>> refs/heads/m25: Jon Smirl <jonsmirl@gmail.com> 1191472422 -0400
>>>> refs/heads/m26: Jon Smirl <jonsmirl@gmail.com> 1194382038 -0500
>>>> refs/heads/m28: Jon Smirl <jonsmirl@gmail.com> 1194385071 -0500
>>>> refs/heads/m29: Jon Smirl <jonsmirl@gmail.com> 1194585780 -0500
>>>
>>> It appears to be using the first head instead of the most recent date.
>>
>> It appears to not _sort_ the output by committerdate, as it should with
>> '--sort=-committerdate'.
>
> It is sorted by committerdate, the sort is ascending. Did you expect
> it to be descending, pick off the last entry instead of the first?
Excerpts from git-for-each-ref(1):
git-for-each-ref [--count=<count>]* (...) [--sort=<key>]* (...)
<count>
By default the command shows all refs that match <pattern>. This
option makes it stop after showing that many refs.
<key> A field name to sort on. Prefix - to sort in descending order of the
value. When unspecified, refname is used. More than one sort keys
can be given.
So I expect --sort=-committerdate to sort by date of committing,
descending, and --count=1 pick first one, which means most recent.
It looks like "your" gitweb sorts ascending instead... strange...
How does git_get_last_activity subroutine in your gitweb.cgi looks like?
Does it have '--sort=-commiterdate'? If it has, then I think it is some
strange bug in git, if it doesn't it is strange modification of gitweb.
HTH
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] builtin-commit: fix --signoff
From: Pierre Habouzit @ 2007-11-10 13:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, krh
In-Reply-To: <7vr6iyo4ff.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
On Sat, Nov 10, 2007 at 09:06:28AM +0000, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > if (signoff) {
> > ...
> > + strbuf_init(&sob, 0);
> > + strbuf_addstr(&sob, sign_off_header);
> > + strbuf_addstr(&sob, git_committer_info(1));
> > + p = strrchr(sob.buf, '>');
> > + if (p)
> > + strbuf_setlen(&sob, p + 1 - sob.buf);
> > + strbuf_addch(&sob, '\n');
> > +
> > + for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
> > + ; /* do nothing */
> > + if (prefixcmp(sb.buf + i, sob.buf))
> > + strbuf_addbuf(&sb, &sob);
> > }
>
> At this point doesn't this leak sob.buf?
It does, strbuf_addbuf copies `sob` but doesn't release resources.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Pierre Habouzit @ 2007-11-10 13:13 UTC (permalink / raw)
To: Carlos Rica; +Cc: Junio C Hamano, git
In-Reply-To: <1b46aba20711100425o2f351ac5o81537adc6f09dc80@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]
On Sat, Nov 10, 2007 at 12:25:44PM +0000, Carlos Rica wrote:
> 2007/11/10, Junio C Hamano <gitster@pobox.com>:
> > Carlos Rica <jasampler@gmail.com> writes:
> A solution not needing memory allocation into the option parser
> could be setting a callback running over the repeated option
> arguments, passing them to the function one per each call.
> Then, the user will be able to decide if he wants the arguments
> concatenated or only need one of them and prefers erroring out.
>
> Is this already possible with the current parser or the callback
> mode only calls using the last option?
Everything is possible, you just have to code it. With a callback
you have in the struct option two places to store "things". The void*
value pointer and the intptr_t defval. _Usually_ the void* is the
pointer to the data that will be _written_ and the defval the data that
will be put into the void* under some circumstances (e.g. when your
option is negated).
For Your case I'd go with some kind of string list pointed into the
void * value, defval has no or little use. You don't really care about
allocating memory in the option parser, I mean, option parsing is done
once at the initialization phase. It's not evil. In pseudo-C here is how
I would write the callback:
int parse_opt_stringlist(const struct option *opt, const char *arg, int unset)
{
string_list **l = opt->value;
string_list_elem *e;
if (unset) { /* negationg option clears the list */
while (*l) {
string_list_elem_free(string_list_pop(l));
}
return 0;
}
e = string_list_elem_new();
e->data = arg;
string_list_push(l, e);
return 0;
}
And you're done, you can do what you want with that list from the caller.
There probably is such a structure in git, if not, it can probably be hacked
in a few lines.
Remember, callbacks give you _full_ control on what you can do in the option
parser, and if you're not happy with Turing complete expressivity, there isn't
anything I can do for you :P Note that if you do write such a generic
callback, it belongs to parse-options.[hc].
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: gitweb, updating 'last changed' column on the project page
From: Jon Smirl @ 2007-11-10 13:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711101034.47861.jnareb@gmail.com>
On 11/10/07, Jakub Narebski <jnareb@gmail.com> wrote:
> On Saturday, 10 November 2007, Jon Smirl wrote:
> > On 11/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 11/9/07, Jakub Narebski <jnareb@gmail.com> wrote:
> >>> Jon Smirl wrote:
> >>>
> >>>> At http://git.digispeaker.com/ the 'last change' column is not getting updated.
> >>>>
> >>>> mpc5200b.git
> >>>> DigiSpeaker for Freescale MPC5200B.
> >>>> Jon Smirl
> >>>> 5 weeks ago
> >>>> summary | shortlog | log | tree
> >>>>
> >>>> It still says 5 weeks ago, but if I click on the project last change is today.
> >>>>
> >>>> What controls this? I tried running update-server-info
> >>>
> >>> What does
> >>>
> >>> git for-each-ref --format="%(refname):%09%(committer)" --sort=-committerdate
> >>> refs/heads
> >>
> >> [daedalus]$ git for-each-ref --format="%(refname):%09%(committer)" \
> >> --sort=-committerdate refs/heads
> >> refs/heads/m24: Jon Smirl <jonsmirl@gmail.com> 1191362799 -0400
> >> refs/heads/m25: Jon Smirl <jonsmirl@gmail.com> 1191472422 -0400
> >> refs/heads/m26: Jon Smirl <jonsmirl@gmail.com> 1194382038 -0500
> >> refs/heads/m28: Jon Smirl <jonsmirl@gmail.com> 1194385071 -0500
> >> refs/heads/m29: Jon Smirl <jonsmirl@gmail.com> 1194585780 -0500
> >
> > It appears to be using the first head instead of the most recent date.
> It appears to not _sort_ the output by committerdate, as it should with
> '--sort=-committerdate'.
It is sorted by committerdate, the sort is ascending. Did you expect
it to be descending, pick off the last entry instead of the first?
>
> 1442:[gitweb/web!git]$ git for-each-ref --format="%(refname):%09%(committer)" \
> --sort=-committerdate refs/heads
> refs/heads/gitweb/web: Jakub Narebski <jnareb@gmail.com> 1194616779 +0100
> refs/heads/man: Junio C Hamano <junio@hera.kernel.org> 1194602628 +0000
> refs/heads/html: Junio C Hamano <junio@hera.kernel.org> 1194602626 +0000
> refs/heads/origin: Junio C Hamano <gitster@pobox.com> 1194602274 -0800
> [...]
> refs/heads/gitweb-snapshot+navbar: Sven Verdoolaege <skimo@kotnet.org> 1134765981 +0100
>
> 1443:[gitweb/web!git]$ git --version
> git version 1.5.3.5
>
>
> Note that git-for-each-ref with those options returns most recent head
> first, sorting output by date of commit (date of adding to repository)
>
> >>>
> >>> return? Does adding --count select proper branch, with proper update
> >>> date?
> >>
> >> Is it looking for master, and just picking the first branch instead?
>
> Gitweb should not (and I think does not) have 'master' hardcoded
> anywhere. It might use HEAD in some cases you don't want it to...
>
> >>>
> >>> Which gitweb version is this?
> >>
> >> <!-- git web interface version 1.5.3.5.605.g79fa-dirty, (C) 2005-2006,
> >> Kay Sievers <kay.sievers@vrfy.org>, Christian Gierke -->
> >> <!-- git core binaries version 1.5.3.5.605.g79fa-dirty -->
>
> Older version of gitweb used HEAD branch for'last changed' info on
> the projects list page. That is why I asked about gitweb version.
>
> But this is not the case of your problem:
> 1. Your gitweb is new enough to use git-for-each-ref. It use
> git for-each-ref --format="%(committer)" --sort=-committerdate
> --count=1 refs/heads
> 2. Looking at 'heads' view (or 'heads' part of summary view) one can see
> that m29 is current branch (HEAD), and it is most recent.
>
> Strange...
> --
> Jakub Narebski
> Poland
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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