* Re: determine if the tree is dirty
From: Adam Mercer @ 2009-11-03 19:30 UTC (permalink / raw)
To: Junio C Hamano, jepler; +Cc: git
In-Reply-To: <7v3a4vs9g3.fsf@alter.siamese.dyndns.org>
On Tue, Nov 3, 2009 at 13:06, Jeff Epler <jepler@unpythonic.net> wrote:
> GIT-VERSION-GEN uses something like this (shell script):
> git update-index -q --refresh
> test -z "$(git diff-index --name-only HEAD --)" || VN="$VN-dirty" ;;
On Tue, Nov 3, 2009 at 13:19, Junio C Hamano <gitster@pobox.com> wrote:
> Use plumbing commands.
>
> "git diff-files" will show changes you have in the work tree compared to
> the index.
>
> "git diff-index HEAD" will show changes you have in the work tree compared
> to the HEAD.
>
> "git diff-index --cached HEAD" will show changes you have in the index
> compared to the HEAD.
Fantastic, this is exactly what I was after! Thanks!
Cheers
Adam
^ permalink raw reply
* Re: determine if the tree is dirty
From: Junio C Hamano @ 2009-11-03 19:19 UTC (permalink / raw)
To: Adam Mercer; +Cc: git
In-Reply-To: <799406d60911031057l5dcb4d4fi3705cc66997ff7f7@mail.gmail.com>
Adam Mercer <ramercer@gmail.com> writes:
> As part of a python script I need to determine if a tree has any
> uncommitted changes, so far I am been using:
>
> # determine tree status
> status_cmd = 'git status'
> status_output = run_external_command(status_cmd,
> honour_ret_code=False)[1].strip()
> if status_output.endswith('no changes added to commit (use "git add"
> and/or "git commit -a")'):
> git_status = 'UNCLEAN: Some modifications not committed'
> else:
> git_status = 'CLEAN: All modifications committed'
>
> but I feel that this relies to heavily on the porcelain and that there
> should be a better way to accomplish this without relying on parsing
> the output of git-status.
>
> Does anyone know of a better way to accomplish this?
Use plumbing commands.
"git diff-files" will show changes you have in the work tree compared to
the index.
"git diff-index HEAD" will show changes you have in the work tree compared
to the HEAD.
"git diff-index --cached HEAD" will show changes you have in the index
compared to the HEAD.
^ permalink raw reply
* Re: determine if the tree is dirty
From: Jeff Epler @ 2009-11-03 19:06 UTC (permalink / raw)
To: Adam Mercer; +Cc: git
In-Reply-To: <799406d60911031057l5dcb4d4fi3705cc66997ff7f7@mail.gmail.com>
On Tue, Nov 03, 2009 at 12:57:37PM -0600, Adam Mercer wrote:
> As part of a python script I need to determine if a tree has any
> uncommitted changes
GIT-VERSION-GEN uses something like this (shell script):
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" || VN="$VN-dirty" ;;
Jeff
^ permalink raw reply
* determine if the tree is dirty
From: Adam Mercer @ 2009-11-03 18:57 UTC (permalink / raw)
To: git
Hi
As part of a python script I need to determine if a tree has any
uncommitted changes, so far I am been using:
# determine tree status
status_cmd = 'git status'
status_output = run_external_command(status_cmd,
honour_ret_code=False)[1].strip()
if status_output.endswith('no changes added to commit (use "git add"
and/or "git commit -a")'):
git_status = 'UNCLEAN: Some modifications not committed'
else:
git_status = 'CLEAN: All modifications committed'
but I feel that this relies to heavily on the porcelain and that there
should be a better way to accomplish this without relying on parsing
the output of git-status.
Does anyone know of a better way to accomplish this?
Cheers
Adam
^ permalink raw reply
* [ANNOUNCE] Grack - Rack-based Git Smart-HTTP Handler
From: Scott Chacon @ 2009-11-03 18:57 UTC (permalink / raw)
To: git list
Just a quick note for those of you interested in running a smart-http
server once Shawns series graduates from 'pu' - I don't use Apache and
the provided git-http-backend CGI script only works with Apache
currently (and only CGI-supporting servers in general). In order to
allow Git smart-http to work through a wider variety of servers, I
wrote a Rack application that does the same things that
git-http-backend does, in case CGI/Apache is not your particular bag
of fun.
Rack (http://rack.rubyforge.org/) is a Ruby webserver interface - you
can write an application for it and it has a bunch of handlers for
common webservers so you can deal with a middleware abstraction rather
than a specific server implementation. This is nice because it means
the Rack app I wrote that provides (hopefully) identical functionality
to the git-http-backend script can run in the following webservers:
* Just about anything that supports CGI or FCGI
* Mongrel (and EventedMongrel and SwiftipliedMongrel)
* WEBrick
* SCGI
* LiteSpeed
* Thin
* Ebb
* Fuzed
* Phusion Passenger (which is mod_rack for Apache and for nginx)
* Unicorn
You can also generate a WAR file from it (via the Warbler project and
JRuby) that can be loaded into any Java application server (I tested
it on Glassfish, but Tomcat, Websphere, JBoss, Jetty, etc should all
work too).
The project is here:
http://github.com/schacon/grack
I've tested it on a few servers, I'll try to test it on more and
provide example setups for each. If you use it, please let me know
how things go.
Scott
^ permalink raw reply
* Re: [PATCH] commit -c/-C/--amend: reset timestamp and authorship to committer with --mine
From: Erick Mattos @ 2009-11-03 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Please don't forget your comments down here wasn't about the last sent
patch. Please see it, in case you don't have it, at:
http://marc.info/?l=git&m=125712272606721&w=2
Anyway I am answering your comments down here:
2009/11/2 Junio C Hamano <gitster@pobox.com>:
> Erick Mattos <erick.mattos@gmail.com> writes:
>
>> 2009/11/1 Junio C Hamano <gitster@pobox.com>:
>>> Erick Mattos <erick.mattos@gmail.com> writes:
>>>
>>>>> % git commit --claim --author='Erick Mattos <eric@mattos>' -C HEAD
>>>>>
>>>>> Should you detect an error? Does your code do so? Do you have a test
>>>>> that catches this error?
>>>>
>>>> It works as intended. Both together.
>>>
>>> That does not make any sense. If you are saying this is yours and it is
>>> his at the same time, there can be no sane way to work "as intended", no?.
>>
>> I am adding a new option not changing the option --author already in
>> git. So it does work together.
>
> Somebody who says "this commit is mine, and its author is this other
> person" is not making any sense. The resulting commit can either have
> that person (i.e. the committer) as the author, which is what the "claim"
> option means, or it can have the person named with --author as the author,
> but both cannot be true at the same time.
>
> When you introduce a new option, sometimes it cannot sanely be used with
> an existing option. In such a case, two options (the new one and the
> existing one) are called mutually exclusive. And you add some code to
> catch an user error to use them together.
As --author text says: "override author for commit".
As I see, something that OVERRIDES supersedes everything else.
IMHO --author shouldn't be blocked by the new option. Probably your
point is about "mine" name.
Cutting --author away would make impossible for someone to force a new
author with a new timestamp in case he is templating. Of course he
can be using the --author because he is doing a change in a computer
not his own or something alike. So I would not wipe "author" out from
the new option.
Please don't forget that I am just being a small contributor. I am
just suggesting things. You have the final word.
>>>>>> + git commit -c HEAD <<EOF
>>>>>> + "Changed"
>>>>>> + EOF &&
>>>>>
>>>>> What editor is reading this "Changed"?
>>>>
>>>> Nobody cares... Just a text to change the file.
>>>
>>> I actually care. Who uses that Changed string, and where does it end up
>>> with? At the end of the log message? At the beginning? What "file"?
>>
>> I didn't get it. -c option does not accept -m option and starts an
>> editor to change the message. The text "Changed is just a forced
>> message. I can not use an editor in interactive mode in a script...
>
> How are the existing tests that try "commit -c" do this? I do not think
> there is any here-text redirect into "git commit".
Sorry, it was automatic for me. Just supposing a here-text... :-)
I am going to fix it.
> It is sometimes easier to show by example than by giving nudging words
> that only show direction, so here is a suggested rewrite on top of your
> patch. I am not very happy with the option name "mine" either, but at
> least I think this gets the semantics right.
We could call it --reset-author. What do you think?
> + if (force_author && renew_authorship)
> + die("Using both --mine and --author does not make sense");
> +
As previously said up there.
^ permalink raw reply
* Re: Problem signing a tag
From: Joshua J. Kugler @ 2009-11-03 18:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0911022331q2976b6e6u575a9700b212623d@mail.gmail.com>
On Monday 02 November 2009, Alex Riesen said something like:
> On Tue, Nov 3, 2009 at 01:58, Joshua J. Kugler <joshua@eeinternet.com>
wrote:
> > Nobody on the git IRC channel responded to this question, even
> > after asking it a few times, so I thought I'd try here.
> >
> > I'm having trouble signing a tag. I'm using this command:
> >
> > git tag -u EAFD344D14EA086E -F .git/TAG_EDITMSG tag_name
> >
> > I type in my passphrase, and am then told:
> >
> > error: gpg failed to sign the tag
> > error: unable to sign the tag
> >
> > However, if I use this command:
> >
> > gpg -s -u EAFD344D14EA086E
> >
> > and use the same passphrase, it works fine. Is there any way to
> > find out why a key-signing is failing?
>
> What does "echo $?" after it prints? IOW, maybe plain gpg fails too,
> without printing anything special, and you don't pay attention to the
> exit code. Git does. And it runs "gpg -bsau <key-id>".
$ git tag -s -F .git/TAG_EDITMSG tag_name
You need a passphrase to unlock the secret key for
user: "Joshua J. Kugler <joshua@azariah.com>"
1024-bit DSA key, ID 14EA086E, created 2009-08-09
gpg: problem with the agent - disabling agent use
error: gpg failed to sign the tag
error: unable to sign the tag
$ echo $?
128
And when I sign at the prompt:
$ gpg -sa
You need a passphrase to unlock the secret key for
user: "Joshua J. Kugler <joshua@azariah.com>"
1024-bit DSA key, ID 14EA086E, created 2009-08-09
gpg: problem with the agent - disabling agent use
Blah blah blah blah
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.9 (GNU/Linux)
owGbwMvMwCT46q+Jr8grjjzG01JJDF4fChqdchIzFJJQCK4ONxYGQSYGNlYmkAoG
Lk4BmLZpyxgW7Jol8mB6kt+Hr1xb9gvUnTs9f/XdVIYFW3VNlx3cmvy4sf/R0/m7
nr9fFpzyFQA=
=Plql
-----END PGP MESSAGE-----
$ echo $?
2
So, it appear that it works (prints the signature) but then exits with
an error code of 2.
Using --status-log, I get:
[GNUPG:] USERID_HINT EAFD344D14EA086E Joshua J. Kugler
<joshua@azariah.com>
[GNUPG:] NEED_PASSPHRASE EAFD344D14EA086E EAFD344D14EA086E 17 0
[GNUPG:] GOOD_PASSPHRASE
[GNUPG:] BEGIN_SIGNING
[GNUPG:] SIG_CREATED S 17 2 00 1257271594
4FE551A1A4AE4DEF7EDD58E1EAFD344D14EA086E
No indication of an error. The only thing I see that might be an error
is "gpg: problem with the agent - disabling agent use." But that should
be a warning, not an error, correct? I talked with somebody on the
gnupg IRC channel and they were able to create a signed tag, even
though they were not using an agent.
Here it is with -bsau:
$ gpg -bsau EAFD344D14EA086E
You need a passphrase to unlock the secret key for
user: "Joshua J. Kugler <joshua@azariah.com>"
1024-bit DSA key, ID 14EA086E, created 2009-08-09
gpg: problem with the agent - disabling agent use
Blah blah blah blah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAkrwciEACgkQ6v00TRTqCG7TZwCfSrvb6p0L+ZZqPB8XrVuMpJPj
jicAoJKnfIeTsWylXpklB9Gw/ArdxvxU
=CM2I
-----END PGP SIGNATURE-----
$ echo $?
2
I'm lost. Thanks for the tips.
j
--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0x14EA086E
^ permalink raw reply
* Re: Problem with "From:" line on "git format-patch" generated patches
From: André Goddard Rosa @ 2009-11-03 18:11 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <b8bf37780911031006q4bc4c487xd9db86eb0fa531e7@mail.gmail.com>
> I'm not using any specific tool for inputting the git-format-patch,
> but instead I'm sending the files generated by it through gmail as an
> inlined patch in the email body.
>
> I like the convenience of format-patch for generating the patch files,
> but in this case, formatting the header as rfc2047 is not necessary
> and makes a funny/garbled output in my patch submission.
>
> Do you have a suggestion for my workflow?
>
I really would like continuing having the convenience of using a web
access to my gmail for sending the patches, so I just need a way to
format the patches which makes it easy submitting them later. I'd like
to avoid using any other email client for that, if possible.
^ permalink raw reply
* Re: Problem with "From:" line on "git format-patch" generated patches
From: André Goddard Rosa @ 2009-11-03 18:06 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0911030902x15faffcen86644733ffda43d5@mail.gmail.com>
On 11/3/09, Santi Béjar <santi@agolina.net> wrote:
> On Tue, Nov 3, 2009 at 5:30 PM, André Goddard Rosa
> <andre.goddard@gmail.com> wrote:
>> Hi, everybody!
>>
>> When I generate patches using "git format-patch" it always makes
>> my name garbled in the "From:" line
>> as shown below. I'm using openSUSE 11.2 RC 1 (x86_64) with the
>> following settings:
>>
>> # locale charmap
>> UTF-8
>> # echo $LANG
>> en_US.UTF-8
>>
>> I've tried changing my environment to use another encoding like
>> ISO-8859-1, but it didn't work as well.
>>
>> Does someone can explain why does this happens? Any suggestions?
>>
>> P.s.: the problem never occurs on the commit message (Signed-off-by)
>>
>>>> >From 584d9bfc7c1d41b76a05655b4562b98fcbef6ee4 Mon Sep 17 00:00:00 2001
>>>> From: =?UTF-8?q?Andr=C3=A9=20Goddard=20Rosa?= <andre.goddard@gmail.com>
>>>> Date: Sun, 1 Nov 2009 14:09:06 -0200
>>>> Subject: [PATCH v2 7/7] vsprintf: factor out skip_space code in a
>>>> separate function
>>>> MIME-Version: 1.0
>>>> Content-Type: text/plain; charset=UTF-8
>>>> Content-Transfer-Encoding: 8bit
>
> This is the normal encoding for email headers where you cannot use
> 8bit characters. You have to use a 7bit characters with this
> =?UTF-8... encoding.
>
> You can check the From: line in your mail, the mail I'm replying:
>
> From: =?ISO-8859-1?Q?Andr=E9_Goddard_Rosa?= <andre.goddard@gmail.com>
>
> At the other hand the tools using the output of git-format-patch must
> deal with this all, as they do. git-am handles it well, if not it's a
> bug that should be reported.
>
Great, Santi!
I really appreciate your reply!!!
I was just in the process of debugging this issue when I landed
into function pp_user_info(), which calls add_rfc2047(). So I started
looking into http://www.faqs.org/rfcs/rfc2047.html , which specifies:
"Generally, an "encoded-word" is a sequence of printable ASCII
characters that begins with "=?", ends with "?=", and has two "?"s in
between."
Ok... I got it; it's necessary for proper signaling of the email
header when it detects the presence of certain characters outside the
ASCII range 0..127 (7 bits). It's the case for latin "é" letter in my
name.
So, let me explain what happened to me:
I'm not using any specific tool for inputting the git-format-patch,
but instead I'm sending the files generated by it through gmail as an
inlined patch in the email body.
I like the convenience of format-patch for generating the patch files,
but in this case, formatting the header as rfc2047 is not necessary
and makes a funny/garbled output in my patch submission.
Do you have a suggestion for my workflow?
Thanks a lot,
André
^ permalink raw reply
* Re: [PATCH 0/2] Set Makefile variables from configure
From: Ben Walton @ 2009-11-03 17:25 UTC (permalink / raw)
To: gitster, jrnieder, git
In-Reply-To: <1257021695-21260-1-git-send-email-bwalton@artsci.utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
Excerpts from Ben Walton's message of Sat Oct 31 16:41:33 -0400 2009:
Ping? Is this useful or should I drop it?
Thanks
-Ben
> These patches add support for setting the newly created DEFAULT_EDITOR
> and DEFAULT_PAGER from the configure script. I also tacked in
> ETC_GITCONFIG, since I can't currently toggle this without setting a
> command line value when building, but have need to alter it.
>
> The function added is generic, and will allow for setting new
> variables as needed in the future. No validation is done on the
> values. It is less specific than the *_PATH setting functions that
> already exist.
>
> Ben Walton (2):
> configure: add function to directly set Makefile variables
> configure: allow user to set gitconfig, pager and editor
>
> configure.ac | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with "From:" line on "git format-patch" generated patches
From: Santi Béjar @ 2009-11-03 17:02 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Git Mailing List
In-Reply-To: <b8bf37780911030830l42ea6dc2v3ef66e2a9e1ca281@mail.gmail.com>
On Tue, Nov 3, 2009 at 5:30 PM, André Goddard Rosa
<andre.goddard@gmail.com> wrote:
> Hi, everybody!
>
> When I generate patches using "git format-patch" it always makes
> my name garbled in the "From:" line
> as shown below. I'm using openSUSE 11.2 RC 1 (x86_64) with the
> following settings:
>
> # locale charmap
> UTF-8
> # echo $LANG
> en_US.UTF-8
>
> I've tried changing my environment to use another encoding like
> ISO-8859-1, but it didn't work as well.
>
> Does someone can explain why does this happens? Any suggestions?
>
> P.s.: the problem never occurs on the commit message (Signed-off-by)
>
>
>>> >From 584d9bfc7c1d41b76a05655b4562b98fcbef6ee4 Mon Sep 17 00:00:00 2001
>>> From: =?UTF-8?q?Andr=C3=A9=20Goddard=20Rosa?= <andre.goddard@gmail.com>
>>> Date: Sun, 1 Nov 2009 14:09:06 -0200
>>> Subject: [PATCH v2 7/7] vsprintf: factor out skip_space code in a
>>> separate function
>>> MIME-Version: 1.0
>>> Content-Type: text/plain; charset=UTF-8
>>> Content-Transfer-Encoding: 8bit
This is the normal encoding for email headers where you cannot use
8bit characters. You have to use a 7bit characters with this
=?UTF-8... encoding.
You can check the From: line in your mail, the mail I'm replying:
From: =?ISO-8859-1?Q?Andr=E9_Goddard_Rosa?= <andre.goddard@gmail.com>
At the other hand the tools using the output of git-format-patch must
deal with this all, as they do. git-am handles it well, if not it's a
bug that should be reported.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: SZEDER Gábor @ 2009-11-03 16:59 UTC (permalink / raw)
To: Junio C Hamano, David Brown; +Cc: git
In-Reply-To: <7vd447o0jp.fsf@alter.siamese.dyndns.org>
Hi,
> > From: David Brown <davidb@quicinc.com>
> >
> > 'git commit -s' will insert a blank line before the Signed-off-by
> > line at the end of the message, unless this last line is a
> > Signed-off-by line itself. Common use has other trailing lines
> > at the ends of commit text, in the style of RFC2822 headers.
> >
> > Be more generous in considering lines to be part of this footer.
> > If the last paragraph of the commit message reasonably resembles
> > RFC-2822 formatted lines, don't insert that blank line.
I think this patch was a bit too generous. If I make a one-line
commit message with git commit -s -m which has a colon in it, e.g.
'subsystem: what I did', then this patch removes the empty line
between the subject and the SOB line.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] commit -c/-C/--amend: acquire authorship and restamp time with --claim
From: Erick Mattos @ 2009-11-03 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskcxwro7.fsf@alter.siamese.dyndns.org>
I am gonna check all this information but you probably missed the last
patch I sent: http://marc.info/?l=git&m=125712272606721&w=2
Could you please check this one... while I am checking this e-mail.
Regards
2009/11/2 Junio C Hamano <gitster@pobox.com>:
> The last one was probably harder to read since it was an interdiff. Here
> is what I am considering to queue.
>
> No, I didn't use --mine option when I ran "commit --amend" to record this
> one ;-)
>
> -- >8 --
> From: Erick Mattos <erick.mattos@gmail.com>
> Date: Sun, 1 Nov 2009 16:45:27 -0200
> Subject: [PATCH] git commit --mine: ignore authorship information taken from -c/-C/--amend
>
> When we use -c, -C, or --amend, we are trying one of two things: using the
> source as a template or modifying a commit with corrections.
>
> When these options are are used, the authorship and timestamp recorded in
> the newly created commit is always taken from the original commit. This
> is inconvenient when you want to just borrow the commit log message, or
> your change is so significant that you should take over the authorship
> (with the blame for bugs you introduced).
>
> Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-commit.txt | 7 +++-
> builtin-commit.c | 10 +++-
> t/t7509-commit.sh | 103 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 116 insertions(+), 4 deletions(-)
> create mode 100755 t/t7509-commit.sh
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 0578a40..7832720 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -9,7 +9,7 @@ SYNOPSIS
> --------
> [verse]
> 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
> - [(-c | -C) <commit>] [-F <file> | -m <msg>]
> + [(-c | -C) <commit>] [-F <file> | -m <msg>] [--mine]
> [--allow-empty] [--no-verify] [-e] [--author=<author>]
> [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
>
> @@ -69,6 +69,11 @@ OPTIONS
> Like '-C', but with '-c' the editor is invoked, so that
> the user can further edit the commit message.
>
> +--mine::
> + When used with -C/-c/--amend options, declare that the
> + authorship of the resulting commit now belongs of the committer.
> + This also renews the author timestamp.
> +
> -F <file>::
> --file=<file>::
> Take the commit message from the given file. Use '-' to
> diff --git a/builtin-commit.c b/builtin-commit.c
> index beddf01..aa42989 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -51,7 +51,7 @@ static const char *template_file;
> static char *edit_message, *use_message;
> static char *author_name, *author_email, *author_date;
> static int all, edit_flag, also, interactive, only, amend, signoff;
> -static int quiet, verbose, no_verify, allow_empty, dry_run;
> +static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
> static char *untracked_files_arg;
> /*
> * The default commit message cleanup mode will remove the lines
> @@ -91,8 +91,9 @@ static struct option builtin_commit_options[] = {
> OPT_FILENAME('F', "file", &logfile, "read log from file"),
> OPT_STRING(0, "author", &force_author, "AUTHOR", "override author for commit"),
> OPT_CALLBACK('m', "message", &message, "MESSAGE", "specify commit message", opt_parse_m),
> - OPT_STRING('c', "reedit-message", &edit_message, "COMMIT", "reuse and edit message from specified commit "),
> + OPT_STRING('c', "reedit-message", &edit_message, "COMMIT", "reuse and edit message from specified commit"),
> OPT_STRING('C', "reuse-message", &use_message, "COMMIT", "reuse message from specified commit"),
> + OPT_BOOLEAN(0, "mine", &renew_authorship, "the commit is authored by me now (used with -C-c/--amend)"),
> OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
> OPT_FILENAME('t', "template", &template_file, "use specified template file"),
> OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
> @@ -381,7 +382,7 @@ static void determine_author_info(void)
> email = getenv("GIT_AUTHOR_EMAIL");
> date = getenv("GIT_AUTHOR_DATE");
>
> - if (use_message) {
> + if (use_message && !renew_authorship) {
> const char *a, *lb, *rb, *eol;
>
> a = strstr(use_message_buffer, "\nauthor ");
> @@ -747,6 +748,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
> if (force_author && !strchr(force_author, '>'))
> force_author = find_author_by_nickname(force_author);
>
> + if (force_author && renew_authorship)
> + die("Using both --mine and --author does not make sense");
> +
> if (logfile || message.len || use_message)
> use_editor = 0;
> if (edit_flag)
> diff --git a/t/t7509-commit.sh b/t/t7509-commit.sh
> new file mode 100755
> index 0000000..ec13cea
> --- /dev/null
> +++ b/t/t7509-commit.sh
> @@ -0,0 +1,103 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2009 Erick Mattos
> +#
> +
> +test_description='git commit --mine'
> +
> +. ./test-lib.sh
> +
> +author_header () {
> + git cat-file commit "$1" |
> + sed -n -e '/^$/q' -e '/^author /p'
> +}
> +
> +message_body () {
> + git cat-file commit "$1" |
> + sed -e '1,/^$/d'
> +}
> +
> +test_expect_success '-C option copies authorship and message' '
> + echo "Initial" >foo &&
> + git add foo &&
> + test_tick &&
> + git commit -m "Initial Commit" --author Frigate\ \<flying@over.world\> &&
> + git tag Initial &&
> + echo "Test 1" >>foo &&
> + test_tick &&
> + git commit -a -C Initial &&
> + author_header Initial >expect &&
> + author_header HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '-C option copies only the message with --mine' '
> + echo "Test 2" >>foo &&
> + test_tick &&
> + git commit -a -C Initial --mine &&
> + echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
> + author_header HEAD >actual
> + test_cmp expect actual &&
> +
> + message_body Initial >expect &&
> + message_body HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '-c option copies authorship and message' '
> + echo "Test 3" >>foo &&
> + test_tick &&
> + EDITOR=: VISUAL=: git commit -a -c Initial &&
> + author_header Initial >expect &&
> + author_header HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '-c option copies only the message with --mine' '
> + echo "Test 4" >>foo &&
> + test_tick &&
> + EDITOR=: VISUAL=: git commit -a -c Initial --mine &&
> + echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
> + author_header HEAD >actual &&
> + test_cmp expect actual &&
> +
> + message_body Initial >expect &&
> + message_body HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '--amend option copies authorship' '
> + git checkout Initial &&
> + echo "Test 5" >>foo &&
> + test_tick &&
> + git commit -a --amend -m "amend test" &&
> + author_header Initial >expect &&
> + author_header HEAD >actual &&
> +
> + echo "amend test" >expect &&
> + message_body HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '--mine makes the commit ours even with --amend option' '
> + git checkout Initial &&
> + echo "Test 6" >>foo &&
> + test_tick &&
> + git commit -a --mine -m "Changed again" --amend &&
> + echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
> + author_header HEAD >actual &&
> + test_cmp expect actual &&
> +
> + echo "Changed again" >expect &&
> + message_body HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '--mine and --author are mutually exclusive' '
> + git checkout Initial &&
> + echo "Test 7" >>foo &&
> + test_tick &&
> + test_must_fail git commit -a --mine --author="Xyzzy <frotz@nitfol.xz>"
> +'
> +
> +test_done
> --
> 1.6.5.2.246.gc99575
>
>
^ permalink raw reply
* Problem with "From:" line on "git format-patch" generated patches
From: André Goddard Rosa @ 2009-11-03 16:30 UTC (permalink / raw)
To: Git Mailing List
Hi, everybody!
When I generate patches using "git format-patch" it always makes
my name garbled in the "From:" line
as shown below. I'm using openSUSE 11.2 RC 1 (x86_64) with the
following settings:
# locale charmap
UTF-8
# echo $LANG
en_US.UTF-8
I've tried changing my environment to use another encoding like
ISO-8859-1, but it didn't work as well.
Does someone can explain why does this happens? Any suggestions?
P.s.: the problem never occurs on the commit message (Signed-off-by)
>> >From 584d9bfc7c1d41b76a05655b4562b98fcbef6ee4 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Andr=C3=A9=20Goddard=20Rosa?= <andre.goddard@gmail.com>
>> Date: Sun, 1 Nov 2009 14:09:06 -0200
>> Subject: [PATCH v2 7/7] vsprintf: factor out skip_space code in a
>> separate function
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>
> btw., for reviewability's sake, could you please fix your patch
> submission method to not include such garbled headers in the mail body?
>
> (Also, it would be nice to reply-thread the 7 patches on the 0/7 mail,
> as git-send-email does.)
Thank you,
André
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Sverre Rabbelier @ 2009-11-03 16:07 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <2e24e5b90911030800j22b00372r99a56c3f847a3644@mail.gmail.com>
Heya,
On Tue, Nov 3, 2009 at 17:00, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> At the command line, this gives you a detailed warning message, but the
> GUI currently allows it without any fuss.
This is even better than an annoying popup dialog, as we all know
those are just ignored anyway :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] gitk: disable checkout of remote branch
From: Sitaram Chamarty @ 2009-11-03 16:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
At the command line, this gives you a detailed warning message, but the
GUI currently allows it without any fuss.
Since the GUI is often used by people much less familiar with git, it
seems reasonable to make the GUI more restrictive than the command line,
not less.
This prevents a lot of detached HEAD commits by new users.
Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
---
gitk | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..95e27d4 100755
--- a/gitk
+++ b/gitk
@@ -8897,6 +8897,9 @@ proc headmenu {x y id head} {
set headmenuid $id
set headmenuhead $head
set state normal
+ if {[string match "remotes/*" $head]} {
+ set state disabled
+ }
if {$head eq $mainhead} {
set state disabled
}
--
1.6.5
^ permalink raw reply related
* Re: git subtree issues
From: Avery Pennarun @ 2009-11-03 15:43 UTC (permalink / raw)
To: morgflast; +Cc: git
In-Reply-To: <26159961.post@talk.nabble.com>
On Mon, Nov 2, 2009 at 11:56 PM, morgflast <daniel@sibblingz.com> wrote:
> git pull -s subtree vw_extensions master remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (3/3), done.
> remote: Total 3 (delta 2), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From git@github.com:sibblingz/vw_extensions
> * branch master -> FETCH_HEAD
> Already uptodate!
> Merge made by subtree.
>
> However, when I looked at the README file in the first project, the changes
> weren't there. I was wondering if anyone might have any suggestions about
> what to do.
Hmm, the output certainly wasn't very helpful :(
Usually what "already uptodate" means is that the commit it merged
didn't actually cause any changes. Is it possible there's another
README file that already contained this change?
The other problem with subtree merge is that it tries to *guess* which
subtree you want to merge, which unfortunately fails almost as often
as it succeeds. If it guessed incorrectly, it might have thrown away
all the directories except one that didn't change at all. If this is
the problem, I don't have an easy fix; my git-subtree command (which
makes it a bit easier to do the things you're trying to do in your
email) suffers from this too. Eventually I was thinking of giving in
and making subtree merge properly configurable, but I haven't had
time.
Or maybe this is a totally different problem. What do you get from:
git diff --stat $(git merge-base HEAD^ FETCH_HEAD) FETCH_HEAD
?
Avery
^ permalink raw reply
* Re: Common setting for interoperability repo across windows and unix?
From: Avery Pennarun @ 2009-11-03 15:33 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120911030709h29c5b8edr53df269632990e81@mail.gmail.com>
On Tue, Nov 3, 2009 at 11:09 AM, Dilip M <dilipm79@gmail.com> wrote:
> I have repo in unix. The same repo is cloned onto windows.I have set
> "core.autocrlf=input" in both the repos.
>
> When I do some change to a file in windows and push to unix repo, I
> get file deleted If I do "git status"?
>
> What is the setting to be done if I want an repo to be
> access/push/pulled across windows and unix?
It sounds like you are pushing to the currently-checked-out branch of
a non-bare repo.
If this is true, you should do one of the following:
- have a central "bare" repo (created with git init --bare) and
push/pull from that rather than directly
- pull, rather than push, when transferring data between repos.
You can pull from a Windows box by running git-daemon on that box from
the command line. (It's easier than it sounds.)
Have fun,
Avery
^ permalink raw reply
* Common setting for interoperability repo across windows and unix?
From: Dilip M @ 2009-11-03 15:09 UTC (permalink / raw)
To: git
Hello,
I have repo in unix. The same repo is cloned onto windows.I have set
"core.autocrlf=input" in both the repos.
When I do some change to a file in windows and push to unix repo, I
get file deleted If I do "git status"?
What is the setting to be done if I want an repo to be
access/push/pulled across windows and unix?
--
Dilip
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Junio C Hamano @ 2009-11-03 14:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Pat Thoyts, Johannes Sixt, Murphy, John, git
In-Reply-To: <19183.64129.695745.269570@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Junio C Hamano writes:
>
>> Even if you could, you would have the same issue giving them from the
>> command line anyway. The right solution would likely to be to give the
>> same --stdin option as rev-list to "git log", I think.
>
> A --stdin option to git log would be great, but it doesn't seem to be
> implemented yet. How hard would it be to add?
Fairly trivial. Only lightly tested with things like:
$ (echo ^master; echo next) | ./git log --stdin
$ (echo ^master; echo jc/log-tz) | ./git format-patch --stdin --stdout
I am not signing this off because...
- I do not want to think about what would happen if you give "-p" option,
nor if our "pager" infrastructure is set up to allow us to do a
sensible thing; and
- This disables --stdin for blame as it wants to read contents from its
standard input when given "-" as the file argument. I suspect there
probably are similar commands that use setup_revisions() and do not use
a "--stdin" option but still read from the standard input, and they
need to be fixed similarly, but I want somebody else to do the audit.
At least, not yet.
That is, making it work for "log" is trivial---making sure it won't break
unsuspecting bystanders is much more time-consuming work.
-- >8 --
Subject: teach --stdin to "log" family
Move the logic to read revs from standard input that rev-list knows about
from it to revision machinery, so that all the users of setup_revisions()
can feed the list of revs from the standard input when "--stdin" is used
on the command line.
Allow some users of the revision machinery that want different semantics
from the "--stdin" option to disable it by setting an option in the
rev_info structure.
This also cleans up the kludge made to bundle.c via cut and paste.
---
builtin-blame.c | 1 +
builtin-diff-tree.c | 1 +
builtin-rev-list.c | 7 -------
bundle.c | 7 -------
revision.c | 15 +++++++++++++--
revision.h | 4 ++--
6 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 7512773..b0aa530 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2352,6 +2352,7 @@ parse_done:
die_errno("cannot stat path '%s'", path);
}
+ revs.disable_stdin = 1;
setup_revisions(argc, argv, &revs, NULL);
memset(&sb, 0, sizeof(sb));
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index 79cedb7..2380c21 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -104,6 +104,7 @@ int cmd_diff_tree(int argc, const char **argv, const char *prefix)
git_config(git_diff_basic_config, NULL); /* no "diff" UI options */
opt->abbrev = 0;
opt->diff = 1;
+ opt->disable_stdin = 1;
argc = setup_revisions(argc, argv, opt, NULL);
while (--argc > 0) {
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 42cc8d8..f6a56f3 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -306,7 +306,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
struct rev_info revs;
struct rev_list_info info;
int i;
- int read_from_stdin = 0;
int bisect_list = 0;
int bisect_show_vars = 0;
int bisect_find_all = 0;
@@ -349,12 +348,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_show_vars = 1;
continue;
}
- if (!strcmp(arg, "--stdin")) {
- if (read_from_stdin++)
- die("--stdin given twice?");
- read_revisions_from_stdin(&revs);
- continue;
- }
usage(rev_list_usage);
}
diff --git a/bundle.c b/bundle.c
index df95e15..a7c9987 100644
--- a/bundle.c
+++ b/bundle.c
@@ -204,7 +204,6 @@ int create_bundle(struct bundle_header *header, const char *path,
int i, ref_count = 0;
char buffer[1024];
struct rev_info revs;
- int read_from_stdin = 0;
struct child_process rls;
FILE *rls_fout;
@@ -257,12 +256,6 @@ int create_bundle(struct bundle_header *header, const char *path,
argc = setup_revisions(argc, argv, &revs, NULL);
for (i = 1; i < argc; i++) {
- if (!strcmp(argv[i], "--stdin")) {
- if (read_from_stdin++)
- die("--stdin given twice?");
- read_revisions_from_stdin(&revs);
- continue;
- }
return error("unrecognized argument: %s'", argv[i]);
}
diff --git a/revision.c b/revision.c
index 9fc4e8d..45c5de8 100644
--- a/revision.c
+++ b/revision.c
@@ -953,7 +953,7 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
-void read_revisions_from_stdin(struct rev_info *revs)
+static void read_revisions_from_stdin(struct rev_info *revs)
{
char line[1000];
@@ -1227,7 +1227,7 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
*/
int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def)
{
- int i, flags, left, seen_dashdash;
+ int i, flags, left, seen_dashdash, read_from_stdin;
/* First, search for "--" */
seen_dashdash = 0;
@@ -1245,6 +1245,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
/* Second, deal with arguments and options */
flags = 0;
+ read_from_stdin = 0;
for (left = i = 1; i < argc; i++) {
const char *arg = argv[i];
if (*arg == '-') {
@@ -1283,6 +1284,16 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
revs->no_walk = 0;
continue;
}
+ if (!strcmp(arg, "--stdin")) {
+ if (revs->disable_stdin) {
+ argv[left++] = arg;
+ continue;
+ }
+ if (read_from_stdin++)
+ die("--stdin given twice?");
+ read_revisions_from_stdin(revs);
+ continue;
+ }
opts = handle_revision_opt(revs, argc - i, argv + i, &left, argv);
if (opts > 0) {
diff --git a/revision.h b/revision.h
index b6421a6..f64637b 100644
--- a/revision.h
+++ b/revision.h
@@ -83,6 +83,8 @@ struct rev_info {
use_terminator:1,
missing_newline:1,
date_mode_explicit:1;
+ unsigned int disable_stdin:1;
+
enum date_mode date_mode;
unsigned int abbrev;
@@ -128,8 +130,6 @@ struct rev_info {
#define REV_TREE_DIFFERENT 3 /* Mixed changes */
/* revision.c */
-void read_revisions_from_stdin(struct rev_info *revs);
-
typedef void (*show_early_output_fn_t)(struct rev_info *, struct commit_list *);
extern volatile show_early_output_fn_t show_early_output;
^ permalink raw reply related
* Re: Error in Git
From: Nicolas Sebrecht @ 2009-11-03 12:18 UTC (permalink / raw)
To: Ravindra; +Cc: git, Nicolas Sebrecht
In-Reply-To: <4AEFEF22.9000909@globaledgesoft.com>
The 03/11/09, Ravindra wrote:
> When i execute the git command for the url
> git://git.openezx.org/sgh-i900.git I am getting the following error,
> Please let me know how to solve this.
It really looks like a problem coming from the remote side only. I'm not
sure why. You should contact the admin of the repository.
> error: waitpid (async) failed fatal: error in sideband demultiplexer
I've had a similar error here :
% git clone git://git.openezx.org/sgh-i900.git
Initialized empty Git repository in /tmp/sgh-i900/.git/
remote: Counting objects: 128422, done.
remote: Compressing objects: 100% (122355/122355), done.
remote: Total 128422 (delta 6110), reused 128357 (delta 6067)
remote: aborting due to possible repository corruption on the remote side.
Receiving objects: 100% (128422/128422), 46.32 MiB | 519 KiB/s, done.
Resolving deltas: 100% (6110/6110), done.
fatal: error in sideband demultiplexer
%
And at my first try :
% git clone git://git.openezx.org/sgh-i900.git
Initialized empty Git repository in /tmp/sgh-i900/.git/
remote: fatal: Out of memory, realloc failed
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
%
% git --version
git version 1.6.5.2.293.ge3812c
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Error in Git
From: Sverre Rabbelier @ 2009-11-03 12:15 UTC (permalink / raw)
To: Ravindra; +Cc: git
In-Reply-To: <4AEFEF22.9000909@globaledgesoft.com>
Heya,
On Tue, Nov 3, 2009 at 09:51, Ravindra
<ravindra.kulkarni@globaledgesoft.com> wrote:
> When i execute the git command for the url
> git://git.openezx.org/sgh-i900.git I am getting the following error,
> Please let me know how to solve this.
I just tried, and to be more precise, the error is at clone time:
$ GIT_TRACE=1 git clone git://git.openezx.org/sgh-i900.git
trace: built-in: git 'clone' 'git://git.openezx.org/sgh-i900.git'
Initialized empty Git repository in /home/sverre/code/sgh-i900/.git/
trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin'
'--keep=fetch-pack 2980 on LAPTOP-SVERRE'
trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin'
'--keep=fetch-pack 2980 on LAPTOP-SVERRE'
trace: exec: 'git-index-pack' '--stdin' '-v' '--fix-thin'
'--keep=fetch-pack 2980 on LAPTOP-SVERRE'
trace: run_command: 'git-index-pack' '--stdin' '-v' '--fix-thin'
'--keep=fetch-pack 2980 on LAPTOP-SVERRE'
remote: Counting objects: 128422, done.
remote: Compressing objects: 100% (122355/122355), done.
remote: Total 128422 (delta 6110), reused 128357 (delta 6067)
remote: aborting due to possible repository corruption on the remote side.
Receiving objects: 100% (128422/128422), 46.32 MiB | 1.41 MiB/s, done.
Resolving deltas: 100% (6110/6110), done.
fatal: error in sideband demultiplexer
No clue what's wrong though, just wanted to save other people some time :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] gitk: Add configuration for UI colour scheme (menus, scrollbars, etc)
From: Paul Mackerras @ 2009-11-03 11:32 UTC (permalink / raw)
To: Guillermo S. Romero; +Cc: git
In-Reply-To: <20091015165149.GA28219@crossbow.battleship>
Guillermo S. Romero writes:
> Add option to control global colour scheme in Edit > Preferences dialog
> so the whole interface can have other color beyond the default one
> and match changes to other areas controlled by bgcolor and fgcolor.
>
> Signed-off-by: Guillermo S. Romero <gsromero@infernal-iceberg.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: fix typo when diffing committed -> staged
From: Paul Mackerras @ 2009-11-03 11:32 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AE72A46.5040201@web.de>
Jens Lehmann writes:
> When highlighting a commit, using the context menu over the staged changes
> and then selecting "Diff this -> selected" the diff was empty. The same
> happened when highlighting the staged changes and using "Diff selected ->
> this" over a commit.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] Skip translation of wrong Tcl version text
From: Paul Mackerras @ 2009-11-03 11:31 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Pat Thoyts, git
In-Reply-To: <87ljipje03.fsf@gollum.intra.norang.ca>
Bernt Hansen writes:
> We check the required Tcl version number before we setup msgcat for
> language translation. If the Tcl version is too old just display the
> untranslated error text.
>
> The caller of show_error can now pass an alternative function for mc.
> The Tcl list function turns the transalation into a no-op.
>
> This fixes the
> Error in startup script: invalid command name "mc"
> when attempting to start gitk with Tcl 8.3.
>
> Signed-off-by: Bernt Hansen <bernt@norang.ca>
Thanks, applied.
Paul.
^ 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