* Re: gitattributes don't work
From: Junio C Hamano @ 2011-01-04 18:33 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <ifr610$3kl$1@dough.gmane.org>
Marcin Wiśnicki <mwisnicki@gmail.com> writes:
> I'm trying to exclude certain paths (those that contain "xmac/gen/") from
> diff output using .git/info/attributes (not .gitattributes).
>
> According to gitattributes(5) it supports patterns from gitignore(5).
>
> Example path that must be excluded:
> src/byucc/jhdl/CSRC/xmac/gen/and2_dp_g.xmac
>
> What I've tried but didn't work:
> xmac/gen/ -diff
Why not "xmac/gen/* -diff" or even "xmac/gen/*.xmac -diff"?
^ permalink raw reply
* Re: [PATCH 2/3] Fixes bug: git-svn: svn.pathnameencoding is not respected with dcommit/set-tree
From: Thomas Rast @ 2011-01-04 17:18 UTC (permalink / raw)
To: Zapped; +Cc: git, Eric Wong
In-Reply-To: <1293240049-7744-2-git-send-email-zapped@mail.ru>
Zapped wrote:
> git-svn dcommit/set-tree fails when svn.pathnameencoding is set for native OS encoding (e.g. cp1251 for Windows) though git-svn fetch/clone works well
I'll let Eric judge whether loading the encoding here is the right
fix, but here too the commit message states only what is broken, not
why you fixed it that way. Can you elaborate a bit?
Also, this should be easy to cover with a test case, can you make one?
> git-svn.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 757de82..399bf4c 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -4451,6 +4451,7 @@ sub new {
> $self->{path_prefix} = length $self->{svn_path} ?
> "$self->{svn_path}/" : '';
> $self->{config} = $opts->{config};
> + $self->{pathnameencoding} = Git::config('svn.pathnameencoding');
> return $self;
> }
>
>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/3] Fixes bug: git-diff: class methods are not detected in hunk headers for Pascal
From: Thomas Rast @ 2011-01-04 17:13 UTC (permalink / raw)
To: Zapped; +Cc: git
In-Reply-To: <1293240049-7744-1-git-send-email-zapped@mail.ru>
Zapped wrote:
> Signed-off-by: Zapped <zapped@mail.ru>
As Junio already said, please provide a real name for the sign-off.
But I also found the commit message and content confusing, probably
because I haven't programmed Pascal for 15 years.
You said
Fixes bug: git-diff: class methods are not detected in hunk headers for Pascal
> PATTERNS("pascal",
> - "^((procedure|function|constructor|destructor|interface|"
> + "^(((class[ \t]+)?(procedure|function)|constructor|destructor|interface|"
> "implementation|initialization|finalization)[ \t]*.*)$"
> "\n"
> "^(.*=[ \t]*(class|record).*)$",
But the last line very conspicuously already mentions 'class', so why
does it fail?
I had to look up a bit of Pascal syntax. Google helped with
http://www.freepascal.org/docs-html/ref/ref.html
which answers this. Also, as stated in SubmittingPatches, we
generally word the messages as stating the behaviour of the changed
version in the present tense. So a better commit message would be
userdiff: match Pascal class methods
Class declarations were already covered by the second pattern, but
class methods have the 'class' keyword in front too. Account for
it.
Signed-off-by: Алексей Крезов <zapped@mail.ru>
Ok, now I feel silly for only having a two-liner despite my
complaints.
That being said, I have now verified that the patch is good, and, you
can include my
Acked-by: Thomas Rast <trast@student.ethz.ch>
in a reroll if you fix the above.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* debugging git clone via git-daemon "cannot handle daemon internally"
From: John Griessen @ 2011-01-04 16:50 UTC (permalink / raw)
To: git
I have a server running debian git-core, gitosis, git version 1.7.2.3 and local git version 1.7.2.3.
I've uninstalled git-daemon-run from the server for testing simplicity.
The server is running this:
sudo /usr/lib/git-core/git-daemon --verbose --strict-paths --user=git --group=gitosis /srv/gitosis/repositories &>git-daemon-err.log
when I try cloning from my local machine I get these results:
john@toolbench:~/EEProjects/test$ git clone git://mail.cibolo.us/gitosis-admin.git
Cloning into gitosis-admin...
fatal: protocol error: bad line length character: fata
john@toolbench:~/EEProjects/test$ telnet mail.cibolo.us 9418
Trying 76.191.252.85...
Connected to mail.cibolo.us.
Escape character is '^]'.
fatal: cannot handle daemon internally
Connection closed by foreign host.
What does "cannot handle daemon internally" signify to you all?
The part where telnet connects is saying the firewall is open at 9418, so that's good.
What do you think about debian's package of gitosis? It is working to push,
and clone with this command:
git clone gitosis@mail.cibolo.us:gitosis-admin.git
but not these:
john@toolbench:~/EEProjects/test$ git clone git://mail.cibolo.us/gitosis-admin.git
Cloning into gitosis-admin...
fatal: protocol error: bad line length character: fata
john@toolbench:~/EEProjects/test$ git clone git://mail.cibolo.us/srv/gitosis/repositories/gitosis-admin.git
Cloning into gitosis-admin...
fatal: protocol error: bad line length character: fata
it creates a gitosis user.
Should I install gitosis from source and have a git user only?
What can I simplify to debug this?
gitweb skips this by not using port 9418, so I will be setting that up in the meantime.
thanks,
John
--
Ecosensory Austin TX
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: make logo optional
From: Jonathan Nieder @ 2011-01-04 16:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John 'Warthog9' Hawley, Eric Wong
In-Reply-To: <201101041252.40254.jnareb@gmail.com>
Jakub Narebski wrote:
> On Tue, 4 Dec 2011, Jonathan Nieder wrote:
>> Some sites may not want to have a logo at all. In particular, git
>> instaweb can benefit from this.
>
> Why do you think that git-instaweb can benefit from not having logo?
> You need gitweb.css anyway, so it is not much more trouble to serve
> additional static file, git-logo.png.
Yep, that sentence is stale (it only applied in 1.7.1.x days) and
should have been removed.
> corelist (Module::CoreList) says that Perl 5.8.0 has CGI.pm version 2.81;
> IIRC gitweb requires something later than 5.8.0 for good support of
> Unicode (Encode module).
>
>>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>
> For what it is worth it:
>
> Acked-by: Jakub Narebski <jnareb@gmail.com>
Thanks for looking it over.
^ permalink raw reply
* [RFC][PATCH] git-send-email: added support for S/MIME
From: Roberto Sassu @ 2011-01-04 16:02 UTC (permalink / raw)
To: git; +Cc: Roberto Sassu
[-- Attachment #1: Type: text/plain, Size: 6042 bytes --]
The script git-send-email.perl has been modified in order to add support
for messages with S/MIME format. First, the message body is written in a
temporary file and signed by OpenSSL with the X.509 certificate provided by
the user. Then the returned content is added to the previously parsed
header and the message is sent as the same for unsigned messages.
Usage:
git send-email -sign -signing-cert </path/of/PEM> <other options>
Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
---
git-send-email.perl | 97 +++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 76565de..c040fe6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -57,6 +57,8 @@ git send-email [options] <file | directory | rev-list options >
--annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
--8bit-encoding <str> * Encoding to assume 8bit mails if undeclared
+ --sign * Sign all emails with an X.509 certificate.
+ --signing-cert <str> * Path of the X.509 certificate.
Sending:
--envelope-sender <str> * Email envelope sender.
@@ -141,7 +143,7 @@ my $auth;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_subject,@files,
+ @xb,$initial_reply_to,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$compose,$time);
my $envelope_sender;
@@ -161,9 +163,10 @@ if ($@) {
}
# Behavior modification variables
-my ($quiet, $dry_run) = (0, 0);
+my ($quiet, $dry_run, $sign) = (0, 0, 0);
my $format_patch;
my $compose_filename;
+my $signing_cert;
my $force = 0;
# Handle interactive edition of files.
@@ -232,6 +235,7 @@ my %config_settings = (
"confirm" => \$confirm,
"from" => \$sender,
"assume8bitencoding" => \$auto_8bit_encoding,
+ "signing_cert" => \$signing_cert
);
# Help users prepare for 1.7.0
@@ -311,6 +315,8 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"format-patch!" => \$format_patch,
"8bit-encoding=s" => \$auto_8bit_encoding,
"force" => \$force,
+ "sign" => \$sign,
+ "signing-cert:s" => \$signing_cert,
);
unless ($rc) {
@@ -356,6 +362,11 @@ sub read_config {
}
}
+# verify if the signing certificate has been specified
+if ($sign && !$signing_cert) {
+ die "Signing certificate not specified";
+}
+
# read configuration from [sendemail "$identity"], fall back on [sendemail]
$identity = Git::config(@repo, "sendemail.identity") unless (defined $identity);
read_config("sendemail.$identity") if (defined $identity);
@@ -1161,6 +1172,7 @@ foreach my $t (@files) {
@to = ();
@cc = ();
@xh = ();
+ @xb = ();
my $input_format = undef;
my @header = ();
$message = "";
@@ -1223,7 +1235,20 @@ foreach my $t (@files) {
if (/charset="?([^ "]+)/) {
$body_encoding = $1;
}
- push @xh, $_;
+ if ($sign) {
+ push @xb, $_;
+ } else {
+ push @xh, $_;
+ }
+ }
+ elsif (/^MIME-Version:/i && $sign) {
+ # Do nothing: this will be added by OpenSSL
+ }
+ elsif (/Content-Transfer-Encoding:/i && $sign) {
+ # move the Content-Transfer-Encoding in the
+ # first part of the message if the latter is
+ # about to be signed
+ push @xb, $_;
}
elsif (/^Message-Id: (.*)/i) {
$message_id = $1;
@@ -1275,9 +1300,14 @@ foreach my $t (@files) {
if ($broken_encoding{$t} && !$has_content_type) {
$has_content_type = 1;
- push @xh, "MIME-Version: 1.0",
- "Content-Type: text/plain; charset=$auto_8bit_encoding",
- "Content-Transfer-Encoding: 8bit";
+ if ($sign) {
+ push @xb, "Content-Type: text/plain; charset=$auto_8bit_encoding",
+ "Content-Transfer-Encoding: 8bit";
+ } else {
+ push @xh, "MIME-Version: 1.0",
+ "Content-Type: text/plain; charset=$auto_8bit_encoding",
+ "Content-Transfer-Encoding: 8bit";
+ }
$body_encoding = $auto_8bit_encoding;
}
@@ -1298,12 +1328,59 @@ foreach my $t (@files) {
}
else {
$has_content_type = 1;
- push @xh,
- 'MIME-Version: 1.0',
- "Content-Type: text/plain; charset=$author_encoding",
- 'Content-Transfer-Encoding: 8bit';
+ if ($sign) {
+ push @xb,
+ "Content-Type: text/plain; charset=$author_encoding",
+ 'Content-Transfer-Encoding: 8bit';
+ } else {
+ push @xh,
+ 'MIME-Version: 1.0',
+ "Content-Type: text/plain; charset=$author_encoding",
+ 'Content-Transfer-Encoding: 8bit';
+ }
+ }
+ }
+ }
+
+ if ($sign) {
+ my $linecount = 0;
+ my $message_body_tmp_file;
+
+ # put the original Content-Type, charset and Content-Transfer-Encoding
+ # information, if specified, in the first part of the message
+ if (@xb) {
+ $message = join("\n", @xb) . "\n\n" . $message;
+ } else {
+ $message = "\n" . $message;
+ }
+
+ # write the message body in a temporary file
+ $message_body_tmp_file = ($repo ?
+ tempfile(".gitsendemail.body.XXXXXX", DIR => $repo->repo_path()) :
+ tempfile(".gitsendemail.body.XXXXXX", DIR => "."))[1];
+
+ open(MESSAGE_BODY_FILE,">",$message_body_tmp_file) or
+ die "Failed to open for writing $message_body_tmp_file: $!";
+ print MESSAGE_BODY_FILE $message;
+ close MESSAGE_BODY_FILE;
+
+ # sign the message body and put the result in the $message variable
+ $message = "";
+ open(OPENSSL_SIGNED_MESSAGE, "openssl smime -sign -in $message_body_tmp_file -signer $signing_cert |")
+ or die "Could not execute OpenSSL";
+
+ while(<OPENSSL_SIGNED_MESSAGE>) {
+ chomp;
+ if($linecount < 2) {
+ # push first two lines into the header
+ push @xh, $_;
+ } else {
+ # put the remaining content in the $message variable
+ $message .= $_;
}
}
+ close OPENSSL_SIGNED_MESSAGE;
+ unlink($message_body_tmp_file);
}
$needs_confirm = (
--
1.7.3.4
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2061 bytes --]
^ permalink raw reply related
* PostScript files: textconv and "git add -p"
From: Matthieu Moy @ 2011-01-04 15:50 UTC (permalink / raw)
To: git
Hi (and happy new year everybody !),
I have trouble setting up a comfortable configuration to version
PostScript files. The particularity they have is that they are "text
files" (i.e. git does not detect them as binary files by default, and
neither do tools like less, diff, ...), but not meant to be
human-readable.
If I do this:
,----[ .gitattributes ]
| *.ps diff=ps
`----
,----[ .gitconfig ]
| [diff "ps"]
| textconv=ps2ascii
`----
then I get the textconv niceness when running "git diff", which is
cool, but "git add -p" still proposes me to stage hunks one by one,
which isn't.
If I set "*.ps binary" in .gitattributes, "git add -p" becomes quiet,
but textconv is disabled.
I want "git diff" to run the textconv filter, and "git add -p" to
consider the file as binary. Is there a way to do this?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules
From: Marcin Wiśnicki @ 2011-01-04 15:40 UTC (permalink / raw)
To: git
In-Reply-To: <1294147915-1475-1-git-send-email-pclouds@gmail.com>
On Tue, 04 Jan 2011 20:31:55 +0700, Nguyễn Thái Ngọc Duy wrote:
> gitattr and .gitignore are supposed to use the same rules for matching
> patterns. Unfortunately it's not exactly the same in reality. Mention
> the differences so users won't be surprised, until gitattr gets updates.
>
>
> diff --git a/Documentation/gitattributes.txt
> b/Documentation/gitattributes.txt index 5a7f936..cfaf107 100644
> --- a/Documentation/gitattributes.txt +++
> b/Documentation/gitattributes.txt @@ -56,6 +56,7 @@ When more than one
> pattern matches the path, a later line
> overrides an earlier line. This overriding is done per attribute. The
> rules how the pattern matches paths are the same as in `.gitignore`
> files; see linkgit:gitignore[5].
> +However patterns that end with a slash is not supported.
>
I'm afraid that is not all. The rules I've inferred:
1. No pattern will match directory tree.
2. It is only possible to match on path components.
3. If pattern contains slash it is treated as absolute.
Example for file: d1/d2/f1.c
Patterns that match:
*.c
d1/d2/*
/d1/d2/*
*/d2/*
*/*/*
Patterns that do not match but should:
d2/*
d2/
d2
d1/d2
/d1/d2
^ permalink raw reply
* Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules
From: Michael J Gruber @ 2011-01-04 14:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Marcin Wiśnicki
In-Reply-To: <1294147915-1475-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy venit, vidit, dixit 04.01.2011 14:31:
> gitattr and .gitignore are supposed to use the same rules for matching
> patterns. Unfortunately it's not exactly the same in reality. Mention
> the differences so users won't be surprised, until gitattr gets
> updates.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> 2011/1/4 Marcin Wiśnicki <mwisnicki@gmail.com>:
> > I think that for the time being at least the manual page must change to
> > reflect reality.
>
> Looks like changes will be more than just a few lines because path_matches()
> needs to learn about directories (iow less likely to get fixed right away).
> So, yes, good idea.
>
> I skimmed through excluded_from_list() (gitignore) and path_matches (gitattr).
> Seems no other differences.
>
> Documentation/gitattributes.txt | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 5a7f936..cfaf107 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -56,6 +56,7 @@ When more than one pattern matches the path, a later line
> overrides an earlier line. This overriding is done per
> attribute. The rules how the pattern matches paths are the
> same as in `.gitignore` files; see linkgit:gitignore[5].
> +However patterns that end with a slash is not supported.
+However, patterns terminated by a slash are not supported.
>
> When deciding what attributes are assigned to a path, git
> consults `$GIT_DIR/info/attributes` file (which has the highest
Cheers,
Michael
^ permalink raw reply
* Re: False positives in git diff-index
From: Alexander Gladysh @ 2011-01-04 14:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Zenaan Harkness, git, Jeff King
In-Reply-To: <m339p8dap4.fsf@localhost.localdomain>
On Tue, Jan 4, 2011 at 14:08, Jakub Narebski <jnareb@gmail.com> wrote:
> Alexander Gladysh <agladysh@gmail.com> writes:
>> On Tue, Jan 4, 2011 at 14:47, Zenaan Harkness <zen@freedbms.net> wrote:
>> > On Tue, Jan 4, 2011 at 20:45, Alexander Gladysh <agladysh@gmail.com> wrote:
>> > So your problem could be quite hard to debug, whilst being distinctly
>> > difficult to ascertain the root causes.
>> 1. I found a reproducible case for a hard to catch bug in Git. (This
>> is a bug in Git, not in my build process.) This bug in its
>> intermittent form annoyed me for quite some time — several months at
>> least — and is likely to annoy other users. (I'm not *that* unique!)
> But it is reproductible to you: from what I understand you didn't find
> some minimal example to reproduce this issue without need for access
> your proprietary build process.
> AG> Unfortunately I can not share it or create a minimal example ? the
> AG> case is triggered by a custom complicated automated build process on a
> AG> private repository.
Yes, that is true. Still, much, much better than intermittent.
>> 3. I'm willing to help Git developers with catching this bug for
>> mutual benefit — I will get rid of annoying issue and make my
>> deployment code more robust. Git will, well, be a bit more robust as
>> well.
> To debug it, if you cannot do it yourself, you would have to find git
> developer who is both knowledgeable about fairly deep part of git
> code, and can work with remote debugging with you at remote.
I understand that. But is the second part of requirement is such a
large problem?
Anyway, as I said, if no one will step up, no problem.
> P.S. Somewhere in the depths of git maling list archive (it didn't
> unfortunately made it to "Interfaces, Frontends and tools" page on git
> wiki) there is tool/script for anonymizing git repository, to allow
> debugging of bugs which occurs in some repositories that cannot be
> made public. Perhaps something similar could be done for your build
> process (you need to reproduce only stat + git part)?
I remember, somebody advised me to use this tool, when I reported some
bug some time (maybe a year) ago.
But, I'm afraid, I do not know how to separate my deployment tool
logic (which reproduces the bug) from the repository data. If I did
know, I'd come up with a minimal example already. Nothing trivial
"along the lines", that I tried so far, does reproduce it.
Alexander.
^ permalink raw reply
* RE: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Vallon, Justin @ 2011-01-04 14:43 UTC (permalink / raw)
To: 'Robin H. Johnson', Junio C Hamano, git@vger.kernel.org
In-Reply-To: <20101227080343.GA15026@orbis-terrarum.net>
# "exec" commands are ran with the user shell by default, but this may
# be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
# to create a file. Unseting SHELL avoids such non-portable behavior
Perl's exec and system do not use SHELL (as far as perlfunc states). It uses /bin/sh -c "$cmd", or a platform-dependent equivalent.
$SHELL is typically only used when a program wants to invoke a user-shell (ie: editor shell-escape, xterm, typescript, screen).
How was SHELL=/bin/false causing problems? Is git using $SHELL?
--
-Justin
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Robin H. Johnson
Sent: Monday, December 27, 2010 3:04 AM
To: Junio C Hamano; git@vger.kernel.org
Subject: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
If the user's shell in NSS passwd is /bin/false (eg as found during Gentoo's
package building), the git-rebase exec tests will fail, because they call
$SHELL around the command, and in the existing testcase, $SHELL was not being
cleared sufficently.
This lead to false positive failures of t3404 on systems where the package
build user was locked down as noted above.
Signed-off-by: "Robin H. Johnson" <robbat2@gentoo.org>
X-Gentoo-Bug: 349083
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=349083
---
t/t3404-rebase-interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index d3a3bd2..7d8147b 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -71,8 +71,9 @@ test_expect_success 'setup' '
# "exec" commands are ran with the user shell by default, but this may
# be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
# to create a file. Unseting SHELL avoids such non-portable behavior
-# in tests.
+# in tests. It must be exported for it to take effect where needed.
SHELL=
+export SHELL
test_expect_success 'rebase -i with the exec command' '
git checkout master &&
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply related
* Re: False positives in git diff-index
From: Jakub Narebski @ 2011-01-04 14:08 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: Zenaan Harkness, git, Jeff King
In-Reply-To: <AANLkTinfbyve-k8xBzDb1sTcXhJGvL_B+auuA8BQSUy2@mail.gmail.com>
Alexander Gladysh <agladysh@gmail.com> writes:
> On Tue, Jan 4, 2011 at 14:47, Zenaan Harkness <zen@freedbms.net> wrote:
> > On Tue, Jan 4, 2011 at 20:45, Alexander Gladysh <agladysh@gmail.com> wrote:
> > > Nobody is interested?
>
> > Your problem set appears that you have a rather gnarly corner case
> > issue, arising from your custom build processes. Although git really
> > is amazing, I believe you may well be pushing git to its technological
> > limits.
>
> Committing few megabytes of data several times per second is
> technological limits? I do not believe so.
Well, at least it is not what version control system is about; git is
designed towards manual and not automatic commits, and version control
of source code.
> > So your problem could be quite hard to debug, whilst being distinctly
> > difficult to ascertain the root causes.
> 1. I found a reproducible case for a hard to catch bug in Git. (This
> is a bug in Git, not in my build process.) This bug in its
> intermittent form annoyed me for quite some time — several months at
> least — and is likely to annoy other users. (I'm not *that* unique!)
But it is reproductible to you: from what I understand you didn't find
some minimal example to reproduce this issue without need for access
your proprietary build process.
AG> Unfortunately I can not share it or create a minimal example ? the
AG> case is triggered by a custom complicated automated build process on a
AG> private repository.
> 3. I'm willing to help Git developers with catching this bug for
> mutual benefit — I will get rid of annoying issue and make my
> deployment code more robust. Git will, well, be a bit more robust as
> well.
To debug it, if you cannot do it yourself, you would have to find git
developer who is both knowledgeable about fairly deep part of git
code, and can work with remote debugging with you at remote.
P.S. Somewhere in the depths of git maling list archive (it didn't
unfortunately made it to "Interfaces, Frontends and tools" page on git
wiki) there is tool/script for anonymizing git repository, to allow
debugging of bugs which occurs in some repositories that cannot be
made public. Perhaps something similar could be done for your build
process (you need to reproduce only stat + git part)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitattributes.txt: mention exceptions to gitignore rules
From: Nguyễn Thái Ngọc Duy @ 2011-01-04 13:31 UTC (permalink / raw)
To: git, Junio C Hamano, Marcin Wiśnicki
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <iftvu6@dough.gmane.org>
gitattr and .gitignore are supposed to use the same rules for matching
patterns. Unfortunately it's not exactly the same in reality. Mention
the differences so users won't be surprised, until gitattr gets
updates.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
2011/1/4 Marcin Wiśnicki <mwisnicki@gmail.com>:
> I think that for the time being at least the manual page must change to
> reflect reality.
Looks like changes will be more than just a few lines because path_matches()
needs to learn about directories (iow less likely to get fixed right away).
So, yes, good idea.
I skimmed through excluded_from_list() (gitignore) and path_matches (gitattr).
Seems no other differences.
Documentation/gitattributes.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 5a7f936..cfaf107 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -56,6 +56,7 @@ When more than one pattern matches the path, a later line
overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+However patterns that end with a slash is not supported.
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* weird github capitalization problem
From: bolfo @ 2011-01-04 13:04 UTC (permalink / raw)
To: git
Hello guys,
I am new at git and github, but I am collaborating on a netbeans java
project with someone else and we host our code on github.
I first installed everything on my laptop, coded some stuff and then pushed
to github. Apparently something went wrong because there was a new
directory, while at first the directory was OurProjectsources, there now was
a new directory called OurProjectSources. Weird since my local directory has
the s not capitalized.
I installed git on another PC and cloned the project from github to my local
PC.
Apparently only the directory with the capital S was pulled.
Does anyone recognize this problem?
I work on a windows PC while the original author works on a Mac, could this
be the problem?
--
View this message in context: http://git.661346.n2.nabble.com/weird-github-capitalization-problem-tp5888573p5888573.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC PATCH v7 11/9] [PoC] gitweb/lib - tee, i.e. print and capture during cache entry generation
From: Jakub Narebski @ 2011-01-04 13:20 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <201101040128.26826.jnareb@gmail.com>
Jakub Narebski wrote:
> On Tue, 4 Jan 2011, J.H. wrote:
> > On 01/03/2011 01:33 PM, Jakub Narebski wrote:
>
> > > Instead of having gitweb use progress info indicator / throbber to
> > > notify user that data is being generated by current process, gitweb
> > > can now (provided that PerlIO::tee from PerlIO::Util is available)
> > > send page to web browser while simultaneously saving it to cache
> > > (print and capture, i.e. tee), thus having incremental generating of
> > > page serve as a progress indicator.
> >
> > In general, and particularly for the large sites that caching is
> > targeted at, teeing is a really bad idea.
[...]
> > 1) Errors may still be generated in flight as the cache is being
> > generated. It would be better to let the cache run with a progress
> > indicator and should an error occur, display the error instead of giving
> > any output that may have been generated (and thus likely a broken page).
>
> On the contrary, with tee-ing (and zero size sanity check) you would be
> able to see pages even if there are errors saving cache entry. Though
> this wouldn't help very large sites which cannot function without caching,
> it could be useful for smaller sites.
I was not sure how Perl reacts to ENOSPC (No space left on device),
which I think it is only error that can be generated in flight as
cache is being generated (or as gitweb output is printed i.e. sent
to browser and captured/tee-ed i.e. saved to cache entry file), so
I have checked this (using loopback to create small filesystem).
The outcomes one worry about are the following:
* Perl dies during printing - this leads to broken page send to
browser, and no cache entry generated
* Perl prints output without dying at all; the page send to browser
via tee-in is all right, but cache entry is truncated which results
in broken page shown to other clients.
But what actually happens is actually different, and quite safe:
* Perl prints output without dying, and dies on closing cache entry
file with ENOSPC. This means that client generating data gets correct
output, and cache entry is not generated. Other clients with my code
try their hand at generation and also get correct page, but not save
it to cache.
This means that no error page about problems with cache is shown, which
is bad. On the other hand, at least for smaller sites, gitweb keeps
working as if without cache for newer entries.
Note that observed behaviour might depend on operating system / filesystem
parameters, such as buffer sizes.
> But see below.
[...]
> Note also that in my rewrite you can simply (by changing one single
> configuration knob) configure gitweb to also cache error pages. This
> might be best and safest solution for very large sites with very large
> disk space, but not so good for smaller sites.
Errr... now after rereading your email I see that caching error pages
has one problem: errors that come from the caching engine or capturing
engine - those errors you cannot cache. Sorry, my mistake.
> > - John 'Warthog9' Hawley
> >
> > P.S. I'm back to work full-time on Wednesday, which I'll be catching up
> > on gitweb and trying to make forward progress on my gitweb code again.
>
> I'll try to send much simplified (and easier to use in caching) error
> handling using exceptions (die / eval used as throw / catch) today.
Sent as
[RFC PATCH v7 2.5/9] gitweb: Make die_error just die, and use send_error
to create error pages
Message-ID: <201101040135.08638.jnareb@gmail.com>
http://permalink.gmane.org/gmane.comp.version-control.git/164466
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 3/3] filter-branch: support --submodule-filter
From: Thomas Rast @ 2011-01-04 13:14 UTC (permalink / raw)
To: Jeffrey Phillips Freeman; +Cc: git, Johannes Sixt, Jens Lehmann
In-Reply-To: <4D225F63.1040502@syncleus.com>
Please don't top-post. (There's nothing wrong with snipping the whole
message if it does not really relate, as in this case.)
Ccs for the patch at the end; I don't really care much but I could
roll all of it into a sort of "submodule tools" series for g-f-b, so
if you like it, speak up.
Jeffrey Phillips Freeman wrote:
> So im kinda new with all this so bare with me guys. I wanted to figure
> out how to apply these patches, now i know i can use git to do this with
> its patch command and such. However i was curious does this exist as a
> branch somewhere official or semi-official?
Not really.
You can dig through the mailing list archives and also e.g.
gitworkflows to see how Junio handles incoming patches, but for series
like this you usually have to apply them yourself. I deliberately
flagged it RFC because I wanted to get some feedback ... and because I
would have had to spend more time on it for docs&tests.
> I currently seem to be using
> --split-submodule which is itself in a git repo i have (which i want to
> also find its source repo so i can keep up to date with it).
For others reading this, I wrote --split-submodule also based on an
IRC request from Jeffrey. The patch is at the end. But it's way less
thought through than the --{dump,load}-map feature. In particular
I've been wondering whether it's possible to use the latter to
implement --split-submodule as a fairly concise index filter.
> So applying
> the patch itself might be somewhat troubling due to conflicts, therefore
> id like to actually merge in a remote branch to keep things easy. So can
> you guys point me to which repo would be best for me to keep up to date
> with this would be?
You'll get the same conflicts from merging two little branches with
the features on them as with a 'git am -3'.
Many patches are never pushed to a public repo (there are some notable
exceptions in longer-running work). The hassle of sending and
applying email is far outweighed by the ease of review. Many reviews
happen without applying the series at all. That I pushed both of them
to a public repo was an exception for your convenience.
--- 8< ---
Subject: TOY PATCH: filter-branch --split-submodule
Sometimes it makes sense to split out a path not as a subdirectory
(that would be merged by subtree-merge), but as a submodule. Since
git objects are just shaped in the right way, this is actually quite
easy to do in a way that maintains the correct history relations:
When splitting out DIR in commit C, the submodule commit has tree
C:DIR and the rewritten superproject commit C' gets a submodule entry
at C:DIR instead.
Parent rewriting is done in the obvious way: submodule commits have
their corresponding submodule-changing ancestors as parents. These
are easy to fetch since we can basically use $(map C^):DIR.
This is a toy patch because of its terrible interface: you will still
have to put the submodule in place. As a start, you can
git clone . DIR
( cd DIR && git reset --hard $(git rev-parse :DIR) )
to get a sub-repo set to the correct commit.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 962a93b..329d85c 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -191,6 +191,9 @@ do
filter_subdir="$OPTARG"
remap_to_ancestor=t
;;
+ --split-submodule)
+ split_submodule="$OPTARG"
+ ;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
;;
@@ -349,6 +352,43 @@ while read commit parents; do
eval "$filter_index" < /dev/null ||
die "index filter failed: $filter_index"
+ if test -n "$split_submodule"; then
+ sub_differs=
+ sub_parents=
+ sub_commit=
+ submodule="$(git rev-parse --verify $commit:$split_submodule 2>/dev/null)"
+ if test -z "$parents"; then
+ if test -n "$submodule"; then
+ sub_differs=t
+ fi
+ fi
+ for parent in $parents; do
+ if ! test "$(git rev-parse --verify $parent:$split_submodule 2>/dev/null)" = "$submodule"; then
+ sub_differs=t
+ fi
+ for reparent in $(map "$parent"); do
+ p="$(git rev-parse --verify $reparent:$split_submodule 2>/dev/null)"
+ if test -n "$p"; then
+ sub_parents="$sub_parents -p $p"
+ fi
+ done
+ done
+ if test -n "$sub_differs"; then
+ sub_commit="$(sed -e '1,/^$/d' <../commit |
+ git commit-tree $submodule $sub_parents)" || exit
+ else
+ for parent in $parents; do
+ sub_commit="$(git rev-parse --verify "$(map "$parent")":$split_submodule 2>/dev/null)"
+ break
+ done
+ fi
+ if test -n "$sub_commit"; then
+ git update-index --add --replace --cacheinfo 160000 $sub_commit "$split_submodule" || exit
+ else
+ git update-index --remove "$split_submodule"
+ fi
+ fi
+
parentstr=
for parent in $parents; do
for reparent in $(map "$parent"); do
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [PATCH] daemon: support <directory> arguments again
From: Erik Faye-Lund @ 2011-01-04 12:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, gitster
In-Reply-To: <20110104040446.GA3541@burratino>
On Tue, Jan 4, 2011 at 5:04 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ever since v1.7.4-rc0~125^2~8 (daemon: use run-command api for async
> serving, 2010-11-04), git daemon spawns child processes instead of
> forking to serve requests. The child processes learn that they are
> being run for this purpose from the presence of the --serve command
> line flag.
>
> When running with <ok_path> arguments, the --serve flag is treated
> as one of the path arguments and the special child behavior does
> not kick in. So the child becomes an ordinary git daemon process,
> notices that all the addresses it needs are in use, and exits with
> the message "fatal: unable to allocate any listen sockets on port
> 9418".
>
> Fix it by putting --serve at the beginning of the command line,
> where the flag cannot be mistaken for a path argument.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> On the client side:
>
> $ git clone git://localhost/git/git.git
> Cloning into git...
> fatal: read error: Connection reset by peer
>
> On the server side:
>
> # $git_src/bin-wrappers/git daemon --verbose --base-path=/var/cache /var/cache/git
> fatal: unable to allocate any listen sockets on port 9418
> [3602] [3604] Disconnected (with error)
>
> Bisects to v1.7.4-rc0~125^2~8. This patch seems to fix it. Thoughts?
>
Looks good to me. Thanks for finding and fixing it!
^ permalink raw reply
* BUG: gitk fails to parse 1.7.4-rc0 version string
From: Mathias Lafeldt @ 2011-01-04 12:44 UTC (permalink / raw)
To: git; +Cc: paulus
Looks like gitk doesn't like the "-rc0" suffix.
$ git --version
git version 1.7.4-rc0
$ gitk
Error in startup script: expected version number but got "1.7.4-rc0"
while executing
"package vcompare $git_version "1.6.6.2""
(file "/usr/local/bin/gitk" line 1)
I temporarily fixed it by hard-coding the version string:
diff --git a/gitk-git/gitk b/gitk-git/gitk
index e82c6bf..367446e 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -11581,7 +11581,7 @@ if {![info exists have_ttk]} {
set use_ttk [expr {$have_ttk && $want_ttk}]
set NS [expr {$use_ttk ? "ttk" : ""}]
-set git_version [join [lrange [split [lindex [exec git version] end] .]
0 2] .]
+set git_version "1.7.4"
set show_notes {}
if {[package vcompare $git_version "1.6.6.2"] >= 0} {
-Mathias
^ permalink raw reply related
* Re: git repo corruption
From: Drew Northup @ 2011-01-04 12:34 UTC (permalink / raw)
To: Levend Sayar; +Cc: git
In-Reply-To: <AANLkTi=TSy1WQZARNQgGfPiV93hQ-xmCTip75JAixgDB@mail.gmail.com>
On Tue, 2011-01-04 at 11:10 +0200, Levend Sayar wrote:
> Hi, all.
>
> We have a repo on a corporate server. The sysadmin changed access
> rights of files on our repo by accedant.
> Some directories have 2750 acces rights before, but he changed as
>
> chmod -R 2770 *
>
> Now when you make git status, every file that is tracked by git is said as
>
> changed but not updated
>
> So is there a way to get this back to normal ?
>
> TIA
>
> _lvnd_
> (^_^)
Am I correct in guessing that this is not a bare repo?
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: False positives in git diff-index
From: Alexander Gladysh @ 2011-01-04 12:01 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git, Jeff King
In-Reply-To: <AANLkTi=Po7zA1YG-VdN6cZEV+ZF3GYNM9W9CLVXFaE5Z@mail.gmail.com>
On Tue, Jan 4, 2011 at 14:47, Zenaan Harkness <zen@freedbms.net> wrote:
> On Tue, Jan 4, 2011 at 20:45, Alexander Gladysh <agladysh@gmail.com> wrote:
>> Nobody is interested?
> Your problem set appears that you have a rather gnarly corner case
> issue, arising from your custom build processes. Although git really
> is amazing, I believe you may well be pushing git to its technological
> limits.
Committing few megabytes of data several times per second is
technological limits? I do not believe so.
> So your problem could be quite hard to debug, whilst being distinctly
> difficult to ascertain the root causes.
> It also appears that your custom complicated build process is likely
> protecting, or at least integral to, your high value corporate process
> assets.
> So _in this case_ you would be remiss to not find a suitable
> consultant to provide professional and discreet assistance - perhaps
> GitHub.com, as GitHub’s Tender provides both public and _private_
> support issue posting, and customized and private training if you and/
> or your colleagues require; you might contact GitHub direct (
> https://github.com/contact ) as their Support page does not link
> directly to support contract information; oh, and GitHub supports a
> lot of community projects too: their support for our community ought
> be supported.
> <disclaimer> I am _not_ affiliated with GitHub, I do work full time
> with a human rights association in Australia.
Thank you for your opinion.
I view this particular situation as follows:
1. I found a reproducible case for a hard to catch bug in Git. (This
is a bug in Git, not in my build process.) This bug in its
intermittent form annoyed me for quite some time — several months at
least — and is likely to annoy other users. (I'm not *that* unique!)
2. I can live happily with sleep(0.2) in my deployment code (while
this is not very satisfying, it is acceptable — certainly cheaper than
a paid consultant).
3. I'm willing to help Git developers with catching this bug for
mutual benefit — I will get rid of annoying issue and make my
deployment code more robust. Git will, well, be a bit more robust as
well.
4. The sole reason I'm pinging back on this bug report is that I'm
afraid to accidentally lose the data snapshot (or something in
environment) that makes the issue reproducible.
5. If no one is interested, well, that's opensource :-) No hard feelings.
Alexander.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: make logo optional
From: Jakub Narebski @ 2011-01-04 11:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, John 'Warthog9' Hawley, Eric Wong
In-Reply-To: <20110104050555.GC8280@burratino>
On Tue, 4 Dec 2011, Jonathan Nieder wrote:
> Some sites may not want to have a logo at all. In particular, git
> instaweb can benefit from this.
Why do you think that git-instaweb can benefit from not having logo?
You need gitweb.css anyway, so it is not much more trouble to serve
additional static file, git-logo.png.
>
> While at it, use $cgi->img to simplify this code. (CGI.pm learned
> most HTML4 tags by version 2.79, so this should be portable to perl
> 5.8, though I haven't tested.)
corelist (Module::CoreList) says that Perl 5.8.0 has CGI.pm version 2.81;
IIRC gitweb requires something later than 5.8.0 for good support of
Unicode (Encode module).
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
For what it is worth it:
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: False positives in git diff-index
From: Zenaan Harkness @ 2011-01-04 11:47 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, Jeff King
In-Reply-To: <AANLkTinDSCPz-oukxzn24hj94d9WpzZ8_64TBHeNTmoG@mail.gmail.com>
On Tue, Jan 4, 2011 at 20:45, Alexander Gladysh <agladysh@gmail.com> wrote:
> Nobody is interested?
Your problem set appears that you have a rather gnarly corner case
issue, arising from your custom build processes. Although git really
is amazing, I believe you may well be pushing git to its technological
limits.
So your problem could be quite hard to debug, whilst being distinctly
difficult to ascertain the root causes.
It also appears that your custom complicated build process is likely
protecting, or at least integral to, your high value corporate process
assets.
So _in this case_ you would be remiss to not find a suitable
consultant to provide professional and discreet assistance - perhaps
GitHub.com, as GitHub’s Tender provides both public and _private_
support issue posting, and customized and private training if you and/
or your colleagues require; you might contact GitHub direct (
https://github.com/contact ) as their Support page does not link
directly to support contract information; oh, and GitHub supports a
lot of community projects too: their support for our community ought
be supported.
<disclaimer> I am _not_ affiliated with GitHub, I do work full time
with a human rights association in Australia.
Good luck
Zenaan
> Is there a way I can get some help with this issue?
>
> Thanks,
> Alexander.
>
> On Mon, Dec 27, 2010 at 11:49, Alexander Gladysh <agladysh@gmail.com> wrote:
>> Hi, list!
>>
>> I wrote about the related issue earlier:
>>
>> http://lists-archives.org/git/731516-false-positives-from-git-diff-index-when-used-with-git-dir.html
>>
>> Now I've got a case when I can reproduce this problem each time I try to.
>>
>> Unfortunately I can not share it or create a minimal example — the
>> case is triggered by a custom complicated automated build process on a
>> private repository.
...
^ permalink raw reply
* Re: [PATCH 4/4] vcs-svn: improve reporting of input errors
From: Jonathan Nieder @ 2011-01-04 10:16 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
In-Reply-To: <20101228105410.GD13360@burratino>
Jonathan Nieder wrote:
> --- a/vcs-svn/svndump.c
> +++ b/vcs-svn/svndump.c
> @@ -107,20 +107,37 @@ static void init_keys(void)
[...]
> } else if (!strncmp(t, "V ", 2)) {
> len = atoi(&t[2]);
> val = buffer_read_string(len);
> + if (!t)
> + die_short_read();
This should have said "if (!val)". Sorry for the confusion.
^ permalink raw reply
* Re: False positives in git diff-index
From: Alexander Gladysh @ 2011-01-04 9:45 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <AANLkTimLW+J_rmRsqUQJO-9Gzn7aK0ZHkd1-s=Wg4Vbi@mail.gmail.com>
Nobody is interested?
Is there a way I can get some help with this issue?
Thanks,
Alexander.
On Mon, Dec 27, 2010 at 11:49, Alexander Gladysh <agladysh@gmail.com> wrote:
> Hi, list!
>
> I wrote about the related issue earlier:
>
> http://lists-archives.org/git/731516-false-positives-from-git-diff-index-when-used-with-git-dir.html
>
> Now I've got a case when I can reproduce this problem each time I try to.
>
> Unfortunately I can not share it or create a minimal example — the
> case is triggered by a custom complicated automated build process on a
> private repository.
>
> Anyway, I'm ready to debug this issue if someone will guide me.
>
> Workflow:
>
> <...change files in /path/dir1/...>
> (cd /path && git add </path/dir1/>)
> (cd /path && git commit -m <message1>)
>
> ... repeat change-add-commit several times for various directories
> (can be the same directory or not) ...
>
> <...generate file /path/dirN/foo...>
> # Accidentally the file is generated the same as it was
>
> (cd /path && git add </path/dirN/>)
> (cd /path && git status) # Refresh index
> (cd /path && git diff-index --exit-code --quiet HEAD -- /path/dirN) #
> Incorrectly reports that there are some changes
> (cd /path && git commit -m <messageN>) # fails, saying that there is
> nothing to commit
>
> If I insert sleep 10 between git status and git diff-index, the
> problem goes away.
>
> Any help?
> Alexander.
>
^ permalink raw reply
* git repo corruption
From: Levend Sayar @ 2011-01-04 9:10 UTC (permalink / raw)
To: git
Hi, all.
We have a repo on a corporate server. The sysadmin changed access
rights of files on our repo by accedant.
Some directories have 2750 acces rights before, but he changed as
chmod -R 2770 *
Now when you make git status, every file that is tracked by git is said as
changed but not updated
So is there a way to get this back to normal ?
TIA
_lvnd_
(^_^)
^ 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