* Re: A typesetting problem with git man pages
From: Teemu Likonen @ 2008-10-31 8:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <8763n9tduo.fsf@iki.fi>
Teemu Likonen (2008-10-31 09:37 +0200) wrote:
> Alas, there are still problems - or at least I have. Let's look at the
> "git checkout" manual page and its output in the "EXAMPLES" section:
>
>
> $ git checkout master âfB(1)âfR
> $ git checkout master~2 Makefile âfB(2)âfR
> $ rm -f hello.c
> $ git checkout hello.c âfB(3)âfR
> â
> âfB1. âfRswitch branch â
> âfB2. âfRtake out a file out of other commit â
> âfB3. âfRrestore hello.c from HEAD of current branch
This has been reported to Debian so perhaps the issue is
Debian-specific. I don't know. The bug was found in Debian git-core
package version 1:1.5.6-1.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490863
^ permalink raw reply
* Re: request for pre-generated git.info pages
From: Kalle Olavi Niemitalo @ 2008-10-30 23:06 UTC (permalink / raw)
To: git
In-Reply-To: <ee2a733e0810291500o67b3f94fibef63e0a173e8cc1@mail.gmail.com>
"Leo Razoumov" <slonik.az@gmail.com> writes:
> I am an emacs user but with my current setup I have difficulties
> generating git.info pages.
This bug in docbook2x 0.8.8 can result in empty *.texi files:
http://sourceforge.net/tracker/index.php?func=detail&aid=1912754&group_id=7856&atid=107856
`db2x_teximl' does not honor `--to-stdout'
With docbook2x 0.8.3, I successfully built git.info and gitman.info.
However, the Info browser does not recognize cross-references
between them. I am playing with some patches to fix those.
^ permalink raw reply
* Re: request for pre-generated git.info pages
From: Kalle Olavi Niemitalo @ 2008-10-31 0:19 UTC (permalink / raw)
To: git
In-Reply-To: <8763n98yz7.fsf@Astalo.kon.iki.fi>
Kalle Olavi Niemitalo <kon@iki.fi> writes:
> However, the Info browser does not recognize cross-references
> between them. I am playing with some patches to fix those.
This seems to fix it, although the result isn't pretty.
Not signed off.
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 62269e3..56e1cf5 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -184,12 +184,12 @@ git.info: user-manual.texi
user-manual.texi: user-manual.xml
$(RM) $@+ $@
- $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
+ $(DOCBOOK2X_TEXI) -s texi.xsl user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
mv $@+ $@
gitman.texi: $(MAN_XML) cat-texi.perl
$(RM) $@+ $@
- ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
+ ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) -s texi.xsl --to-stdout $(xml);)) | \
$(PERL_PATH) cat-texi.perl $@ >$@+
mv $@+ $@
diff --git a/Documentation/texi.xsl b/Documentation/texi.xsl
new file mode 100644
index 0000000..5c6f4cd
--- /dev/null
+++ b/Documentation/texi.xsl
@@ -0,0 +1,17 @@
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ xmlns="http://docbook2x.sourceforge.net/xmlns/Texi-XML"
+ version="1.0">
+ <!-- docbook2x 0.8.3 recognizes sf.net but not sourceforge.net. -->
+ <xsl:import href="http://docbook2x.sf.net/latest/xslt/texi/docbook.xsl"/>
+
+ <!-- In a man page, asciidoc.conf expands linkgit to citerefentry.
+ Each man page goes in gitman.texi so ref/@file is not needed. -->
+ <xsl:template match="citerefentry[starts-with(refentrytitle, 'git')]">
+ <ref node="{refentrytitle}" />
+ </xsl:template>
+
+ <!-- In Git User's Manual, user-manual.conf expands linkgit to ulink. -->
+ <xsl:template match="ulink[starts-with(@url, 'git') and substring(@url, string-length(@url) - 4) = '.html']">
+ <ref node="{substring(@url, 1, string-length(@url) - 5)}" file="gitman.info" />
+ </xsl:template>
+</xsl:stylesheet>
^ permalink raw reply related
* Re: [PATCH 1/9] close another possibility for propagating pack corruption
From: Junio C Hamano @ 2008-10-31 8:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <1225321372-6570-2-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> writes:
> Abstract
> --------
>
> With index v2 we have a per object CRC to allow quick and safe reuse of
> pack data when repacking. this, however, doesn't currently prevent a
s/this/This/;
> stealth corruption from being propagated into a new pack when _not_
> reusing pack data as demonstrated by the modification to t5302 included
> here.
>
> The Context
> -----------
>
> The Git database is all checksumed with SHA1 hashes. Any kind of
s/checksumed/checksummed/;
> ...
> What about the streamed pack case? Well, any client receiving a pack
> must always consider that pack as untrusty and perform full validation
> anyway, hence no such stealth corruption could be propagated to remote
> repositoryes already. It is therefore worthless doing local validation
> in that case.
Very nicely done. I've never seen a commit message that needs its own
Abstract ;-)
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 59c30d1..0366277 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1689,6 +1689,8 @@ static int add_ref_tag(const char *path, const unsigned char *sha1, int flag, vo
> return 0;
> }
>
> +extern int do_check_packed_object_crc;
> +
This ought to belong to cache.h or some other header file. Perhaps you
did this to avoid unnecessary recompilation (we've discussed this at
GitTogether)?
> @@ -1697,6 +1699,16 @@ static void prepare_pack(int window, int depth)
>
> get_object_details();
>
> + /*
> + * If we're locally repacking then we need to be doubly careful
> + * from now on in order to make sure no stealth corruption gets
> + * propagated to the new pack. Clients receiving streamed packs
> + * should validate everything they get anyway so no need to incure
s/incure/incur/;
^ permalink raw reply
* [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2008-10-31 9:26 UTC (permalink / raw)
To: git; +Cc: pasky, srabbelier, Pierre Habouzit
In-Reply-To: <20081030132623.GC24098@artemis.corp>
git_commit_non_empty_tree is added to the functions that can be run from
commit filters. Its effect is to commit only commits actually touching the
tree and that are not merge points either.
The option --prune-empty is added. It defaults the commit-filter to
'git_commit_non_empty_tree "$@"', and can be used with any other
combination of filters, except --commit-hook that must used
'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
usually to achieve the same result.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Okay, this one is meant for inclusion, and has a test case.
Note that this prune-empty option is not 100% perfect, for example, it won't
prune an empty base (an empty commit whose parent is 0000000) since it has
no parent, or won't reduce histories this way:
t0---t1---t1 t0---t1
/ ----> /
t2 t2
But I don't think it's especially bad since such trees happen when one does
'git merge -s ours' all the time, and I don't think git-filter-branch should
erase those (I mean some people may want to, but then they can figure out
how to do that by themselves, I don't think it's a common wish).
The goal of --prune-empty is rather meant to be used e.g. when you remove a
file from your history, and want to get rid of commits that only touched it,
or that you want to extract the history of a given subdirectory only and
remove commits that didn't touch that directory.
Documentation/git-filter-branch.txt | 14 ++++++++++++++
git-filter-branch.sh | 29 ++++++++++++++++++++++++++++-
t/t7003-filter-branch.sh | 8 ++++++++
3 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index fed6de6..451950b 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -122,6 +122,10 @@ You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
that, use 'git-rebase' instead).
++
+You can also use the 'git_commit_non_empty_tree "$@"' instead of
+'git commit-tree "$@"' if you don't wish to keep commits with a single parent
+and that makes no change to the tree.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -151,6 +155,16 @@ to other tags will be rewritten to point to the underlying commit.
The result will contain that directory (and only that) as its
project root.
+--prune-empty::
+ Some kind of filters will generate empty commits, that left the tree
+ untouched. This switch allow git-filter-branch to ignore such
+ commits. Though, this switch only applies for commits that have one
+ and only one parent, it will hence keep merges points. Also, this
+ option is not compatible with the use of '--commit-filter'. Though you
+ just need to use the function 'git_commit_non_empty_tree "$@"' instead
+ of the 'git commit-tree "$@"' idiom in your commit filter to make that
+ happen.
+
--original <namespace>::
Use this option to set the namespace where the original commits
will be stored. The default value is 'refs/original'.
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 81392ad..4827934 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -40,6 +40,16 @@ skip_commit()
done;
}
+# if you run 'git_commit_non_empty_tree "$@"' in a commit filter,
+# it will skip commits that leave the tree untouched, commit the other.
+git_commit_non_empty_tree()
+{
+ if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
+ map "$3"
+ else
+ git commit-tree "$@"
+ fi
+}
# override die(): this version puts in an extra line break, so that
# the progress is still visible
@@ -109,11 +119,12 @@ filter_tree=
filter_index=
filter_parent=
filter_msg=cat
-filter_commit='git commit-tree "$@"'
+filter_commit=
filter_tag_name=
filter_subdir=
orig_namespace=refs/original/
force=
+prune_empty=
while :
do
case "$1" in
@@ -126,6 +137,11 @@ do
force=t
continue
;;
+ --prune-empty)
+ shift
+ prune_empty=t
+ continue
+ ;;
-*)
;;
*)
@@ -176,6 +192,17 @@ do
esac
done
+case "$prune_empty,$filter_commit" in
+',')
+ filter_commit='git commit-tree "$@"';;
+'t,')
+ filter_commit="$functions;"' git_commit_non_empty_tree "$@"';;
+','*)
+ ;;
+*)
+ die "Cannot set --prune-empty and --filter-commit at the same time"
+esac
+
case "$force" in
t)
rm -rf "$tempdir"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index b0a9d7d..352b56b 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
test_cmp expect actual
'
+test_expect_success 'Prune empty commits' '
+ make_commit to_remove &&
+ (git rev-list HEAD | grep -v $(git rev-parse HEAD)) > expect &&
+ git filter-branch -f --index-filter "git update-index --remove to_remove" --prune-empty HEAD &&
+ git rev-list HEAD > actual &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.0.3.757.gf86e6.dirty
^ permalink raw reply related
* Are binary xdeltas only used if you use git-gc?
From: Thanassis Tsiodras @ 2008-10-31 9:43 UTC (permalink / raw)
To: git
Hi everyone.
I've been usig Git for the last couple of months and am quite happy with it.
In one of my Git repositories, I am storing uncompressed .tar files
(since being uncompressed allows git to detect and store
only their "real"differences).
However, when I introduce a new filename in the repos (with a minor
set of differences compared to an existing file with a different filename)
I've been unsuccessful in finding a way to tell Git to do it efficiently...
This is what I mean:
bash$ mkdir -p /var/tmp/tst
bash$ cd /var/tmp/tst
bash$ git init
bash$ cp /var/www/renderer-2.0e.tar .
bash$ git add renderer-2.0e.tar
bash$ git commit -m "First version"
bash$ du -s -k .git/
1724 .git/
bash$ cp renderer-2.0e.tar renderer-2.0f.tar
bash$ git add renderer-2.0f.tar
bash$ git commit -m "To add new version, first copy the first, so Git
detects it"
bash$ du -s -k .git/
1740 .git/
bash$ echo Good, Git detected it is the same
bash$ cp /var/www/renderer-2.0f.tar .
bash$ git add renderer-2.0f.tar
bash$ git commit -m "Real new version, slightly different to first"
bash$ du -s -k .git/
3344 .git/
bash$ echo What... did I do something wrong
bash$ xdelta delta renderer-2.0e.tar renderer-2.0f.tar delta
bash$ ls -l
total 7788
-rw-r--r-- 1 ttsiod ttsiod 8181 2008-10-31 11:27 delta
-rw-r--r-- 1 ttsiod ttsiod 3962880 2008-10-31 11:23 renderer-2.0e.tar
-rw-r--r-- 1 ttsiod ttsiod 3993600 2008-10-31 11:25 renderer-2.0f.tar
bash$ git-gc
bash$ du -s -k .git/
1660 .git/
So even though the xdelta is just 8KB, and git-gc actually finds out
that indeed
the new file is very similar to the old one, the initial commit of the
new version
in the repos is not taking advantage.
I found out about this when I tried to "git push" over a PSTN modem...
Then again, I must confess I only did the git-gc after I pushed.
Does the git-push actually take advantage of the similarities only if
I do a git-gc first?
If that is the case, I will create an alias to always git-gc after commits...
--
What I gave, I have; what I spent, I had; what I kept, I lost. -Old Epitaph
^ permalink raw reply
* [PATCH 1/3] git send-email: avoid leaking directory file descriptors.
From: Pierre Habouzit @ 2008-10-31 10:57 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225450632-7230-1-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-send-email.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index bdbfac6..94ca5c8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -374,10 +374,9 @@ for my $f (@ARGV) {
push @files, grep { -f $_ } map { +$f . "/" . $_ }
sort readdir(DH);
-
+ closedir(DH);
} elsif (-f $f or -p $f) {
push @files, $f;
-
} else {
print STDERR "Skipping $f - not found.\n";
}
--
1.6.0.3.759.g40a2.dirty
^ permalink raw reply related
* [PATCH 2/3] git send-email: interpret unknown files as revision lists
From: Pierre Habouzit @ 2008-10-31 10:57 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225450632-7230-2-git-send-email-madcoder@debian.org>
Instead of skipping unkown files on the command line, pass them through
git format-patch into a safe temporary directory. This allow no
complicated rev-list option lists combining "--all" "--not" and so on, but
allow to use ranges which are quite enough for most of the use cases.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 82f5056..cafff1a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -8,7 +8,7 @@ git-send-email - Send a collection of patches as emails
SYNOPSIS
--------
-'git send-email' [options] <file|directory> [... file|directory]
+'git send-email' [options] <file|directory|rev-list>...
DESCRIPTION
diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..0d50ee2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -22,6 +22,7 @@ use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
use Term::ANSIColor;
+use File::Temp qw/ tempdir /;
use Git;
package FakeTerm;
@@ -38,7 +39,7 @@ package main;
sub usage {
print <<EOT;
-git send-email [options] <file | directory>...
+git send-email [options] <file | directory | rev-list >
Composing:
--from <str> * Email From:
@@ -378,7 +379,8 @@ for my $f (@ARGV) {
} elsif (-f $f or -p $f) {
push @files, $f;
} else {
- print STDERR "Skipping $f - not found.\n";
+ my $tempdir = tempdir(CLEANUP => 1);
+ push @files, $repo->command('format-patch', '-o', $tempdir, $f);
}
}
--
1.6.0.3.759.g40a2.dirty
^ permalink raw reply related
* [PATCH 3/3] git send-email: add --annotate option
From: Pierre Habouzit @ 2008-10-31 10:57 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225450632-7230-3-git-send-email-madcoder@debian.org>
This allows to review every patch (and fix various aspects of them, or
comment them) in an editor just before being sent. Combined to the fact
that git send-email can now process revision lists, this makes git
send-email and efficient way to review and send patches interactively.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-send-email.txt | 11 +++++++++++
git-send-email.perl | 26 ++++++++++++++++++++++++--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index cafff1a..9ee81d5 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -37,6 +37,11 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
+--annotate::
+ Review each patch you're about to send in an editor. The setting
+ 'sendemail.multiedit' defines if this will spawn one editor per patch
+ or one for all of them at once.
+
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
@@ -204,6 +209,12 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+sendemail.multiedit::
+ If true (default), a single editor instance will be spawned to edit
+ files you have to edit (patches when '--annotate' is used, and the
+ summary when '--compose' is used). If false, files will be edited one
+ after the other, spawning a new editor each time.
+
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index 0d50ee2..65c254d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -48,6 +48,7 @@ git send-email [options] <file | directory | rev-list >
--bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
+ --annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
Sending:
@@ -130,7 +131,8 @@ my $compose_filename = ".msg.$$";
# Variables we fill in automatically, or via prompting:
my (@to,@cc,@initial_cc,@bcclist,@xh,
- $initial_reply_to,$initial_subject,@files,$author,$sender,$smtp_authpass,$compose,$time);
+ $initial_reply_to,$initial_subject,@files,
+ $author,$sender,$smtp_authpass,$annotate,$compose,$time);
my $envelope_sender;
@@ -151,6 +153,17 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
+# Handle interactive edition of files.
+my $multiedit;
+my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+sub do_edit {
+ if (defined($multiedit) && !$multiedit) {
+ map { system('sh', '-c', $editor.' "$@"', $editor, $_); } @_;
+ } else {
+ system('sh', '-c', $editor.' "$@"', $editor, @_);
+ }
+}
+
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
@@ -180,6 +193,7 @@ my %config_settings = (
"aliasesfile" => \@alias_files,
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
+ "multiedit" => \$multiedit,
);
# Handle Uncouth Termination
@@ -222,6 +236,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-ssl" => sub { $smtp_encryption = 'ssl' },
"smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
+ "annotate" => \$annotate,
"compose" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
@@ -499,7 +514,12 @@ EOT
close(C);
my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
- system('sh', '-c', $editor.' "$@"', $editor, $compose_filename);
+
+ if ($annotate) {
+ do_edit($compose_filename, @files);
+ } else {
+ do_edit($compose_filename);
+ }
open(C2,">",$compose_filename . ".final")
or die "Failed to open $compose_filename.final : " . $!;
@@ -548,6 +568,8 @@ EOT
}
@files = ($compose_filename . ".final", @files);
+} elsif ($annotate) {
+ do_edit(@files);
}
# Variables we set as part of the loop over files
--
1.6.0.3.759.g40a2.dirty
^ permalink raw reply related
* git send-email improvements
From: Pierre Habouzit @ 2008-10-31 10:57 UTC (permalink / raw)
To: git
The teaser
==========
This series has been sent using:
git send-email --to git@vger.kernel.org --compose --annotate HEAD~3..
The series
==========
Here is a patch series to improve git send-email following our
discussions at GitTogether'08, despite my hate for perl.
The first patch is a minor nitpick, because leaking fd's sucks.
The second patch allow git-send-email to receive revision lists as
arguments. This doesn't allow complex arguments combinations as it
proces the revision lists one by one (IOW ^$sha1 $sha2 won't work as
expected _at all_) but this shouldn't be a problem since this command is
primarily used for interactive users. People wanting to use
git-send-email with complex revision lists through scripts MUST
git-format-patch first into a safe temporary directory and use
git-send-email on this afterwards.
The last patch adds the possibility to review patches into an editor
before sending them, which allow you (thanks to patch 2) to serialize,
review, annotate, and send patches in one command.
Further discussion
==================
I think one could make git send-email better doing this:
(1) make --compose and --annotate default, do not asking for a Subject
if it's missing, neither should we ask for the in-reply-to if it's
missing.
Then spawn the editor with a first empty file that contains rougly a
template looking like this:
----8<----
GIT: Purge this buffer from any content if you don't want a series summary
GIT:
GIT: Lines beginning in "GIT: " will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
GIT:
GIT: Please fill a Subject if missing
GIT: Leave the In-Reply-To field empty if not applicable.
Subject:
In-Reply-To:
--> <we may want to add some more headers here: To/Cc/Bcc/...>
GIT: put the content of the mail below this line
GIT: [PATCH 1/10] .... \
GIT: [PATCH 2/10] .... | this would contain all the Subject's
[...] | from the commits that are beeing sent
GIT: [PATCH 8/10] .... | as a conveniency for people not
GIT: [PATCH 9/10] .... | having to cut&paste them
GIT: [PATCH 10/10] .... /
---->8----
I suggest we don't enable --compose when the series is reduced to
one patch, as the usual way is to comment inline. This is probably
arguable.
(2) Introduce a --batch option that basically:
* turns --compose and --annotate off
* turns any interactive feature off
* complain (and fail) if it misses any information that is usually
asked interactively
What do you think ?
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Pierre Habouzit @ 2008-10-31 11:02 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: git
In-Reply-To: <f1d2d9ca0810310243r669840bbj2c5ee7183e0caaed@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Fri, Oct 31, 2008 at 09:43:43AM +0000, Thanassis Tsiodras wrote:
> So even though the xdelta is just 8KB, and git-gc actually finds out
> that indeed
> the new file is very similar to the old one, the initial commit of the
> new version
> in the repos is not taking advantage.
Have you tried to git repack with aggressive options, like:
git repack --window=500 --depth=500 \
--window-memory=<fair amount of your physical RAM>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo-n` in tests.
From: Steve Folly @ 2008-10-31 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzat89br.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> Brian Gernhardt <benji <at> silverinsanity.com> writes:
>
> > Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> > is far more portable.
> >
> > Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
> > the test scripts.
>
> I had an impression that OS X was BSDish. Wasn't "echo -n" a BSDism?
>
FYI, "man echo" on OS X 10.5.5 has this to say...
The following option is available:
-n Do not print the trailing newline character. This may also be
achieved by appending `\c' to the end of the string, as is done by
iBCS2 compatible systems. Note that this option as well as the
effect of `\c' are implementation-defined in IEEE Std 1003.1-2001
(``POSIX.1'') as amended by Cor. 1-2002. Applications aiming for
maximum portability are strongly encouraged to use printf(1) to
suppress the newline character.
Some shells may provide a builtin echo command which is similar or iden-
tical to this utility. Most notably, the builtin echo in sh(1) does not
accept the -n option. Consult the builtin(1) manual page.
Regards,
Steve.
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Jakub Narebski @ 2008-10-31 11:15 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: git
In-Reply-To: <f1d2d9ca0810310243r669840bbj2c5ee7183e0caaed@mail.gmail.com>
"Thanassis Tsiodras" <ttsiodras@gmail.com> writes:
> I've been usig Git for the last couple of months and am quite happy with it.
> In one of my Git repositories, I am storing uncompressed .tar files
> (since being uncompressed allows git to detect and store
> only their "real"differences).
I think you can use clean / smudge filter in gitattributes for that.
[...]
> Then again, I must confess I only did the git-gc after I pushed.
> Does the git-push actually take advantage of the similarities only if
> I do a git-gc first?
Git does deltification _only_ in packfiles. But when you push via SSH
git would generate a pack file with commits the other side doesn't
have, and those packs are thin packs, so they also have deltas... but
the remote side then adds bases to those thin packs making them
standalone: you would have to git-gc on remote.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Thanassis Tsiodras @ 2008-10-31 11:16 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081031110245.GA22633@artemis.corp>
Actually, after using git-gc, git-repack isn't really needed...
git-gc identifies that the two files are very similar and re-deltifies
(see the du -s -k outputs in the original mail, after git-gc we have
in fact lower usage than the first commit).
My question is basically...
(a) why doesn't git detect this during commit and needs a git-gc
(b) whether after git-gc I would have seen the massive difference
during a subsequent git-push or not
Thanassis.
> Have you tried to git repack with aggressive options, like:
>
> git repack --window=500 --depth=500 \
> --window-memory=<fair amount of your physical RAM>
--
What I gave, I have; what I spent, I had; what I kept, I lost. -Old Epitaph
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Thanassis Tsiodras @ 2008-10-31 11:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m37i7pggnk.fsf@localhost.localdomain>
On Fri, Oct 31, 2008 at 1:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> I think you can use clean / smudge filter in gitattributes for that.
Thanks, I didn't know about that. Will look into it
> Git does deltification _only_ in packfiles. But when you push via SSH
> git would generate a pack file with commits the other side doesn't
> have, and those packs are thin packs, so they also have deltas... but
> the remote side then adds bases to those thin packs making them
> standalone: you would have to git-gc on remote.
So I have to git-gc on my side (after the commits), git-gc on the remote,
and then git-push?
What I gave, I have; what I spent, I had; what I kept, I lost. -Old Epitaph
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Kyle Moffett @ 2008-10-31 11:38 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: Sam Vilain, git
In-Reply-To: <d4bc1a2a0810300355q42b35a35p2ba0e778691a0ab6@mail.gmail.com>
On Thu, Oct 30, 2008 at 6:55 AM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain <sam@vilain.net> wrote:
>> + * 'git export' command that does what
>> + 'git archive --format=tar --prefix=dir | tar x' does now
>
> It would be nice if the "git export" command could "checkout" a
> non-repo copy of a remote repo at a specific version. This would be as
> simple as calling archive on the remote size and then unarchiving it
> locally. But would of course take care of all the plumbing.
I'm not sure whether the "git archive | tar" or the following is more efficient:
export GIT_INDEX_FILE="$(mktemp .git/export-index.XXXXXX)"
git read-tree -i "$1"
git checkout-index -f -a --prefix="$2/"
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: why not TortoiseGit
From: Ian Hilt @ 2008-10-31 12:19 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE96125890@zch01exm23.fsl.freescale.net>
On Fri, Oct 31, 2008 at 09:44:45AM +0800, Li Frank-B20596 wrote:
> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg
> Why not ToroiseGit
This is what Johannes Schindelin had to say,
<http://code.google.com/p/msysgit/wiki/GitCheetah>
^ permalink raw reply
* Re: why not TortoiseGit
From: Andreas Ericsson @ 2008-10-31 12:35 UTC (permalink / raw)
To: Ian Hilt; +Cc: Li Frank-B20596, git
In-Reply-To: <20081031121913.GE18221@sys-0.hiltweb.site>
Ian Hilt wrote:
> On Fri, Oct 31, 2008 at 09:44:45AM +0800, Li Frank-B20596 wrote:
>> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg
>> Why not ToroiseGit
>
> This is what Johannes Schindelin had to say,
>
> <http://code.google.com/p/msysgit/wiki/GitCheetah>
Noone's written TortoiseGit yet. I have no idea why, and I have
no reason to write it myself. If GitCheetah isn't working well,
I'm sure patches are welcome.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 3/3] git send-email: turn --compose on when more than one patch.
From: Pierre Habouzit @ 2008-10-31 12:36 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225456609-694-3-git-send-email-madcoder@debian.org>
Automatically turn --compose on when there is more than one patch, and
that the output is a tty.
Do not print the list of files sent anymore in that case, as the list is
shown in the summary editor.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-send-email.perl | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5c189a7..5cebb40 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -49,7 +49,7 @@ git send-email [options] <file | directory | rev-list >
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
--annotate * Review each patch that will be sent in an editor.
- --compose * Open an editor for introduction.
+ --[no-]compose * Open an editor for introduction.
Sending:
--envelope-sender <str> * Email envelope sender.
@@ -237,7 +237,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
"annotate" => \$annotate,
- "compose" => \$compose,
+ "compose!" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
@@ -409,7 +409,11 @@ if ($validate) {
}
if (@files) {
- unless ($quiet) {
+ if (!defined($compose) && -t STDOUT) {
+ # turn $compose on if there is more than one file
+ $compose = $#files;
+ }
+ unless ($quiet || $compose) {
print $_,"\n" for (@files);
}
} else {
--
1.6.0.3.763.g0275.dirty
^ permalink raw reply related
* [PATCH 1/3] git send-email: make the message file name more specific.
From: Pierre Habouzit @ 2008-10-31 12:36 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225456609-694-1-git-send-email-madcoder@debian.org>
This helps editors choosing their syntax hilighting properly.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 65c254d..4ca571f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -127,7 +127,7 @@ sub unique_email_list(@);
sub cleanup_compose_files();
# Constants (essentially)
-my $compose_filename = ".msg.$$";
+my $compose_filename = ".gitsendemail.msg.$$";
# Variables we fill in automatically, or via prompting:
my (@to,@cc,@initial_cc,@bcclist,@xh,
--
1.6.0.3.763.g0275.dirty
^ permalink raw reply related
* Further enhancement proposal for git-send-email
From: Pierre Habouzit @ 2008-10-31 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <1225450632-7230-1-git-send-email-madcoder@debian.org>
Here is a three patch series (again).
[PATCH 1/3] git send-email: make the message file name more specific.
-> quite independant, and should IMHO be taken.
[PATCH 2/3] git send-email: do not ask questions when --compose is used.
[PATCH 3/3] git send-email: turn --compose on when more than one patch.
Those two patches enhance git-send-email by making ask less questions
when --compose is used (as it can grab the subject, from and reply-to
from the buffer).
It also turns --compose on by default as soon as there is more than
one patch, as I believe than commenting a patch series is more often
done than not. It's is really trivial to "refuse" to comment the
series by just erasing the full buffer content, which should not
really be too anoying (or one can explicitely pass --no-compose for
the same result).
It's probable that those two changes may trigger some discussion
though, but I just used that to send this series, and I can tell with
this git-send-email is nearer what I would like it to be.
^ permalink raw reply
* [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Pierre Habouzit @ 2008-10-31 12:36 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225456609-694-2-git-send-email-madcoder@debian.org>
When --compose is used, we can grab the From/Subject/In-Reply-To from the
edited summary, let it be so and don't ask the user silly questions.
The summary templates gets quite revamped, and includes the list of
patches subjects that are going to be sent with this batch.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-send-email.perl | 174 ++++++++++++++++++++++++++++++---------------------
1 files changed, 102 insertions(+), 72 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4ca571f..5c189a7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -417,6 +417,105 @@ if (@files) {
usage();
}
+sub get_patch_subject($) {
+ my $fn = shift;
+ open (my $fh, '<', $fn);
+ while (my $line = <$fh>) {
+ next unless ($line =~ /^Subject: (.*)$/);
+ close $fh;
+ return "GIT: $1\n";
+ }
+ close $fh;
+ die "No subject line in $fn ?";
+}
+
+if ($compose) {
+ # Note that this does not need to be secure, but we will make a small
+ # effort to have it be unique
+ open(C,">",$compose_filename)
+ or die "Failed to open for writing $compose_filename: $!";
+
+
+ my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
+ my $tpl_subject = $initial_subject || '';
+ my $tpl_reply_to = $initial_reply_to || '';
+
+ print C <<EOT;
+From $tpl_sender # This line is ignored.
+GIT: Lines beginning in "GIT: " will be removed.
+GIT: Consider including an overall diffstat or table of contents
+GIT: for the patch you are writing.
+From: $tpl_sender
+Subject: $tpl_subject
+In-Reply-To: $tpl_reply_to
+
+GIT: Please enter your email below this line.
+
+EOT
+ for my $f (@files) {
+ print C get_patch_subject($f);
+ }
+ close(C);
+
+ my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+
+ if ($annotate) {
+ do_edit($compose_filename, @files);
+ } else {
+ do_edit($compose_filename);
+ }
+
+ open(C2,">",$compose_filename . ".final")
+ or die "Failed to open $compose_filename.final : " . $!;
+
+ open(C,"<",$compose_filename)
+ or die "Failed to open $compose_filename : " . $!;
+
+ my $need_8bit_cte = file_has_nonascii($compose_filename);
+ my $in_body = 0;
+ my $summary_empty = 1;
+ while(<C>) {
+ next if m/^GIT: /;
+ if ($in_body) {
+ } elsif (/^\n$/) {
+ $in_body = 1;
+ if ($need_8bit_cte) {
+ print C2 "MIME-Version: 1.0\n",
+ "Content-Type: text/plain; ",
+ "charset=utf-8\n",
+ "Content-Transfer-Encoding: 8bit\n";
+ }
+ } elsif (/^MIME-Version:/i) {
+ $need_8bit_cte = 0;
+ } elsif (/^Subject:\s*(.+)\s*$/i) {
+ $initial_subject = $1;
+ my $subject = $initial_subject;
+ $_ = "Subject: " .
+ ($subject =~ /[^[:ascii:]]/ ?
+ quote_rfc2047($subject) :
+ $subject) .
+ "\n";
+ } elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
+ $initial_reply_to = $1;
+ next;
+ } elsif (/^From:\s*(.+)\s*$/i) {
+ $sender = $1;
+ next;
+ }
+ $summary_empty = 0;
+ print C2 $_;
+ }
+ close(C);
+ close(C2);
+
+ if ($summary_empty) {
+ print "Summary email is empty, skpping it\n";
+ $compose = -1;
+ }
+} elsif ($annotate) {
+ do_edit(@files);
+}
+
my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
@@ -461,17 +560,6 @@ sub expand_aliases {
@initial_cc = expand_aliases(@initial_cc);
@bcclist = expand_aliases(@bcclist);
-if (!defined $initial_subject && $compose) {
- while (1) {
- $_ = $term->readline("What subject should the initial email start with? ", $initial_subject);
- last if defined $_;
- print "\n";
- }
-
- $initial_subject = $_;
- $prompting++;
-}
-
if ($thread && !defined $initial_reply_to && $prompting) {
while (1) {
$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ", $initial_reply_to);
@@ -498,64 +586,6 @@ if (!defined $smtp_server) {
}
if ($compose) {
- # Note that this does not need to be secure, but we will make a small
- # effort to have it be unique
- open(C,">",$compose_filename)
- or die "Failed to open for writing $compose_filename: $!";
- print C "From $sender # This line is ignored.\n";
- printf C "Subject: %s\n\n", $initial_subject;
- printf C <<EOT;
-GIT: Please enter your email below.
-GIT: Lines beginning in "GIT: " will be removed.
-GIT: Consider including an overall diffstat or table of contents
-GIT: for the patch you are writing.
-
-EOT
- close(C);
-
- my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
-
- if ($annotate) {
- do_edit($compose_filename, @files);
- } else {
- do_edit($compose_filename);
- }
-
- open(C2,">",$compose_filename . ".final")
- or die "Failed to open $compose_filename.final : " . $!;
-
- open(C,"<",$compose_filename)
- or die "Failed to open $compose_filename : " . $!;
-
- my $need_8bit_cte = file_has_nonascii($compose_filename);
- my $in_body = 0;
- while(<C>) {
- next if m/^GIT: /;
- if (!$in_body && /^\n$/) {
- $in_body = 1;
- if ($need_8bit_cte) {
- print C2 "MIME-Version: 1.0\n",
- "Content-Type: text/plain; ",
- "charset=utf-8\n",
- "Content-Transfer-Encoding: 8bit\n";
- }
- }
- if (!$in_body && /^MIME-Version:/i) {
- $need_8bit_cte = 0;
- }
- if (!$in_body && /^Subject: ?(.*)/i) {
- my $subject = $1;
- $_ = "Subject: " .
- ($subject =~ /[^[:ascii:]]/ ?
- quote_rfc2047($subject) :
- $subject) .
- "\n";
- }
- print C2 $_;
- }
- close(C);
- close(C2);
-
while (1) {
$_ = $term->readline("Send this email? (y|n) ");
last if defined $_;
@@ -567,9 +597,9 @@ EOT
exit(0);
}
- @files = ($compose_filename . ".final", @files);
-} elsif ($annotate) {
- do_edit(@files);
+ if ($compose > 0) {
+ @files = ($compose_filename . ".final", @files);
+ }
}
# Variables we set as part of the loop over files
--
1.6.0.3.763.g0275.dirty
^ permalink raw reply related
* Re: Are binary xdeltas only used if you use git-gc?
From: Matthieu Moy @ 2008-10-31 12:42 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: git
In-Reply-To: <f1d2d9ca0810310243r669840bbj2c5ee7183e0caaed@mail.gmail.com>
"Thanassis Tsiodras" <ttsiodras@gmail.com> writes:
> If that is the case, I will create an alias to always git-gc after commits...
If you have a decent version of git, it already does "git gc --auto"
regularly. With --auto, git gc will do nothing if you don't have too
many unpacked objects, and will try to do the right thing otherwise
(incremental packs, see man git gc). The idea is that "git gc" is a
costly operation, and git prefers to waste a bit of disk space to make
most "commit" really fast, and to take time to optimize the repository
only when it grew too much.
If you're worried about repository size and you have a permanently
running machine, a good idea is to run git gc in a cron job, so that
you work fast in daytime, and your computer optimizes hard at night
time ;-) (I have gic gc + git fsck in a cron job, so I'll also know if
a repository gets corrupted).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Peter Harris @ 2008-10-31 12:59 UTC (permalink / raw)
To: Alex Riesen
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <20081031070003.GA4458@blimp.localdomain>
On Fri, Oct 31, 2008 at 3:00 AM, Alex Riesen wrote:
> Sam Vilain, Thu, Oct 30, 2008 06:29:14 +0100:
>> On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
>> > I could not find what exactly does the ActiveState's Perl use for its stat
>> > implementation (and honestly, have no motivation to look harder).
>> > It seems to honor TZ, but the produced time does not seem to be either
>> > local or GMT.
>>
>> See, the difference is that the perl is portable and your patch isn't.
>
> ActiveState Perl on Windows is portable? To another windows, maybe.
Quite aside from missing the point (which is that Vanilla Perl runs
everywhere, including Windows[1]), this is also factually incorrect. A
quick check of the ActiveState website would reveal ActivePerl
downloads for AIX, Linux (x86 and x86-64), Solaris (x86, SPARC, and
SPARC64), MacOSX (x86 and PPC), and source code, in addition to
Windows.
Looks pretty portable to me.
Peter Harris
[1] http://vanillaperl.com/
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-10-31 13:45 UTC (permalink / raw)
To: Peter Harris
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <eaa105840810310559l29addd80i7a22c21e37231bb1@mail.gmail.com>
2008/10/31 Peter Harris <git@peter.is-a-geek.org>:
> On Fri, Oct 31, 2008 at 3:00 AM, Alex Riesen wrote:
>> Sam Vilain, Thu, Oct 30, 2008 06:29:14 +0100:
>>> On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
>>> > I could not find what exactly does the ActiveState's Perl use for its stat
>>> > implementation (and honestly, have no motivation to look harder).
>>> > It seems to honor TZ, but the produced time does not seem to be either
>>> > local or GMT.
>>>
>>> See, the difference is that the perl is portable and your patch isn't.
>>
>> ActiveState Perl on Windows is portable? To another windows, maybe.
>
> Quite aside from missing the point (which is that Vanilla Perl runs
> everywhere, including Windows[1]), this is also factually incorrect.
Ok, it is (almost: "Vanilla Perl is experimental and is not intended for
production purposes". Well, I need it exactly for production purposes!)
> A quick check of the ActiveState website would reveal ActivePerl
> downloads for AIX, Linux (x86 and x86-64), Solaris (x86, SPARC, and
> SPARC64), MacOSX (x86 and PPC), and source code, in addition to
> Windows.
what's the point of that, I wonder... Just to admit they broke the original
source beyond all repair on one platform (windows) so now they
have provide their poor customers with the same broken version
on all the other platforms, because they complained about incompatibilities.
So Perl is portable. ActiveState Perl may look portable. They just don't
seem to be compatible enough. Even then, the Git's test suite and some
scripts (I have no use for git-svn on Windows) do very good job to be usable
even if the portable dependency replaced with something else. I'm trying to
keep it at that because I personally have no choice.
^ 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