* [PATCH v2] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-15 10:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Shawn O. Pearce,
git
In-Reply-To: <7vd43krwd0.fsf@alter.siamese.dyndns.org>
On my slow laptop (P3 600MHz), system-wide bash completions take
too much time to load (> 2s), and a significant fraction of this
time is spent loading git-completion.bash:
$ time bash -c ". ./git-completion.bash" # hot cache, before this patch
real 0m0.509s
user 0m0.310s
sys 0m0.180s
Kirill noticed that most of the time is spent warming up the
merge_strategy, all_command and porcelain_command caches.
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
The result is that loading completion is significantly faster
now:
$ time bash -c ". ./git-completion.bash" # cold cache, after this patch
real 0m0.171s
user 0m0.060s
sys 0m0.040s
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: SZEDER Gábor <szeder@ira.uka.de>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This version incorporates the small improvements previously sent, plus the
following nice one (which makes caching merge strategies safe again).
Thanks for the advice, everyone.
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> > __git_compute_merge_strategies ()
> > {
> > - : ${__git_merge_strategies=$(__git_list_merge_strategies)}
> > + __git_merge_strategies=$(__git_list_merge_strategies)
>
> Wouldn't
>
> : ${__gms:=$(command)}
>
> run command only until it gives a non-empty string?
Yes. :)
contrib/completion/git-completion.bash | 76 +++++++++++++++++---------------
1 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..43d76b7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -324,12 +318,8 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
+__git_list_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -339,8 +329,17 @@ __git_merge_strategies ()
p
}'
}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
+
+unset __git_merge_strategies
+# 'git merge -s help' (and thus detection of the merge strategy
+# list) fails, unfortunately, if run outside of any git working
+# tree. __git_merge_strategies is set to the empty string in
+# that case, and the detection will be repeated the next time it
+# is needed.
+__git_compute_merge_strategies ()
+{
+ : ${__git_merge_strategies:=$(__git_list_merge_strategies)}
+}
__git_complete_file ()
{
@@ -474,27 +473,24 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
+__git_list_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -504,17 +500,18 @@ __git_all_commands ()
esac
done
}
-__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-__git_porcelain_commands ()
+unset __git_all_commands
+__git_compute_all_commands ()
+{
+ : ${__git_all_commands=$(__git_list_all_commands)}
+}
+
+__git_list_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -595,8 +592,13 @@ __git_porcelain_commands ()
esac
done
}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
+
+unset __git_porcelain_commands
+__git_compute_porcelain_commands ()
+{
+ __git_compute_all_commands
+ : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
+}
__git_aliases ()
{
@@ -1088,7 +1090,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "$__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1444,7 +1447,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1545,7 +1549,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "$__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2142,7 +2147,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH todo] dodoc: detect doctype-xsl version before making docs
From: Junio C Hamano @ 2009-11-15 10:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: gitster, git
In-Reply-To: <20091112023139.GA1627@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> The manpages in the man branch of git.git appear to have acquired
> the dreaded escaped .ft disease when the docbook-xsl toolchain
> was upgraded to v1.74.3.
> ---
> It is hard work avoiding escaped nroff directives in output. I am a
> bit confused at what happened here, since docbook-xsl v1.73.2 should
> have required the same settings.
>
> These changes are untested, unfortunately. I hope they can be of some
> help nevertheless.
>
> dodoc.sh | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/dodoc.sh b/dodoc.sh
> index 5cbc269..bf49710 100755
> --- a/dodoc.sh
> +++ b/dodoc.sh
> @@ -77,6 +77,19 @@ asciidoc' 8'.*)
> export ASCIIDOC8 ;;
> esac
>
> +db_version_file=/usr/share/xml/docbook/stylesheet/nwalsh/VERSION
> +case "$(grep "<fm:Version>" "$db_version_file" 2>/dev/null)" in
Thanks, but there seem to be no such file on FC11. In /etc/xml/catalog,
I see:
<rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/current"
rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.74.3"/>
Unfortunately this seems highly distro dependent. On my near-by Debian
box, /etc/xml/docbook-xsl.xml has
<delegateURI
uriStartString="http://docbook.sourceforge.net/release/xsl/"
catalog="file:///usr/share/xml/docbook/stylesheet/nwalsh/catalog.xml"/>
and the _catalog_ file has comment v1.73.2 (or whatever) and also
<rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/1.73.2/"
rewritePrefix="./"/>
For now I simply will give up to be portable and adjust the script for the
reality on k.org machine that is used to auto-generate the documentation.
^ permalink raw reply
* Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-15 10:04 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Hello,
I contact you because I spent quite some time to make something pretty
basic with gitweb.
I made gitweb behave a bit like UserDir module will in apache.
In fact it's only configuration but I think it could be useful to others.
Basicly it allows users of your server who use git to be able to use
gitweb to browse their own root project. E.G. :
Alice's private repos :
/home/alice/git/product_a.git (cloned from /var/git/product_a.git)
/home/alice/git/product_b.git (cloned from /var/git/product_b.git)
/home/alice/git/product_c.git (cloned from /var/git/product_c.git)
Alice's links to her repos which she wants to be able to browse with gitweb :
/home/alice/gitweb/product_a -> /home/alice/git/product_a.git/.git
/home/alice/gitweb/product_c -> /home/alice/git/product_c.git/.git
Bare repos :
/var/git/product_a.git
/var/git/product_b.git
/var/git/product_c.git
/var/git/product_d.git
/etc/gitweb.conf :
$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/var/git/";
Apache configuration :
RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
So now all users with a gitweb folder in their home will be able to
browse all git repos in it through http://<host>/~<user>.
You will find a patch enclosed which try to describe best what I did
and why in the gitweb/README.
Regards.
[-- Attachment #2: userdirstyle.patch --]
[-- Type: application/octet-stream, Size: 1490 bytes --]
diff --git a/gitweb/README b/gitweb/README
index 66c6a93..6f733e6 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -306,8 +306,10 @@ repositories, you can configure apache like this:
DocumentRoot /pub/git
SetEnv GITWEB_CONFIG /etc/gitweb.conf
RewriteEngine on
+
# make the front page an internal rewrite to the gitweb script
RewriteRule ^/$ /cgi-bin/gitweb.cgi
+
# make access for "dumb clients" work
RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
</VirtualHost>
@@ -332,6 +334,20 @@ something like the following in your gitweb.conf (or gitweb_config.perl) file:
$my_uri = "/";
$home_link = "/";
+If you want gitweb to act a bit like UserDir mod in apache, knowing, http://<host>/~<user>
+will list all git repos of <user> located in a special directory in his home (/home/<user>/gitweb/),
+do the following steps :
+
+Add this to the VirtualHost section of your apache configuration file :
+
+ RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
+
+Modify your gitweb.conf file, located at /etc/gitweb.conf in this example, with :
+
+ $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/path/to/the/defaul/project/root";
+
+Thus, each user with a gitweb folder in his home will be able to browse it with gitweb.
+/!\ The gitweb folder and user's home folder must be readable by the webserver user.
PATH_INFO usage
-----------------------
^ permalink raw reply related
* Re: git svn fetch loses data
From: Victor Engmark @ 2009-11-15 9:56 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Sverre Rabbelier, git
In-Reply-To: <4AFF3EB7.5080606@gmail.com>
On Sun, Nov 15, 2009 at 12:35 AM, Johan 't Hart <johanthart@gmail.com> wrote:
> Sverre Rabbelier schreef:
>> On Sat, Nov 14, 2009 at 20:29, Victor Engmark <victor.engmark@gmail.com>
>> wrote:
>>>
>>> Do I need to run something after fetch to see them?
>>
>> Your working copy is probably not up to date anymore, try:
>>
>> $ git rebase git-svn
>>
> Why not just
> $ git svn rebase
> ?
What is the difference between the two?
--
Victor Engmark
^ permalink raw reply
* Re: .gitignore polution
From: Jeff King @ 2009-11-15 9:43 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0911141557k5f6b0b8aud48b95784a9da4e3@mail.gmail.com>
On Sun, Nov 15, 2009 at 12:57:31AM +0100, Sverre Rabbelier wrote:
> I usually compile git from next (sometimes pu to test out a new
> feature), and when I then switch back to a development branch (usually
> based off master) I get something like this:
>
> $ git status
> # On branch remote-helpers
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # git-http-backend
> # git-notes
> # git-remote-hg
> # test-index-version
>
> Now I can easily do 'git clean -f', but it's somewhat annoying. How do
> other developers deal with this?
I use "git clean". :)
The other option is to mark them for ignore outside of the
branch-specific ignore:
git ls-files -o --exclude-standard >>.git/info/exclude
-Peff
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Junio C Hamano @ 2009-11-15 9:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: rocketraman, git, trast, gitster
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Other minor clarifications in the text are also included in this change:
>
> * Clarify "building documentation" a bit; the post-update hook
> creates preformatted documentation pages.
>
> * The latest documentation set uses "fast-forward", not "fast
> forward".
>
> * Call 'next' branch an integration branch, not a "testing" branch, to be
> consistent with the Graduation section.
> ...
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
Your changes look mostly fine.
I obviously agree with the removal of "use 'branch -f' to update maint"
which I said I do not want to see in the document number of times.
There is another thing; I didn't notice it in the earlier round but the
way I actually rotate 'master', 'maint' and the 'maint-one-rev-old' is
similar to how Thomas mentioned. That is:
================================
git checkout master
git log ..maint ;# should see nothing
git tag ... ;# release task
git checkout maint
git branch maint-X.Y.Z ;# without -f so that I can catch a typo to
clobber what already exists
git merge --ff-only master
================================
My fingers are trained to type "git merge" before --ff-only was invented,
so I actually do use "merge master" without --ff-only option in the last
step, but if I see a real merge created with that command, I notice it and
treat it as a grave error, so in the Recipe we should say --ff-only.
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Junio C Hamano @ 2009-11-15 9:12 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Jeff King, git
In-Reply-To: <20091110122315.GA15906@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 10, 2009 at 11:46:51AM +0100, Philippe Bruhat (BooK) wrote:
> (snip)
> Will this work if I just have PERL_PATH in my config.mak in the root
> directory? Should we be adding PERL_PATH to the generated
> GIT-BUILD-OPTIONS file in the root, which gets sourced by test-lib?
>
> Something like the following (completely untested) patch?
Philippe, could you please help getting this topic unstuck with a "it
works" or "it doesn't and here is a better solution"?
> diff --git a/Makefile b/Makefile
> index a10a60c..b9a8145 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1643,6 +1643,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> # and the first level quoting from the shell that runs "echo".
> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
> @echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
> + @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
> @echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
> @echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
> @echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
^ permalink raw reply
* Re: [PATCH 2/2] pack documentation review updates
From: Junio C Hamano @ 2009-11-15 9:11 UTC (permalink / raw)
To: Scott Chacon
Cc: Nanako Shiraishi, Junio C Hamano, Sverre Rabbelier,
Shawn O. Pearce, git list
In-Reply-To: <d411cc4a0911110205j6f3afedw57d2c56fb28dc20@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> On Wed, Nov 11, 2009 at 9:19 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Update Scott's protocol document according to review comments given by Junio.
>>
>> * name of "%00" byte is NUL not null;
>> ...
>> * don't unnecessarily say "SHOULD NOT" when existing servers can satisify
>> "MUST NOT";
>> ...
>
> I was _just_ working on this yesterday and had gotten about halfway
> through - I'm traveling a lot right now, so I'm a bit behind. This
> looks good, thanks for taking the time Nanako.
>
> Signed-off-by: Scott Chacon <schacon@gmail.com>
Thanks, both.
I had some doubts about the "SHOULD NOT"/"MUST" on obj-id myself, but if
you are Ok with the change, I wouldn't complain ;-).
Will squash this in.
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Junio C Hamano @ 2009-11-15 9:10 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Peter Krefting, Junio C Hamano, Thomas Rast, Nicolas Sebrecht,
Baz, Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <20091114111259.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Peter Krefting <peter@softwolves.pp.se>
>
>> The web tree checkout script uses rebase to avoid introducing merge
>> commits every time the blog comment is updated, as it in 99 % of cases
>> is unrelated to any other changes found in the central repo.
>>
>> In the few cases where the blog comment update from the web tree
>> conflicts with a change in the central repo, I want the "git pull
>> --rebase" call to overwrite any changes in the central repo with my
>> changes in the web tree (meaning that I would later have to manually
>> re-delete the spam comments, but I can live with that).
>
> That sounds like "-Xours" merge option that was discussed some time
> ago. See
>
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
>
> I remember that Junio and Petr were against it because it would
> encourage a bad workflow. Dscho was against the syntax used to
> pass the options also.
Yeah, Björn seems to speculate the same.
Even though I still think -Xours/-Xtheirs are nonsense options in the
context of source code management, I suspect that they might be exactly
what Peter needs in this situation.
As long as the changes made on the "web tree" side only consist of
user-generated blog contents and never touch framework code that is
controlled by his "central repo" side (and that condition should
hold true; otherwise Peter's web site is seriously broken from the
security point of view and no SCM can fix that), running a merge with
the fabled -Xours option in the "web tree" to slurp in the changes made on
the "central repo" side does not sound like an unreasonable thing to do.
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Tim Henigan; +Cc: Nanako Shiraishi, gitster, git
In-Reply-To: <32c343770911142034j6cf10e36jbd031c49119973c8@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> On Fri, Nov 13, 2009 at 5:19 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>>
>> The second change is good but why do you remove -v from the
>> synopsis section? Why is it a good idea? Manual pages for
>> many other commands list --verbose in their synopsis section.
>>
>
> After checking other git operations (fetch, pull, clone, commit, merge, etc)
> I found that none of these other commands document '-v' in the synopsis.
>
> With that in mind, I wondered why it had been listed for 'git remote'. My best
> guess is that only some of the 'git remote' subcommands are affected by '-v'.
> However, to me it still seems better to only mention it as a general option.
> That way if subcommands add/remote support for '-v', the usage string
> and man page don't need to be updated.
>
> Please note that even with the change, '-v' is still printed as one of the
> general options in the usage string. I simply removed it from the synopsis
> section.
You noticed a good issue to address. That is, "git remote -h" output
looks Ok but "git remote add -h" and friends show way suboptimal help.
The current output looks like:
$ git remote add -h
usage: git remote [-v | --verbose]
or: git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name>
<url>
or: git remote rename <old> <new>
or: git remote rm <name>
or: git remote set-head <name> [-a | -d | <branch>]
or: git remote show [-n] <name>
or: git remote prune [-n | --dry-run] <name>
or: git remote [-v | --verbose] update [-p | --prune] [group]
add specific options
-f, --fetch fetch the remote branches
-t, --track <branch> branch(es) to track
-m, --master <branch>
master branch
--mirror no separate remotes
As the user already knows "add" is the subcommand she is interested in,
this is insane.
My preference is:
(1) to drop your change to the synopsis section ("git remote -v" is a
valid way to get more verbose information, isn't it?);
(2) to keep the current output of "git remote -h";
(3) to drop the general description section altogether from "git remote
add -h" output;
I think this is related to a bigger issue of how we generally would want
to show help in response to "-h", and also in the manual pages.
http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
^ permalink raw reply
* Re: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Jan Krüger; +Cc: Jeff King, Jan Nieuwenhuizen, Tomas Carnecky, git list
In-Reply-To: <20091112170814.1858aba4@perceptron>
Jan Krüger <jk@jk.gs> writes:
> So this still uses config file syntax, but the erroneous check for
> using the "rebase" setting is gone. Instead, if --rebase is in effect,
> include "rebase = true" in the sample config snippet.
Will queue.
I've been ill and didn't follow the discussion very closely, so perhaps
there may still some minor disagreements in the details I didn't catch?
Just in case, I'll queue it on 'pu' for now.
Thanks.
^ permalink raw reply
* Re: [PATCH] http-backend: Fix bad treatment of uintmax_t in Content-Length
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Tarmigan; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <905315640911141349t7121baa8vc0b2be59fa348512@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> On Wed, Nov 11, 2009 at 8:42 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Our Content-Length needs to report an off_t, which could be larger
>> precision than size_t on this system (e.g. 32 bit binary built with
>> 64 bit large file support).
>>
>> We also shouldn't be passing a size_t parameter to printf when
>> we've used PRIuMAX as the format specifier.
>>
>> Fix both issues by using uintmax_t for the hdr_int() routine,
>> allowing strbuf's size_t to automatically upcast, and off_t to
>> always fit.
>>
>> Also fixed the copy loop we use inside of send_local_file(), we never
>> actually updated the size variable so we might as well not use it.
>>
>> Reported-by: Tarmigan <tarmigan+git@gmail.com>
>
> Tested-by: Tarmigan <tarmigan+git@gmail.com>
Thanks; care to spell your name in full (as if you are publishing say a
scientific paper)? I am guessing that the other Tarmigan with full name
who posted a few patches is the same person as you.
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Junio C Hamano @ 2009-11-15 9:05 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Shawn O. Pearce,
git
In-Reply-To: <20091114110141.GB1829@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> __git_compute_merge_strategies ()
> {
> - : ${__git_merge_strategies=$(__git_list_merge_strategies)}
> + __git_merge_strategies=$(__git_list_merge_strategies)
Wouldn't
: ${__gms:=$(command)}
run command only until it gives a non-empty string?
^ permalink raw reply
* Re: [PATCH v4 0/9] Default pager and editor
From: Junio C Hamano @ 2009-11-15 9:04 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Thanks, re-queued.
I've been sick and in bed for the past few days, so apologies for a late
reply.
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Jacob Helwig @ 2009-11-15 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <20091115073628.GE5934@penguin.codegnome.org>
On Sat, Nov 14, 2009 at 23:36, Todd A. Jacobs <nospam@codegnome.org> wrote:
> On Sat, Nov 14, 2009 at 09:36:47PM -0800, Jacob Helwig wrote:
>
>> What version of git are you using? git checkout -b foo/bar/baz works
>
> I'm using 1.6.5.2 as well. Okay, try this in a temp directory, and
> you'll see what I mean:
>
> git init
> echo foo > foo
> git add foo
> git commit -m testing foo
> git checkout -b dev
> git checkout -b dev/feature/foobar
>
> The first branch works fine, but after attempting the nested branch the
> message reappears:
>
> error: unable to resolve reference refs/heads/dev/feature/foobar: Not a directory
> fatal: Failed to lock ref for update: Not a directory
>
> I can recreate this behavior at any time; it isn't just a problem with
> an existing repository.
>
> --
> "Oh, look: rocks!"
> -- Doctor Who, "Destiny of the Daleks"
>
The problem is that you have a branch dev. You can't have both a
file, and a directory with the same name.
You're trying to get git to do basically this:
% cd .git/refs/heads
% ls -l
total 0
-rw-rw-r-- 1 jhe jhe 41 2009-11-14 23:51 dev
-rw-rw-r-- 1 jhe jhe 41 2009-11-14 23:51 master
% mkdir dev
mkdir: cannot create directory `dev': File exists
You're getting the equivalent of the "cannot create directory" error.
When you have a branch with slashes in it, it gets stored as a
directory hierarchy under .git/refs/heads.
-Jacob
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Todd A. Jacobs @ 2009-11-15 7:36 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060911142136s68a08892ifa27989f3a5bfdfb@mail.gmail.com>
On Sat, Nov 14, 2009 at 09:36:47PM -0800, Jacob Helwig wrote:
> What version of git are you using? git checkout -b foo/bar/baz works
I'm using 1.6.5.2 as well. Okay, try this in a temp directory, and
you'll see what I mean:
git init
echo foo > foo
git add foo
git commit -m testing foo
git checkout -b dev
git checkout -b dev/feature/foobar
The first branch works fine, but after attempting the nested branch the
message reappears:
error: unable to resolve reference refs/heads/dev/feature/foobar: Not a directory
fatal: Failed to lock ref for update: Not a directory
I can recreate this behavior at any time; it isn't just a problem with
an existing repository.
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Daniel Barkalow @ 2009-11-15 7:16 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <20091115050227.GD5934@penguin.codegnome.org>
On Sat, 14 Nov 2009, Todd A. Jacobs wrote:
> I want to create a nested feature branch, but git keeps complaining if I
> nest more than one level deep:
>
> $ git checkout -b dev/feature/foo
> error: unable to resolve reference refs/heads/dev/feature/foo:
> Not a directory
> fatal: Failed to lock ref for update: Not a directory
>
> Based on my reading of the manual pages, it seems like I should be able
> to nest branch names as long as it conforms to certain rules. I read
> git-branch(1), which points me to git-check-ref-format(1), which seems
> to say that the rules are being followed.
Do you have a branch "dev/feature"? Branch names are path-like in that you
can't have dev/feature as both a branch and a prefix for branches.
> On the other hand, running:
>
> $ git check-ref-format foo; echo $?
>
> always results in a non-zero error code, even with a literal 'foo' as a
> branch name, so clearly it isn't saying what I think it's saying.
> *shrug*
You want either "git check-ref-format --branch foo" or "git
check-ref-format refs/heads/foo".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-15 6:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <1258242380.9650.90.camel@swboyd-laptop>
Stephen Boyd wrote:
> I was thinking of adding an option to git merge (like --strategies) to
> list the strategies without requiring you to be in a git directory. It
> doesn't look that easy at first glance so it might not be worth the
> trouble.
Right, that would require support from run_builtin().
^ permalink raw reply
* Re: PEBKAC or bug: unable to create path-like branch names
From: Jacob Helwig @ 2009-11-15 5:36 UTC (permalink / raw)
To: git
In-Reply-To: <20091115050227.GD5934@penguin.codegnome.org>
On Sat, Nov 14, 2009 at 21:02, Todd A. Jacobs <nospam@codegnome.org> wrote:
> I want to create a nested feature branch, but git keeps complaining if I
> nest more than one level deep:
>
> $ git checkout -b dev/feature/foo
> error: unable to resolve reference refs/heads/dev/feature/foo:
> Not a directory
> fatal: Failed to lock ref for update: Not a directory
>
> Based on my reading of the manual pages, it seems like I should be able
> to nest branch names as long as it conforms to certain rules. I read
> git-branch(1), which points me to git-check-ref-format(1), which seems
> to say that the rules are being followed.
>
> On the other hand, running:
>
> $ git check-ref-format foo; echo $?
>
> always results in a non-zero error code, even with a literal 'foo' as a
> branch name, so clearly it isn't saying what I think it's saying.
> *shrug*
>
> Can someone provide a little clarity here?
>
> --
> "Oh, look: rocks!"
> -- Doctor Who, "Destiny of the Daleks"
>
What version of git are you using? git checkout -b foo/bar/baz works
for me on 1.6.5.2. As far as git check-ref-format, it works (returns
0) if I do 'refs/heads/foo', but returns 1 on 'foo'. This makes
sense, given rule 2 from the manpage: They must contain at least one
/. This enforces the presence of a category like heads/, tags/ etc.
but the actual names are not restricted.
Hope this helps.
-Jacob
^ permalink raw reply
* PEBKAC or bug: unable to create path-like branch names
From: Todd A. Jacobs @ 2009-11-15 5:02 UTC (permalink / raw)
To: git
In-Reply-To: <20091115020605.GE15966@cl.cam.ac.uk>
I want to create a nested feature branch, but git keeps complaining if I
nest more than one level deep:
$ git checkout -b dev/feature/foo
error: unable to resolve reference refs/heads/dev/feature/foo:
Not a directory
fatal: Failed to lock ref for update: Not a directory
Based on my reading of the manual pages, it seems like I should be able
to nest branch names as long as it conforms to certain rules. I read
git-branch(1), which points me to git-check-ref-format(1), which seems
to say that the rules are being followed.
On the other hand, running:
$ git check-ref-format foo; echo $?
always results in a non-zero error code, even with a literal 'foo' as a
branch name, so clearly it isn't saying what I think it's saying.
*shrug*
Can someone provide a little clarity here?
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-15 4:34 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: gitster, git
In-Reply-To: <20091114071948.6117@nanako3.lavabit.com>
On Fri, Nov 13, 2009 at 5:19 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>
> The second change is good but why do you remove -v from the
> synopsis section? Why is it a good idea? Manual pages for
> many other commands list --verbose in their synopsis section.
>
After checking other git operations (fetch, pull, clone, commit, merge, etc)
I found that none of these other commands document '-v' in the synopsis.
With that in mind, I wondered why it had been listed for 'git remote'. My best
guess is that only some of the 'git remote' subcommands are affected by '-v'.
However, to me it still seems better to only mention it as a general option.
That way if subcommands add/remote support for '-v', the usage string
and man page don't need to be updated.
Please note that even with the change, '-v' is still printed as one of the
general options in the usage string. I simply removed it from the synopsis
section.
Thank for reviewing,
Tim
^ permalink raw reply
* Preserving empty directories when doing a git-svn clone/rebase
From: Steven J. Murdoch @ 2009-11-15 2:06 UTC (permalink / raw)
To: git; +Cc: normalperson
When git-svn clones a Subversion repository, any empty directories
appear to be silently dropped (tested using git version 1.6.5.2 on Mac
OS X Snow Leopard). This causes problems for using git with software
projects which depend on Subversion's ability to track empty
directories. I was recently caught out by this, and it was difficult
to debug what had gone wrong.
Would it be possible to change git-svn to handle this case? Since git
doesn't have the ability to track empty directories, probably the
simplest thing to do would be to automatically add a file (e.g.
.gitignore) to any empty directories. In theory this could cause
problems, but I would think the chances of this are far lower than
with the current behaviour.
I think this feature would help projects in which some contributors
are transitioning to git. It would especially be useful to novice
users of git, who are not aware of the potential problems with having
empty directories.
I see there was a discussion in 2006:
http://kerneltrap.org/mailarchive/git/2006/11/29/231586
However, since then I haven't seen any updates. The rationale behind
the original request still seems applicable today:
"I think there are many potential git users out there who are
currently svn users. And git-svn is a really nice way to get started,
but this sort of stumbling block could really turn people off. For
example, it made me look pretty dumb when I carelessly complained to
my colleague about his code not working and then it turns out to be
because my super-advanced scm tool "messed things up"."
(git-svn and empty directories in svn (was: [PATCH 1.2/2 (fixed)]
git-svn: fix output reporting from the delta fetcher))
Thanks,
Steven Murdoch.
--
http://www.cl.cam.ac.uk/users/sjm217/
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Daniel Barkalow @ 2009-11-15 2:49 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911141807q4be6015bjda4805496be6dbb3@mail.gmail.com>
On Sun, 15 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Nov 11, 2009 at 19:45, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Okay, finally got to it just now. This is entirely untested (because I
> > don't have anything that uses it), but it compiles and should be correct.
> > It would be nice to get a clean bill of health on it from valgrind.
>
> After a lot of manual comparison of valgrind traces (comparing cloning
> a local git repo and a local hg repo), I have found the following
> before applying your patch (I removed the ==proc== and "by 0xDEADBEEF"
> noise):
>
> 20 bytes in 1 blocks are definitely lost in loss record 24 of 95
> at : calloc (vg_replace_malloc.c:418)
> by : xcalloc (wrapper.c:75)
> by : get_importer (transport-helper.c:132)
> by : fetch_with_import (transport-helper.c:150)
> by : fetch (transport-helper.c:198)
> by : transport_fetch_refs (transport.c:977)
> by : cmd_clone (builtin-clone.c:538)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
> by : main (git.c:509)
>
> 60 bytes in 1 blocks are definitely lost in loss record 43 of 95
> at : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : strbuf_grow (strbuf.c:61)
> by : strbuf_getwholeline (strbuf.c:335)
> by : strbuf_getline (strbuf.c:349)
> by : get_helper (transport-helper.c:52)
> by : get_refs_list (transport-helper.c:228)
> by : transport_get_remote_refs (transport.c:943)
> by : cmd_clone (builtin-clone.c:535)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
>
> 65 bytes in 1 blocks are definitely lost in loss record 47 of 95
> at : malloc (vg_replace_malloc.c:195)
> by : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : strbuf_grow (strbuf.c:61)
> by : strbuf_addf (strbuf.c:199)
> by : get_helper (transport-helper.c:69)
> by : get_refs_list (transport-helper.c:228)
> by : transport_get_remote_refs (transport.c:943)
> by : cmd_clone (builtin-clone.c:535)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
>
> 65 bytes in 1 blocks are definitely lost in loss record 50 of 95
> at : malloc (vg_replace_malloc.c:195)
> by : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : strbuf_grow (strbuf.c:61)
> by : strbuf_addf (strbuf.c:199)
> by : fetch_with_import (transport-helper.c:158)
> by : fetch (transport-helper.c:198)
> by : transport_fetch_refs (transport.c:977)
> by : cmd_clone (builtin-clone.c:538)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
>
> 123 (96 direct, 27 indirect) bytes in 1 blocks are definitely lost
> in loss record 71 of 95
> at : malloc (vg_replace_malloc.c:195)
> by : realloc (vg_replace_malloc.c:476)
> by : xrealloc (wrapper.c:59)
> by : get_helper (transport-helper.c:62)
> by : get_refs_list (transport-helper.c:228)
> by : transport_get_remote_refs (transport.c:943)
> by : cmd_clone (builtin-clone.c:535)
> by : run_builtin (git.c:251)
> by : handle_internal_command (git.c:396)
> by : run_argv (git.c:438)
> by : main (git.c:509)
>
> Annotated with the relevant source and my comments:
> by : get_importer (transport-helper.c:132)
> fastimport->argv = xcalloc(5, sizeof(*fastimport->argv));
>
> You never free fastimport->argv.
>
> by : get_helper (transport-helper.c:52)
> if (strbuf_getline(&buf, file, '\n') == EOF)
>
> You never strbuf_release(&buf).
>
> by : get_helper (transport-helper.c:69)
> strbuf_addf(&gitdir, "gitdir %s\n", get_git_dir());
>
> I do strbuf_reset(&gitdir), which should of course be
> strbuf_release(&gitdir), oops.
>
> by : fetch_with_import (transport-helper.c:158)
> strbuf_addf(&buf, "import %s\n", posn->name);
>
> Same here, you never strbuf_release(&buf).
>
> by : get_helper (transport-helper.c:62)
> ALLOC_GROW(refspecs,
> refspec_nr + 1,
> refspec_alloc);
>
> This would of course be fixed by your patch.
>
> However, applying your patch causes:
> error: Trying to write ref refs/heads/tip with nonexistant object
> 0000000000000000000000000000000000000000
> fatal: Cannot update the ref 'HEAD'.
>
> If I comment out both new lines in disonnect_helper like so fixes that:
> //free_refspec(data->refspec_nr, data->refspecs);
> //data->refspecs = NULL;
>
> Commenting out only one of the two makes the error return, any idea's?
Looks like I'm discarding the information before I use it, instead of
after. Try moving those lines to release_helper(), and a "!data->refspecs
&&" to the !prefixcmp(... "refspec ") if condition. (That is, keep the
refspecs from the first call to the helper until the whole thing is
released, and ignore those capabilities in later calls.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Sverre Rabbelier @ 2009-11-15 2:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0911111259520.14365@iabervon.org>
Heya,
On Wed, Nov 11, 2009 at 19:45, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Okay, finally got to it just now. This is entirely untested (because I
> don't have anything that uses it), but it compiles and should be correct.
> It would be nice to get a clean bill of health on it from valgrind.
After a lot of manual comparison of valgrind traces (comparing cloning
a local git repo and a local hg repo), I have found the following
before applying your patch (I removed the ==proc== and "by 0xDEADBEEF"
noise):
20 bytes in 1 blocks are definitely lost in loss record 24 of 95
at : calloc (vg_replace_malloc.c:418)
by : xcalloc (wrapper.c:75)
by : get_importer (transport-helper.c:132)
by : fetch_with_import (transport-helper.c:150)
by : fetch (transport-helper.c:198)
by : transport_fetch_refs (transport.c:977)
by : cmd_clone (builtin-clone.c:538)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
by : main (git.c:509)
60 bytes in 1 blocks are definitely lost in loss record 43 of 95
at : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : strbuf_grow (strbuf.c:61)
by : strbuf_getwholeline (strbuf.c:335)
by : strbuf_getline (strbuf.c:349)
by : get_helper (transport-helper.c:52)
by : get_refs_list (transport-helper.c:228)
by : transport_get_remote_refs (transport.c:943)
by : cmd_clone (builtin-clone.c:535)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
65 bytes in 1 blocks are definitely lost in loss record 47 of 95
at : malloc (vg_replace_malloc.c:195)
by : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : strbuf_grow (strbuf.c:61)
by : strbuf_addf (strbuf.c:199)
by : get_helper (transport-helper.c:69)
by : get_refs_list (transport-helper.c:228)
by : transport_get_remote_refs (transport.c:943)
by : cmd_clone (builtin-clone.c:535)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
65 bytes in 1 blocks are definitely lost in loss record 50 of 95
at : malloc (vg_replace_malloc.c:195)
by : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : strbuf_grow (strbuf.c:61)
by : strbuf_addf (strbuf.c:199)
by : fetch_with_import (transport-helper.c:158)
by : fetch (transport-helper.c:198)
by : transport_fetch_refs (transport.c:977)
by : cmd_clone (builtin-clone.c:538)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
123 (96 direct, 27 indirect) bytes in 1 blocks are definitely lost
in loss record 71 of 95
at : malloc (vg_replace_malloc.c:195)
by : realloc (vg_replace_malloc.c:476)
by : xrealloc (wrapper.c:59)
by : get_helper (transport-helper.c:62)
by : get_refs_list (transport-helper.c:228)
by : transport_get_remote_refs (transport.c:943)
by : cmd_clone (builtin-clone.c:535)
by : run_builtin (git.c:251)
by : handle_internal_command (git.c:396)
by : run_argv (git.c:438)
by : main (git.c:509)
Annotated with the relevant source and my comments:
by : get_importer (transport-helper.c:132)
fastimport->argv = xcalloc(5, sizeof(*fastimport->argv));
You never free fastimport->argv.
by : get_helper (transport-helper.c:52)
if (strbuf_getline(&buf, file, '\n') == EOF)
You never strbuf_release(&buf).
by : get_helper (transport-helper.c:69)
strbuf_addf(&gitdir, "gitdir %s\n", get_git_dir());
I do strbuf_reset(&gitdir), which should of course be
strbuf_release(&gitdir), oops.
by : fetch_with_import (transport-helper.c:158)
strbuf_addf(&buf, "import %s\n", posn->name);
Same here, you never strbuf_release(&buf).
by : get_helper (transport-helper.c:62)
ALLOC_GROW(refspecs,
refspec_nr + 1,
refspec_alloc);
This would of course be fixed by your patch.
However, applying your patch causes:
error: Trying to write ref refs/heads/tip with nonexistant object
0000000000000000000000000000000000000000
fatal: Cannot update the ref 'HEAD'.
If I comment out both new lines in disonnect_helper like so fixes that:
//free_refspec(data->refspec_nr, data->refspecs);
//data->refspecs = NULL;
Commenting out only one of the two makes the error return, any idea's?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: pre-built man pages have ".ft" noise
From: Björn Steinbrink @ 2009-11-15 1:34 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git
In-Reply-To: <1258245915.9650.94.camel@swboyd-laptop>
On 2009.11.14 16:45:15 -0800, Stephen Boyd wrote:
> On Sun, 2009-11-15 at 00:47 +0100, Björn Steinbrink wrote:
> > since 916a3c4b7 "Autogenerated manpages for v1.6.5.1-69-g36942", some of
> > the man pages in the "man" branch have a lot of the ".ft C" and ".ft"
> > noise.
>
> I thought this was already noticed a few days ago by Jonathan Nieder.
>
> From: Jonathan Nieder <jrnieder@gmail.com>
> Subject: [PATCH todo] dodoc: detect doctype-xsl version before making
> docs
> Message-id: <20091112023139.GA1627@progeny.tock>
Ah, sorry for the noise then. I only searched the subject lines for
"man", my fault.
Björn
^ 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