* Re: [PATCH 3/4] pathspec: apply "*.c" optimization from exclude
From: Nguyen Thai Ngoc Duy @ 2012-11-20 13:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtxsluw3k.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 4:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> $ time git rev-list --quiet HEAD -- '*.c'
>>
>> real 0m40.770s
>> user 0m40.290s
>> sys 0m0.256s
>>
>> With the patch
>>
>> $ time ~/w/git/git rev-list --quiet HEAD -- '*.c'
>>
>> real 0m34.288s
>> user 0m33.997s
>> sys 0m0.205s
>>
>> The above command is not supposed to be widely popular.
>
> Hrm, perhaps. I use "git grep <pattern> -- \*.c" quite a lot, but
> haven't seen use case for \*.c in the context of the "log" family.
"git diff *.c" is also helpful (maybe "git diff *.[ch]" is more often
used). But I suspect I/O dominates in both grep and diff cases. I just
try to make sure matching code won't show up in profile.
>> +#define PSF_ONESTAR 1
>
> Together with the GF_ prefix in the previous, PSF_ prefix needs a
> bit of in-code explanation. Is it just an RC3L (random combination
> of 3 letters?)
I'm pretty sure "PS" stands for pathspec. "F" is probably from
fnmatch. Any suggestions?
>> @@ -46,6 +46,12 @@ inline int git_fnmatch(const char *pattern, const char *string,
>> pattern += prefix;
>> string += prefix;
>> }
>> + if (flags & GF_ONESTAR) {
>> + int pattern_len = strlen(++pattern);
>> + int string_len = strlen(string);
>> + return strcmp(pattern,
>> + string + string_len - pattern_len);
>> + }
>
> What happens when pattern="foo*oob" and string="foob"?
>
> The prefix match before this code determines that the literal prefix
> in the pattern matches with the early part of the string, and makes
> pattern="*oob" and string="b".
>
> When you come to strcmp(), you see that string_len is 1, pattern_len
> is 3, and pattern is "oob". string+string_len-pattern_len = "oob",
> one past the beginning of the original string "foob". They match.
>
> Oops?
Oops indead. I'll need to check exclude code too :(
> return (string_len < pattern_len) ||
> strcmp(pattern, string + string_len - pattern_len);
>
> perhaps?
Yeah.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/4] pathspec: do exact comparison on the leading non-wildcard part
From: Nguyen Thai Ngoc Duy @ 2012-11-20 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk2duw3m.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 3:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> How would we protect this optimization from future breakages?
>
> Once we start using FNM_PERIOD, this becomes unsafe, as the simple
> part in "foo/bar*baz" would be "foo/bar" with remainder "*baz".
>
> The pattern "foo/bar*baz" should match "foo/bar.baz" with FNM_PERIOD
> set. But with this optimization, fnmatch is fed pattern="*baz",
> string=".baz" and they would not match.
The first question is how FNM_PERIOD comes in the first place without
breaking the current syntax. I guess we just turn off the optimization
if FNM_PERIOD is used.
My secret "plan" is to convert all fnmatch() calls to git_fnmatch()
then replace fnmatch() with wildmatch() and move these optimization
down to wildmatch(). I think we can handle FNM_PERIOD case better down
there because string is still "foo/bar.baz".
--
Duy
^ permalink raw reply
* [PATCH] git-send-email: don't return undefined value in extract_valid_address()
From: Krzysztof Mazur @ 2012-11-20 12:20 UTC (permalink / raw)
To: git; +Cc: Krzysztof Mazur
In the fallback check, when Email::Valid is not available, the
extract_valid_address() does not check for success of matching regex,
and $1, which can be undefined, is always returned. Now if match
fails an empty string is returned.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
This fixes following warnings:
Use of uninitialized value in string eq at ./git-send-email.perl line 1017.
Use of uninitialized value in quotemeta at ./git-send-email.perl line 1017.
W: unable to extract a valid address from: x a.patch
when invalid email address was added by --cc-cmd,
./git-send-email.perl --dry-run --to a@podlesie.net --cc-cmd=echo x a.patch
git-send-email.perl | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..045f25f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -831,12 +831,12 @@ sub extract_valid_address {
$address =~ s/^\s*<(.*)>\s*$/$1/;
if ($have_email_valid) {
return scalar Email::Valid->address($address);
- } else {
- # less robust/correct than the monster regexp in Email::Valid,
- # but still does a 99% job, and one less dependency
- $address =~ /($local_part_regexp\@$domain_regexp)/;
- return $1;
}
+
+ # less robust/correct than the monster regexp in Email::Valid,
+ # but still does a 99% job, and one less dependency
+ return $1 if $address =~ /($local_part_regexp\@$domain_regexp)/;
+ return "";
}
# Usually don't need to change anything below here.
--
1.8.0.283.gc57d856
^ permalink raw reply related
* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-20 12:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Heiko Voigt, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7v1ufou92h.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]
On Mon, Nov 19, 2012 at 09:39:34PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
> >> "W. Trevor King" <wking@tremily.us> writes:
> >> ...
> >> > I think it's best to have users craft their own commit messages
> >> > explaining why the branch was updated. That said, an auto-generated
> >> > hint (a la "git merge") would probably be a useful extra feature.
> >>
> >> I am not quite sure I agree. When the project says "Use the tip of
> >> 'bar' branch for the submodule 'foo'" at the top-level, does an
> >> individual user who is not working on the submodule 'foo' but merely
> >> is using it have any clue as to why the submodule's 'foo' branch
> >> 'foo' moved, or does he necessarily even care?
> >
> > If he doesn't care, why is he updating the submodule gitlink?
>
> He may not be updating the gitlink with "git add foo" at the
> top-level superproject level. He is just using that submodule as
> part of the larger whole as he is working on either the top-level or
> some other submodule. And checkout of 'foo' is necessary in the
> working tree for him to work in the larger context of the project,
> and 'foo' is set to float at the tip of its 'bar' branch. And that
> checkout results in a commit that is different from the commit the
> gitlink suggests, perhaps because somebody worked in 'foo' submodule
> and advanced the tip of branch 'bar'.
The superproject gitlink should only be updated after
$ git submodule update --pull
A plain
$ git submodule update
would still checkout the previously-recorded SHA, not the new upstream
tip. The uncaring user should skip the "--pull", and there will be no
superproject changes to worry about.
> Or are you envisioning that such a check-out will and should show a
> local difference at the submodule 'foo' by leaving the index of the
> top-level superproject unchanged,
A plain "git submodule update" will, yes. And this will clobber any
changes that have happened in the submodule directory and its index
(because the user explicitly asked to checkout the
superproject-recorded SHA)
> and the user should refrain from using "git commit -a" to avoid
> having to describe the changes made on the 'bar' branch in the
> meantime in his top-level commit?
What would "git commit -a" be picking up? Nothing in the superproject
has changed?
> That is certainly fine by me (I am no a heavy submodule user to
> begin with), but I am not sure if that is useful and helpful to the
> submodule users.
The benefit is that Ævar's
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
becomes
$ git submodule update --pull
Still an explicit pull, but much easier to remember.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: RFC: Making submodules "track" branches
From: W. Trevor King @ 2012-11-20 12:04 UTC (permalink / raw)
To: nottrobin; +Cc: git
In-Reply-To: <1353410195055-7571610.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
On Tue, Nov 20, 2012 at 03:16:35AM -0800, nottrobin wrote:
> Did any of this ever find its way into the submodule core? I'd like
> to have a submodule that tracks a branch.
In progress. See:
http://thread.gmane.org/gmane.comp.version-control.git/208254
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-20 11:59 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <CAMP44s38gTB_3Ao1rFZgMo2EAuiNb+h88-qRFcQPRMJNxo3CAQ@mail.gmail.com>
On Tue, Nov 20, 2012 at 11:28:39AM +0100, Felipe Contreras wrote:
> On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
>
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -925,8 +925,11 @@ sub quote_subject {
> > sub sanitize_address {
> > my ($recipient) = @_;
> >
> > + my $local_part_regexp = qr/[^<>"\s@]+/;
> > + my $domain_regexp = qr/[^.<>"\s@]+(?:\.[^.<>"\s@]+)+/;
> > +
> > # remove garbage after email address
> > - $recipient =~ s/(.*>).*$/$1/;
> > + $recipient =~ s/^(.*?<$local_part_regexp\@$domain_regexp>).*/$1/;
>
> I don't think all that extra complexity is warranted, to me
> s/(.*?>)(.*)$/$1/ is just fine.
>
Yeah, it's a little bit too complex, but "s/(.*?>)(.*)$/$1/"
causes small regression - '>' character is no longer allowed
in "phrase" before "<email address>". Maybe the initial version,
that removes everything after last '>' is better? In this case '>'
is not allowed in garbage after email.
Krzysiek
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #06; Mon, 19)
From: Paul Fox @ 2012-11-20 11:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpq39up0m.fsf@alter.siamese.dyndns.org>
junio c hamano wrote:
> [Stalled]
>
> * pf/editor-ignore-sigint (2012-11-11) 5 commits
> - launch_editor: propagate SIGINT from editor to git
> - run-command: do not warn about child death by SIGINT
> - run-command: drop silent_exec_failure arg from wait_or_whine
> - launch_editor: ignore SIGINT while the editor has control
> - launch_editor: refactor to use start/finish_command
>
> Avoid confusing cases where the user hits Ctrl-C while in the editor
> session, not realizing git will receive the signal. Since most editors
> will take over the terminal and will block SIGINT, this is not likely
> to confuse anyone.
>
> Some people raised issues with emacsclient, which are addressed by this
> re-roll. It should probably also handle SIGQUIT, and there were a
> handful of other review comments.
>
> Expecting a re-roll.
i don't have strong feelings on any of the later review comments
(though i guess the check on finish_command()'s return code needed
attention), and wasn't the last submitter, but would certainly like to
see this move forward.
paul
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 26.1 degrees)
^ permalink raw reply
* Re: Auto-repo-repair
From: Drew Northup @ 2012-11-20 11:56 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeff King, git
In-Reply-To: <fd162e10-46a8-433c-80b2-c1c4185c2032@zcs>
On Mon, Nov 19, 2012 at 5:35 PM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
>
>> >> How would the broken repository be sure of what it is missing to
>> >> request it from the other side?
>> >
>> > fsck will find missing objects.
>>
>> And what about the objects referred to by objects that are missing?
>
> Will be fetched after multiple iterations.
> We could even introduce some 'fsck --autorepair' mode, which triggers
> it to fetch any missing object from its remotes.
>
> Maybe even introduce a concept of peer object stores, which (a bit like
> alternates) are asked for objects that arent locally availabe - that
> could be even a plain venti store.
I still think that it would make the most sense to do the following
(if you insist on some sort of automated repair):
(1) Fetch a "good" clone (or clones) into a temporary directory;
(2) Cannibalize the objects from it (them);
(3) Re-run git fsck and check for still-missing / unreachable items;
(4) IF THE RESULT OF (3) IS ACCEPTABLE, run git gc to clean up the
mess, discard / "merge" duplicate objects, and fix up the packfiles.
It is step (4) that requires the most user interaction. I could see
building up a shell script that does all but (4) nearly automatically.
None of this requires modifying Git itself.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Crash when pushing large binary file
From: Nguyen Thai Ngoc Duy @ 2012-11-20 11:37 UTC (permalink / raw)
To: Thomas Gay; +Cc: Git Mailing List
In-Reply-To: <CA+AoP-n=P3-yTshfQRwdyUcb7eFM12-+bAtS_FUAxXtwuFxjzg@mail.gmail.com>
On Tue, Nov 20, 2012 at 8:50 AM, Thomas Gay <tgay@tokyois.com> wrote:
> Sorry for the late reply; I've been out of the office for the past few days.
>
> On Fri, Nov 16, 2012 at 7:11 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> If it still says "unpack-objects died of signal 11" then it was not
>> done the right way.
>
> I upgraded Git on both ends and tried setting it again. index-pack was
> used this time, but it still failed:
>
> Counting objects: 38, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (26/26), done.
> error: index-pack died of signal 11 GiB | 62.44 MiB/s
> error: pack-objects died of signal 13
> error: failed to push some refs to '...'
>
> Would you still like me to try your other method?
Interesting. No, if index-pack fails too the culprit is something
else. Does the stack trace look the same (i.e. crashed in
write_sha1_file_prepare)? I still don't know how it crashes there.
It'd be great if you could run it under valgrind (not sure if valgrind
runs in OS X). Try building with NO_OPENSSL too to avoid external sha1
issues.
--
Duy
^ permalink raw reply
* Re: RFC: Making submodules "track" branches
From: nottrobin @ 2012-11-20 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTiknGcteTjrHWM02H2KOMMDPZKHY1w0ZOIswddFn@mail.gmail.com>
Did any of this ever find its way into the submodule core? I'd like to have a
submodule that tracks a branch.
--
View this message in context: http://git.661346.n2.nabble.com/RFC-Making-submodules-track-branches-tp5151566p7571610.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Andreas Ericsson @ 2012-11-20 11:08 UTC (permalink / raw)
To: Felipe Contreras
Cc: Krzysztof Mazur, Junio C Hamano, Felipe Balbi, git,
Tomi Valkeinen
In-Reply-To: <CAMP44s38gTB_3Ao1rFZgMo2EAuiNb+h88-qRFcQPRMJNxo3CAQ@mail.gmail.com>
On 11/20/2012 11:28 AM, Felipe Contreras wrote:
> On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
>
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -925,8 +925,11 @@ sub quote_subject {
>> sub sanitize_address {
>> my ($recipient) = @_;
>>
>> + my $local_part_regexp = qr/[^<>"\s@]+/;
>> + my $domain_regexp = qr/[^.<>"\s@]+(?:\.[^.<>"\s@]+)+/;
>> +
>> # remove garbage after email address
>> - $recipient =~ s/(.*>).*$/$1/;
>> + $recipient =~ s/^(.*?<$local_part_regexp\@$domain_regexp>).*/$1/;
>
> I don't think all that extra complexity is warranted, to me
> s/(.*?>)(.*)$/$1/ is just fine.
>
It's intentionally left without the at-sign so one can send mail to a
local account as well as remote ones. Very nifty when debugging, and
when one wants to preview outgoing emails.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Felipe Contreras @ 2012-11-20 10:28 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Junio C Hamano, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <20121120075628.GA7159@shrek.podlesie.net>
On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -925,8 +925,11 @@ sub quote_subject {
> sub sanitize_address {
> my ($recipient) = @_;
>
> + my $local_part_regexp = qr/[^<>"\s@]+/;
> + my $domain_regexp = qr/[^.<>"\s@]+(?:\.[^.<>"\s@]+)+/;
> +
> # remove garbage after email address
> - $recipient =~ s/(.*>).*$/$1/;
> + $recipient =~ s/^(.*?<$local_part_regexp\@$domain_regexp>).*/$1/;
I don't think all that extra complexity is warranted, to me
s/(.*?>)(.*)$/$1/ is just fine.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Fix typo in 1.8.1 release notes
From: Alexey Molchanov @ 2012-11-20 10:03 UTC (permalink / raw)
To: git
Fix typo in documentation
Signed-off-by: Alexey Molchanov <alexey.molchanov@portaone.com>
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 107e5f3..559cd05 100644
--- a/Documentation/RelNotes/1.8.1.txt
+++ b/Documentation/RelNotes/1.8.1.txt
@@ -36,7 +36,7 @@ UI, Workflows & Features
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
- * "git format-patch" leraned the "--notes=<ref>" option to give
+ * "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
--
1.7.11.2
^ permalink raw reply related
* gitk: Portuguese "Ignore space change" translation
From: Joao Vitor P. Moraes @ 2012-11-20 10:03 UTC (permalink / raw)
To: git
Inside gitk there's a checkbox which says:
Ignore space change
It was translated to portuguese (pt-br) as:
Ignorar mudanças de caixa
But that message in portuguese means:
Ignore case changes
that checkbox does not ignore case changes, but instead it ignores space
changes, a better translation would be
Ignorar mudanças de espaço
or
Ignorar espaçamentos
or
Ignorar espaços
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Felipe Balbi @ 2012-11-20 7:54 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Junio C Hamano, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <20121119225838.GA23412@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
On Mon, Nov 19, 2012 at 11:58:38PM +0100, Krzysztof Mazur wrote:
> On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
> > Given that the problematic line
> >
> > Stable Kernel Maintainance Track <stable@vger.kernel.org> # vX.Y
> >
> > is not even a valid e-mail address, doesn't this new logic belong to
> > sanitize_address() conceptually?
>
> Yes, it's much better to do it in the sanitize_address().
>
> Felipe, may you check it?
>
> Krzysiek
> -- >8 --
> Subject: [PATCH] git-send-email: remove garbage after email address
>
> In some cases it's very useful to add some additional information
> after email in Cc-list, for instance:
>
> "Cc: Stable kernel <stable@vger.kernel.org> #v3.4 v3.5 v3.6"
>
> Currently the git refuses to add such invalid email to Cc-list,
> when the Email::Valid perl module is available or just uses whole line
> as the email address.
>
> Now in sanitize_address() everything after the email address is
> removed, so the resulting line is correct email address and Email::Valid
> validates it correctly.
>
> Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Tested-by: Felipe Balbi <balbi@ti.com>
> ---
> git-send-email.perl | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 5a7c29d..9840d0a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -924,6 +924,10 @@ sub quote_subject {
> # use the simplest quoting being able to handle the recipient
> sub sanitize_address {
> my ($recipient) = @_;
> +
> + # remove garbage after email address
> + $recipient =~ s/(.*>).*$/$1/;
> +
> my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
>
> if (not $recipient_name) {
> --
> 1.8.0.283.gc57d856
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-20 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <20121120073100.GB7206@shrek.podlesie.net>
On Tue, Nov 20, 2012 at 08:31:00AM +0100, Krzysztof Mazur wrote:
> On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> > > On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> > >
> > >> --- a/git-send-email.perl
> > >> +++ b/git-send-email.perl
> > >> @@ -924,6 +924,10 @@ sub quote_subject {
> > >> # use the simplest quoting being able to handle the recipient
> > >> sub sanitize_address {
> > >> my ($recipient) = @_;
> > >> +
> > >> + # remove garbage after email address
> > >> + $recipient =~ s/(.*>).*$/$1/;
> > >> +
> > >
> > > Looks fine, but I would do s/(.*?>)(.*)$/$1/, so that 'test
> > > <foo@bar.com> <#comment>' gets the second comment removed.
> >
> > Yeah, but do you need to capture the second group? IOW, like
> > "s/(.*?>).*$/$1/" perhaps?
>
> I also thought about removing everything after first ">", but I will
> not work for addresses like:
>
> Cc: "foo >" <stable@vger.kernel.org> #v3.4 v3.5 v3.6
>
> What about:
>
> $recipient =~ s/(.*<[^@]*@[^]]*>).*$/$1/;
>
> or even
>
> which uses regex used by 99% accurate version of extract_valid_address().
>
Of course, as you suggested earier, only the first email address should
be used, so in both cases the first ".*" should be changed to ".*?".
The second version becomes:
diff --git a/git-send-email.perl b/git-send-email.perl
index 9840d0a..dbe520c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -925,8 +925,11 @@ sub quote_subject {
sub sanitize_address {
my ($recipient) = @_;
+ my $local_part_regexp = qr/[^<>"\s@]+/;
+ my $domain_regexp = qr/[^.<>"\s@]+(?:\.[^.<>"\s@]+)+/;
+
# remove garbage after email address
- $recipient =~ s/(.*>).*$/$1/;
+ $recipient =~ s/^(.*?<$local_part_regexp\@$domain_regexp>).*/$1/;
my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
Krzysiek
^ permalink raw reply related
* git-svn: What is --follow-parent / --no-follow-parent for?
From: Sebastian Leske @ 2012-11-20 7:31 UTC (permalink / raw)
To: git
Hi,
on reading the docs of "git-svn", I stumbled across this paragraph:
> --follow-parent
> This is especially helpful when we’re tracking a directory that has been
> moved around within the repository, or if we started tracking a branch
> and never tracked the trunk it was descended from. This feature is
> enabled by default, use --no-follow-parent to disable it.
However, this does not make sense to me: This sounds like there is no
good reason *not* to enable this option. So why is it there? And in
what situation might I want to use "--no-follow-parent"?
As a matter of fact, I'm not even sure what "--no-follow-parent" does
(and the docs don't really say).
I tried it out with a small test repo with a single branch (produced by
copying the trunk, then later deleted). With --follow-parent git-svn
correctly detected the branch point, and modeled the branch deletion as
a merge. With --no-follow-parent it just acted as if branch and trunk
were completely unrelated.
Commit graph of git-svn result:
--follow-parent: --no-follow-parent:
| |
/| | |
/ | | |
| | | |
| | | |
| | | |
\ | | |
\| | |
| |
(please excuse cheap ASCII art)
Is that the only effect of --no-follow-parent? And again, why would I
want that?
I'd be grateful for any clarifications. If I manage to understand the
explanation, I'll volunteer to summarize it into doc patch (if there are
no objections).
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-20 7:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <7vlidxuowf.fsf@alter.siamese.dyndns.org>
On Mon, Nov 19, 2012 at 03:57:36PM -0800, Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > On Mon, Nov 19, 2012 at 11:58 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> >
> >> --- a/git-send-email.perl
> >> +++ b/git-send-email.perl
> >> @@ -924,6 +924,10 @@ sub quote_subject {
> >> # use the simplest quoting being able to handle the recipient
> >> sub sanitize_address {
> >> my ($recipient) = @_;
> >> +
> >> + # remove garbage after email address
> >> + $recipient =~ s/(.*>).*$/$1/;
> >> +
> >
> > Looks fine, but I would do s/(.*?>)(.*)$/$1/, so that 'test
> > <foo@bar.com> <#comment>' gets the second comment removed.
>
> Yeah, but do you need to capture the second group? IOW, like
> "s/(.*?>).*$/$1/" perhaps?
I also thought about removing everything after first ">", but I will
not work for addresses like:
Cc: "foo >" <stable@vger.kernel.org> #v3.4 v3.5 v3.6
What about:
$recipient =~ s/(.*<[^@]*@[^]]*>).*$/$1/;
or even
diff --git a/git-send-email.perl b/git-send-email.perl
index 9840d0a..b988c57 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -925,8 +925,11 @@ sub quote_subject {
sub sanitize_address {
my ($recipient) = @_;
+ my $local_part_regexp = qr/[^<>"\s@]+/;
+ my $domain_regexp = qr/[^.<>"\s@]+(?:\.[^.<>"\s@]+)+/;
+
# remove garbage after email address
- $recipient =~ s/(.*>).*$/$1/;
+ $recipient =~ s/(.*<$local_part_regexp\@$domain_regexp>).*$/$1/;
my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
which uses regex used by 99% accurate version of extract_valid_address().
Krzysiek
^ permalink raw reply related
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-20 7:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <7vhaoluos6.fsf@alter.siamese.dyndns.org>
On Mon, Nov 19, 2012 at 04:00:09PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
> > On Mon, Nov 19, 2012 at 11:27:45AM -0800, Junio C Hamano wrote:
> >> Given that the problematic line
> >>
> >> Stable Kernel Maintainance Track <stable@vger.kernel.org> # vX.Y
> >>
> >> is not even a valid e-mail address, doesn't this new logic belong to
> >> sanitize_address() conceptually?
> >
> > Yes, it's much better to do it in the sanitize_address().
>
> Note that I did not check that all the addresses that are handled by
> extract-valid-address came through sanitize-address function, so
Before sending that patch, I checked that and tested with and without
Email::Valid.
> unlike your original patch, this change alone may still pass some
> garbage to Email::Valid->address(). I tend to think that is a
> progress; we should make sure all the addresses are sanitized before
> using them for sending messages out.
I will try to check that.
Krzysiek
^ permalink raw reply
* Re: [PATCH 15/13] compat/fnmatch: fix off-by-one character class's length check
From: Johannes Sixt @ 2012-11-20 7:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1352628837-5784-2-git-send-email-pclouds@gmail.com>
Am 11/11/2012 11:13, schrieb Nguyễn Thái Ngọc Duy:
> Character class "xdigit" is the only one that hits 6 character limit
> defined by CHAR_CLASS_MAX_LENGTH. All other character classes are 5
> character long and therefore never caught by this.
>
> This should make xdigit tests in t3070 pass on Windows.
>
> Reported-by: Johannes Sixt <j6t@kdbg.org>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I tested with Linux (removing the ifdef __LIBC in fnmatch.c) but I
> think this should get an ACK from someone who actually uses it on
> Windows.
Works well here on Windows.
This does not affect Windows alone, but all platforms that fall back to
compat/fnmatch. It's perhaps worth its own topic branch.
> We may want to tell upstream (who?) about this if they haven't fixed
> it already.
>
> compat/fnmatch/fnmatch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
> index 9473aed..0ff1d27 100644
> --- a/compat/fnmatch/fnmatch.c
> +++ b/compat/fnmatch/fnmatch.c
> @@ -345,7 +345,7 @@ internal_fnmatch (pattern, string, no_leading_period, flags)
>
> for (;;)
> {
> - if (c1 == CHAR_CLASS_MAX_LENGTH)
> + if (c1 > CHAR_CLASS_MAX_LENGTH)
> /* The name is too long and therefore the pattern
> is ill-formed. */
> return FNM_NOMATCH;
>
-- Hannes
^ permalink raw reply
* [PATCH 14/13] test-wildmatch: avoid Windows path mangling
From: Johannes Sixt @ 2012-11-20 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vvcdco1pf.fsf@alter.siamese.dyndns.org>
From: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The MSYS bash mangles arguments that begin with a forward slash
when they are passed to test-wildmatch. This causes tests to fail.
Avoid mangling by prepending "XXX", which is removed by
test-wildmatch before further processing.
[J6t: reworded commit message]
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Works well, and I'm fine with this work-around.
-- Hannes
t/t3070-wildmatch.sh | 10 +++++-----
test-wildmatch.c | 8 ++++++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index e6ad6f4..3155eab 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -74,7 +74,7 @@ match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 0 'foo' '**/foo'
-match 1 x '/foo' '**/foo'
+match 1 x 'XXX/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
match 0 0 'foo/bar/baz' '**/bar*'
@@ -95,8 +95,8 @@ match 0 0 ']' '[!]-]'
match 1 x 'a' '[!]-]'
match 0 0 '' '\'
match 0 x '\' '\'
-match 0 x '/\' '*/\'
-match 1 x '/\' '*/\\'
+match 0 x 'XXX/\' '*/\'
+match 1 x 'XXX/\' '*/\\'
match 1 1 'foo' 'foo'
match 1 1 '@foo' '@foo'
match 0 0 'foo' '@foo'
@@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 74c0864..e384c8e 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -3,6 +3,14 @@
int main(int argc, char **argv)
{
+ int i;
+ for (i = 2; i < argc; i++) {
+ if (argv[i][0] == '/')
+ die("Forward slash is not allowed at the beginning of the\n"
+ "pattern because Windows does not like it. Use `XXX/' instead.");
+ else if (!strncmp(argv[i], "XXX/", 4))
+ argv[i] += 3;
+ }
if (!strcmp(argv[1], "wildmatch"))
return !!wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], "iwildmatch"))
^ permalink raw reply related
* Re: [PATCH v4.1 5/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-20 5:44 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <CAEUsAPa9fiF9cuMqRHNsQSz_CsbbvdO-eGDS9HWW3MrAYZPA8w@mail.gmail.com>
Chris Rorvick <chris@rorvick.com> writes:
> On Mon, Nov 19, 2012 at 2:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Yeah, this was one of a few stupid mistakes. Previously I used
> 'forwardable' throughout, but that is awkward except in the last
> commit since until then everything is allowed to fast-forward and the
> flag is only used to output tag-specific advice. But inverting the
> meaning of the flag is dumb, and I didn't even do it right.
>
> But, as I think you're suggesting, it probably makes more sense to use
> a flag that prevents fast-forwarding when set. So maybe
> "not_forwardable", or "is_a_tag" => "not_forwardable" if you think the
> renaming is a good idea.
Yeah, calling it not-forwardable from the beginning would be a
sensible approach, I would think.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Junio C Hamano @ 2012-11-20 5:39 UTC (permalink / raw)
To: W. Trevor King
Cc: Heiko Voigt, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121120011628.GD321@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
>> "W. Trevor King" <wking@tremily.us> writes:
>> ...
>> > I think it's best to have users craft their own commit messages
>> > explaining why the branch was updated. That said, an auto-generated
>> > hint (a la "git merge") would probably be a useful extra feature.
>>
>> I am not quite sure I agree. When the project says "Use the tip of
>> 'bar' branch for the submodule 'foo'" at the top-level, does an
>> individual user who is not working on the submodule 'foo' but merely
>> is using it have any clue as to why the submodule's 'foo' branch
>> 'foo' moved, or does he necessarily even care?
>
> If he doesn't care, why is he updating the submodule gitlink?
He may not be updating the gitlink with "git add foo" at the
top-level superproject level. He is just using that submodule as
part of the larger whole as he is working on either the top-level or
some other submodule. And checkout of 'foo' is necessary in the
working tree for him to work in the larger context of the project,
and 'foo' is set to float at the tip of its 'bar' branch. And that
checkout results in a commit that is different from the commit the
gitlink suggests, perhaps because somebody worked in 'foo' submodule
and advanced the tip of branch 'bar'.
So:
- at the top-level superproject level, entry 'foo' in the HEAD tree
points at an older commit;
- 'foo/.git/HEAD' points at refs/heads/bar, which matches the
working tree of 'foo' and the index foo/.git/index..
I am not sure what should happen to the entry 'foo' in the index of
the top-level superproject after such a 'submodule floats at the
tip' checkout, but I imagine that it must match the contents of
foo/.git/HEAD's tree. Otherwise, "git diff" at the top-level would
report local changes.
When committing his work at the top-level, he will see that 'foo'
gitlink is updated in that commit; after all that combination is the
context in which his work was done.
Or are you envisioning that such a check-out will and should show a
local difference at the submodule 'foo' by leaving the index of the
top-level superproject unchanged, and the user should refrain from
using "git commit -a" to avoid having to describe the changes made
on the 'bar' branch in the meantime in his top-level commit? That
is certainly fine by me (I am no a heavy submodule user to begin
with), but I am not sure if that is useful and helpful to the
submodule users.
^ permalink raw reply
* Re: [PATCH v4.1 5/5] push: update remote tags only with force
From: Chris Rorvick @ 2012-11-20 4:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7va9udxryf.fsf@alter.siamese.dyndns.org>
On Mon, Nov 19, 2012 at 2:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>> The object referenced by <src> is used to update the <dst> reference
>> -on the remote side, but by default this is only allowed if the
>> -update can fast-forward <dst>. By having the optional leading `+`,
>> -you can tell git to update the <dst> ref even when the update is not a
>> -fast-forward. This does *not* attempt to merge <src> into <dst>. See
>> -EXAMPLES below for details.
>> +on the remote side. By default this is only allowed if the update is
>> +a branch, and then only if it can fast-forward <dst>. By having the
>
> I can already see the next person asking "I can update refs/notes
> the same way. The doc says it applies only to the branches. Is
> this a bug?".
Sure, will fix.
>> diff --git a/cache.h b/cache.h
>> index f410d94..127e504 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -1004,13 +1004,14 @@ struct ref {
>> requires_force:1,
>> merge:1,
>> nonfastforward:1,
>> - is_a_tag:1,
>> + forwardable:1,
>
> This is somewhat an unfortunate churn. Perhaps is_a_tag could have
> started its life under its final name in the series?
>
> I am assuming that the struct members will be initialized to 0 (false),
> so everything by default is now not forwardable if somebody forgets
> to set this flag?
Yeah, this was one of a few stupid mistakes. Previously I used
'forwardable' throughout, but that is awkward except in the last
commit since until then everything is allowed to fast-forward and the
flag is only used to output tag-specific advice. But inverting the
meaning of the flag is dumb, and I didn't even do it right.
But, as I think you're suggesting, it probably makes more sense to use
a flag that prevents fast-forwarding when set. So maybe
"not_forwardable", or "is_a_tag" => "not_forwardable" if you think the
renaming is a good idea. Or maybe just "is_a_tag"? I think the
rename is good because its meaning is more general in the last commit.
>> diff --git a/remote.c b/remote.c
>> index 44e72d6..a723f7a 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -1311,14 +1311,24 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
>> * to overwrite it; you would not know what you are losing
>> * otherwise.
>> *
>> - * (3) if both new and old are commit-ish, and new is a
>> - * descendant of old, it is OK.
>> + * (3) if new is commit-ish and old is a commit, new is a
>> + * descendant of old, and the reference is not of the
>> + * refs/tags/ hierarchy it is OK.
>> *
>> * (4) regardless of all of the above, removing :B is
>> * always allowed.
>> */
>
> I think this is unreadable. Isn't this more like
>
> (1.5) if the destination is inside refs/tags/ and already
> exists, you are not allowed to overwrite it without
> --force or +A:B notation.
>
> early in the rule set?
Yes, something like that is much better.
>> - ref->is_a_tag = !prefixcmp(ref->name, "refs/tags/");
>> + if (prefixcmp(ref->name, "refs/tags/")) {
>> + /* Additionally, disallow fast-forwarding if
>> + * the old object is not a commit. This kicks
>> + * out annotated tags that might pass the
>> + * is_newer() test but dangle if the reference
>> + * is updated.
>> + */
>
> Huh? prefixcmp() excludes refs/tags/ hierarchy. What is an
> annotated tag doing there? Is this comment outdated???
I think the comment is accurate, although inverting the meaning of the
flag probably doesn't help the clarity of this change.
What do you mean by "there"? Annotated tags normally are referenced
via something under refs/tags/, but they could be elsewhere, right?
So what I meant to say was: if the reference is not under refs/tags/
then the starting point has to be a commit for it to be forwardable.
I interpreted parse_object(ref->old_sha1) == NULL as the old thing not
existing (rule 1) but I'm pretty sure that was a mistake. I should
first test it with is_null_sha1, if true then it doesn't exist.
Otherwise parse_object() returning NULL means we just don't have the
object and therefore should follow rule 2.
> Regarding the other arm of this "if (not in refs/tags/ hierarchy)",
> what happens when refs/tags/foo is a reference to a blob or a tree?
> This series declares that the point of tag is not to let people to
> move it willy-nilly, and I think it is in line with its spirit if
> you just rejected non-creation events.
Nothing under refs/tags/ is updateable and only commits are updateable
outside of that due to the new logic. The ref_newer() call will
reject updating to blobs and trees, although that probably isn't the
right thing to do. Previously I was ensuring both old and new objects
were commits if the ref was not under refs/tags/, but it occurred to
me that fast-forwarding from a commit to a tag might be a reasonable
thing to want to do. But a rejected update to a blob should get the
already-exists advice, not a message suggesting a merge (which is what
you get by relying on ref_newer() to fail.)
> Also, I suspect that you do not even need to have old object locally
> when looking at refs/tags/ hierarchy. "Do not overwrite tags" can
> be enforced by only noticing that they already have something; you
> do not know what that something actually is to prevent yourself from
> overwriting it. You may have to update the rule (2) in remote.c
> around l.1311 for this.
Isn't it already doing this? I think I've either confounded things
with my mistakes or I'm missing this point.
>> +test_expect_success 'push requires --force to update lightweight tag' '
>> + mk_test heads/master &&
>> + mk_child child1 &&
>> + mk_child child2 &&
>> + (
>> + cd child1 &&
>> + git tag Tag &&
>> + git push ../child2 Tag &&
>
> Don't you want to make sure that another "git push ../child2 Tag" at
> this point, i.e. attempt to update Tag with the same, should succeed
> without --force?
Yes, that is clearly a good addition.
Thanks for all the feedback. Sorry I mucked up this series a bit,
tried to get an update out too quickly I guess.
Chris
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #06; Mon, 19)
From: Felipe Contreras @ 2012-11-20 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <7vpq39up0m.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * fc/remote-testgit-feature-done (2012-10-29) 1 commit
> - remote-testgit: properly check for errors
Pinging Sverre again.
I now think that we need a better solution with waitpid() to check the
status of the process, so that both import and export get proper error
checks. I found that out the hard way with a buggy remote helper.
I still think this patch is good regardless, but not so big of a
priority. I'm not going to purse it more, if it gets in, good, if not,
a waitpid() patch would take care of it.
Cheers.
--
Felipe Contreras
^ 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