* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Junio C Hamano @ 2008-01-16 4:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801151902080.2806@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> We do not want to make it particularly easy for people to create
> mind-bogglingly stupid diff output.
Although the discussion was triggered by that Tortoise thing,
the RFC patch was not about helping that. That's a new feature
asked long after we went into rc freeze, and I am not interested
in discussing such a feature, especially when I am sick.
The only objective was to make sure that a patch that is not
kosher in git-apply's eyes is not marked with "diff --git";
otherwise, its output will confuse git-apply. As --no-prefix
will be a new feature in 1.5.4, we would be shipping with a
known-to-be-bad new feature that is --no-prefix, unless we do
something about it. Fixing that breakage was the sole
motivation behind my patch.
I think a reasonable short-term solution might be to disable any
git specific stuff (renames, rewrites, etc) when --no-prefix and
its friends are used, along with the patch you are commenting on
to remove " --git" from the header. That would at least make
sure that the --no-prefix feature is safe.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 4:18 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20801152006w11307ce0j17463f1c6536543f@mail.gmail.com>
David Symonds wrote:
> On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
>> dir slipping into the tarball, allowing my client to be able to peruse
>> the history of what we did and when.
>
> Use git-archive.
>
Thanks but this isn't sufficient. If we have one directory of our web
root in a git repository, say docroot/php, and we tar up docroot, it
will include php/.git. We don't want that. We would have to go out of
our way to avoid the .git directory. The point is, we don't want
anything in docroot that shouldn't be made live.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Daniel Barkalow @ 2008-01-16 4:13 UTC (permalink / raw)
To: Mike; +Cc: git
In-Reply-To: <478D79BD.7060006@talkingspider.com>
On Tue, 15 Jan 2008, Mike wrote:
> I'm learning git and I'm really annoyed that the .git directory lives in the
> same directory as my code. I don't want it there for three reasons:
>
> 1. My code lives on a development web server docroot, and I don't want the
> .git repository to end up getting published to the live site by accident. (I
> would imagine this would be a common need.)
>
> 2. If I tar/gz my code and deliver it to a client, I don't want the .git dir
> slipping into the tarball, allowing my client to be able to peruse the history
> of what we did and when.
Generate your tarballs with "git archive", which will also make sure that
you don't accidentally include anything else that's not committed.
Likewise for sending to the live site, probably.
> 3. The .git respository will get big, especially with binary files in it, and
> I want it someplace with a lot of disk space. And I don't want it to get
> tarred up when we migrate the site to a different server. (And tar isn't aware
> of hard links is it? wonderful.)
You'll probably want to keep your history, which is what's in .git, when
you migrate to a different server; that's kind of the point of using
version control...
> How do I make the repository dir live somewhere else, the hell away from my
> code? Thanks
export GIT_DIR=/somewhere-else.git
Note that this only really works if you've only got one repository;
there's no good way to have the repository information outside of the
working directory and still have which repository you're using depend on
which directory you're working in.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 4:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86hcheig3n.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
>>>>>> "Mike" == Mike <fromlists@talkingspider.com> writes:
>
>
> Sounds like you need an installer... something that copies your repo into the
> live location with things you don't want included left out, and all the
> permissions and ownership correct.
If you mean copying files from the development webserver to the live
server, then the only reason we'd need an installer is because of the
.git directory, it's the only thing we "don't want included". And as
for permissions and ownership, rsync takes care of that.
>
> git archive --help
>
I got:
$ git archive --help
No manual entry for git-archive
Did I install it wrong? I have CentOS 5, and I did:
su
yum install git
thanks,
m
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: David Symonds @ 2008-01-16 4:06 UTC (permalink / raw)
To: Mike; +Cc: git
In-Reply-To: <478D79BD.7060006@talkingspider.com>
On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>
> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
> dir slipping into the tarball, allowing my client to be able to peruse
> the history of what we did and when.
Use git-archive.
Dave.
^ permalink raw reply
* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Daniel Barkalow @ 2008-01-16 4:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801151919440.2806@woody.linux-foundation.org>
On Tue, 15 Jan 2008, Linus Torvalds wrote:
> On Tue, 15 Jan 2008, Linus Torvalds wrote:
> >
> > If we do any git-specific stuff, we need to have that "--git" thing there.
> > That is *not* just limited to the prefix, but to all the other things git
> > diffs can do: renames, mode changes, etc.
>
> Side note: the fact that git-apply itself might have issues with a
> "--no-prefix" patch is really a red herring, because while it's true that
> you would normally not do it for git, it's even more true that we haven't
> actually started teaching git about it and the cases where you *would* use
> it (eg recursive subproject diffs etc).
>
> So I do not think it's true that "--no-prefix" (or --src/dst-prefix)
> necessarily implies "no-git" at all. It *can* do so, but it's not a given
> thing, and almost certainly isn't in the long run with submodule support.
I don't think --no-prefix is sufficient for submodules; it means that
git-apply will accidentally remove exactly one level, but if your
submodule is two directory levels down, it won't work, and having the
effective prefixes be "gitweb" and "gitweb" is a little hackish. You'd
really want to generate a -p1 patch whose root is shifted from the actual
project root, not a -p0 patch or -p2 patch or something.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Nguyen Thai Ngoc Duy @ 2008-01-16 4:03 UTC (permalink / raw)
To: Mike; +Cc: git
In-Reply-To: <478D79BD.7060006@talkingspider.com>
On Jan 16, 2008 10:27 AM, Mike <fromlists@talkingspider.com> wrote:
>
> I'm learning git and I'm really annoyed that the .git directory lives in
> the same directory as my code. I don't want it there for three reasons:
>
> 1. My code lives on a development web server docroot, and I don't want
> the .git repository to end up getting published to the live site by
> accident. (I would imagine this would be a common need.)
>
> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
> dir slipping into the tarball, allowing my client to be able to peruse
> the history of what we did and when.
>
> 3. The .git respository will get big, especially with binary files in
> it, and I want it someplace with a lot of disk space. And I don't want
> it to get tarred up when we migrate the site to a different server. (And
> tar isn't aware of hard links is it? wonderful.)
>
> How do I make the repository dir live somewhere else, the hell away from
> my code? Thanks
Setup GIT_WORK_TREE and GIT_DIR env variables or use --git-dir and
--work-tree together. See "man git" for more detail.
--
Duy
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Dan McGee @ 2008-01-16 3:56 UTC (permalink / raw)
To: git; +Cc: fromlists
In-Reply-To: <478D79BD.7060006@talkingspider.com>
On 01/15/2008 09:27 PM, Mike wrote:
>
> How do I make the repository dir live somewhere else, the hell away from
> my code? Thanks
mv .git <location to move to>
ln -s <location moved to> .git
Did you try this before you sent your email?
-Dan
^ permalink raw reply
* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Daniel Barkalow @ 2008-01-16 3:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801151902080.2806@woody.linux-foundation.org>
On Tue, 15 Jan 2008, Linus Torvalds wrote:
> On Tue, 15 Jan 2008, Junio C Hamano wrote:
> >
> > If a non-standard prefix is used by --no-prefix, --src-prefix,
> > or --dst-prefix options, the resulting diff becomes something
> > git-apply would not grok. In such a case, we should not trigger
> > the more strict check git-apply does for patches in "diff --git"
> > format.
>
> I think this is wrong.
>
> If we do any git-specific stuff, we need to have that "--git" thing there.
> That is *not* just limited to the prefix, but to all the other things git
> diffs can do: renames, mode changes, etc.
Well, part of the issue is that, if you drop the prefix, then *git* can't
understand the resulting patch (because --git causes git-apply to use
open-coded -p1 handling of names, which won't be right).
I suppose the other option is to have the header in this case be:
diff --git --src-prefix= --dst-prefix= filename filename
so that apply can figure out what diff did correctly.
> > Metainformation (e.g. "index", "similarity", etc.) lines will
> > safely be ignored by patch and git-apply (even when the latter
> > parses a non-git diff output), so this patch does not bother
> > stripping them away.
>
> It's not necessarily safe to ignore some of them, like the rename info. If
> you see a rename patch and don't understand it as a rename, it's
> pointless.
>
> So I would argue that you need something stronger to say "don't do a git
> diff", and that should also disallow rename detection at a minimum. Quite
> frankly, any program that is so stupid as to not accept current git
> patches (ie TortoiseSVN), then we damn well shouldn't just disable the
> most trivial part of it. We should make sure that we do not enable *any*
> of the rather important extensions: even if ToirtoiseSVN would ignore
> them, if ignoring them means that it mis-understands the diff, it
> shouldn't be allowed at all.
>
> So maybe a --standard-diff option that removes the "--git" part, but also
> removes everything else.
That seems wise to me. We should be able to generate patches that are
accessible to programs that can't follow any clever instructions. I think
the point of the "Index:" header is that these programs will freak out if
two filenames don't match (or, more likely, break in some way), and it
means you can't sensibly generate patches that upset them for deletes or
creates.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 3:27 UTC (permalink / raw)
To: git
I'm learning git and I'm really annoyed that the .git directory lives in
the same directory as my code. I don't want it there for three reasons:
1. My code lives on a development web server docroot, and I don't want
the .git repository to end up getting published to the live site by
accident. (I would imagine this would be a common need.)
2. If I tar/gz my code and deliver it to a client, I don't want the .git
dir slipping into the tarball, allowing my client to be able to peruse
the history of what we did and when.
3. The .git respository will get big, especially with binary files in
it, and I want it someplace with a lot of disk space. And I don't want
it to get tarred up when we migrate the site to a different server. (And
tar isn't aware of hard links is it? wonderful.)
How do I make the repository dir live somewhere else, the hell away from
my code? Thanks
^ permalink raw reply
* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Linus Torvalds @ 2008-01-16 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801151902080.2806@woody.linux-foundation.org>
On Tue, 15 Jan 2008, Linus Torvalds wrote:
>
> If we do any git-specific stuff, we need to have that "--git" thing there.
> That is *not* just limited to the prefix, but to all the other things git
> diffs can do: renames, mode changes, etc.
Side note: the fact that git-apply itself might have issues with a
"--no-prefix" patch is really a red herring, because while it's true that
you would normally not do it for git, it's even more true that we haven't
actually started teaching git about it and the cases where you *would* use
it (eg recursive subproject diffs etc).
So I do not think it's true that "--no-prefix" (or --src/dst-prefix)
necessarily implies "no-git" at all. It *can* do so, but it's not a given
thing, and almost certainly isn't in the long run with submodule support.
So it would be kind of sad if we mixed it up with the prefix decision,
when it really is something totally separate. Many other SCM's may want a
simple "-p1" patch (BK did, for example), and that doesn't make them
particularly "git-like". And conversely, git itself will want more than a
simple "-p1" patch for subproject handling.
Linus
^ permalink raw reply
* Samba NTFS error "Could not rename the lock file?"
From: Mike @ 2008-01-16 3:13 UTC (permalink / raw)
To: git
git version 1.5.2.1
I have my repository on a linux server and I'm trying to create a "git
clone" on an NTFS samba mount. So for example:
$ git clone /www/git/amflex /mnt/NTFS80gigsamba/amflex
Could not rename the lock file?
Could not rename the lock file?
Could not rename the lock file?
Could not rename the lock file?
Initialized empty Git repository in /mnt/NTFS80gigsamba/amflex/.git/
remote: Generating pack...
remote: Done counting 156 objects.
remote: Deltifying 156 objects...
remote: 100% (156/156) done
Indexing 156 objects...
remote: Total 156 (delta 58), reused 0 (delta 0)
100% (156/156) done
Resolving 58 deltas...
100% (58/58) done
Could not rename the lock file?
Could not rename the lock file?
This isn't permissions because I can manually create, rename, delete all
the files on the samba mount, using the same login account, no problem.
fstab for the samba mount is:
//192.168.1.100/NTFS80gigsamba /mnt/NTFS80gigsamba
user,auto,file_mode=0777,dir_mode=0777,credentials=/etc/samba/auth.mike,uid=dmke
0 0
^ permalink raw reply
* [RFC/PATCH] Remove repo-config
From: Dan McGee @ 2008-01-16 3:19 UTC (permalink / raw)
To: git; +Cc: Dan McGee
'git config' has been used in place of 'git repo-config' for some time in
the documentation and most of the tools, so remove traces of repo-config
from the source.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
Mainly a request for comment, but I sent this patch becuase I noticed
repo-config is not even listed in command-list.txt. Before the 1.5.4 release,
I would think it either needs to be listed there or removed entirely.
Looking forward to 1.5.5, is there any reason to keep an old command like
this around? It is rarely used and needlessly complicates things, and the
manpage did nothing but send you to config anyway.
All tests pass on Linux 2.6.23.
-Dan
Documentation/git-repo-config.txt | 18 ------------------
Makefile | 4 ++--
contrib/completion/git-completion.bash | 1 -
contrib/examples/git-tag.sh | 1 +
git.c | 1 -
t/t0020-crlf.sh | 24 ++++++++++++------------
t/t9200-git-cvsexportcommit.sh | 2 +-
templates/hooks--update | 8 ++++----
8 files changed, 20 insertions(+), 39 deletions(-)
delete mode 100644 Documentation/git-repo-config.txt
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
deleted file mode 100644
index 2ca3994..0000000
--- a/Documentation/git-repo-config.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-git-repo-config(1)
-==================
-
-NAME
-----
-git-repo-config - Get and set repository or global options
-
-
-SYNOPSIS
---------
-'git-repo-config' ...
-
-
-DESCRIPTION
------------
-
-This is a synonym for linkgit:git-config[1]. Please refer to the
-documentation of that command.
diff --git a/Makefile b/Makefile
index 82e9cd6..603f4ac 100644
--- a/Makefile
+++ b/Makefile
@@ -262,7 +262,7 @@ EXTRA_PROGRAMS =
BUILT_INS = \
git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \
- git-get-tar-commit-id$X git-init$X git-repo-config$X \
+ git-get-tar-commit-id$X git-init$X \
git-fsck-objects$X git-cherry-pick$X git-peek-remote$X git-status$X \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
@@ -1145,7 +1145,7 @@ check-docs::
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
git-merge-resolve | git-merge-stupid | git-merge-subtree | \
- git-fsck-objects | git-init-db | git-repo-config | \
+ git-fsck-objects | git-init-db | \
git-?*--?* ) continue ;; \
esac ; \
test -f "Documentation/$$v.txt" || \
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 343364d..c63a642 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -333,7 +333,6 @@ __git_commands ()
read-tree) : plumbing;;
receive-pack) : plumbing;;
reflog) : plumbing;;
- repo-config) : plumbing;;
rerere) : plumbing;;
rev-list) : plumbing;;
rev-parse) : plumbing;;
diff --git a/contrib/examples/git-tag.sh b/contrib/examples/git-tag.sh
index ae7c531..a3182df 100755
--- a/contrib/examples/git-tag.sh
+++ b/contrib/examples/git-tag.sh
@@ -167,6 +167,7 @@ type=$(git cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
test -n "$username" ||
+ #NOTE: 'git repo-config' has since been replaced by 'git config'
username=$(git repo-config user.signingkey) ||
username=$(expr "z$tagger" : 'z\(.*>\)')
diff --git a/git.c b/git.c
index 15fec89..061d365 100644
--- a/git.c
+++ b/git.c
@@ -340,7 +340,6 @@ static void handle_internal_command(int argc, const char **argv)
{ "push", cmd_push, RUN_SETUP },
{ "read-tree", cmd_read_tree, RUN_SETUP },
{ "reflog", cmd_reflog, RUN_SETUP },
- { "repo-config", cmd_config },
{ "rerere", cmd_rerere, RUN_SETUP },
{ "reset", cmd_reset, RUN_SETUP },
{ "rev-list", cmd_rev_list, RUN_SETUP },
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 89baebd..8b27aa8 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -19,7 +19,7 @@ remove_cr () {
test_expect_success setup '
- git repo-config core.autocrlf false &&
+ git config core.autocrlf false &&
for w in Hello world how are you; do echo $w; done >one &&
mkdir dir &&
@@ -46,7 +46,7 @@ test_expect_success 'update with autocrlf=input' '
rm -f tmp one dir/two three &&
git read-tree --reset -u HEAD &&
- git repo-config core.autocrlf input &&
+ git config core.autocrlf input &&
for f in one dir/two
do
@@ -70,7 +70,7 @@ test_expect_success 'update with autocrlf=true' '
rm -f tmp one dir/two three &&
git read-tree --reset -u HEAD &&
- git repo-config core.autocrlf true &&
+ git config core.autocrlf true &&
for f in one dir/two
do
@@ -93,7 +93,7 @@ test_expect_success 'update with autocrlf=true' '
test_expect_success 'checkout with autocrlf=true' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf true &&
+ git config core.autocrlf true &&
git read-tree --reset -u HEAD &&
for f in one dir/two
@@ -117,7 +117,7 @@ test_expect_success 'checkout with autocrlf=true' '
test_expect_success 'checkout with autocrlf=input' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf input &&
+ git config core.autocrlf input &&
git read-tree --reset -u HEAD &&
for f in one dir/two
@@ -143,7 +143,7 @@ test_expect_success 'checkout with autocrlf=input' '
test_expect_success 'apply patch (autocrlf=input)' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf input &&
+ git config core.autocrlf input &&
git read-tree --reset -u HEAD &&
git apply patch.file &&
@@ -156,7 +156,7 @@ test_expect_success 'apply patch (autocrlf=input)' '
test_expect_success 'apply patch --cached (autocrlf=input)' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf input &&
+ git config core.autocrlf input &&
git read-tree --reset -u HEAD &&
git apply --cached patch.file &&
@@ -169,7 +169,7 @@ test_expect_success 'apply patch --cached (autocrlf=input)' '
test_expect_success 'apply patch --index (autocrlf=input)' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf input &&
+ git config core.autocrlf input &&
git read-tree --reset -u HEAD &&
git apply --index patch.file &&
@@ -183,7 +183,7 @@ test_expect_success 'apply patch --index (autocrlf=input)' '
test_expect_success 'apply patch (autocrlf=true)' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf true &&
+ git config core.autocrlf true &&
git read-tree --reset -u HEAD &&
git apply patch.file &&
@@ -196,7 +196,7 @@ test_expect_success 'apply patch (autocrlf=true)' '
test_expect_success 'apply patch --cached (autocrlf=true)' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf true &&
+ git config core.autocrlf true &&
git read-tree --reset -u HEAD &&
git apply --cached patch.file &&
@@ -209,7 +209,7 @@ test_expect_success 'apply patch --cached (autocrlf=true)' '
test_expect_success 'apply patch --index (autocrlf=true)' '
rm -f tmp one dir/two three &&
- git repo-config core.autocrlf true &&
+ git config core.autocrlf true &&
git read-tree --reset -u HEAD &&
git apply --index patch.file &&
@@ -224,7 +224,7 @@ test_expect_success '.gitattributes says two is binary' '
rm -f tmp one dir/two three &&
echo "two -crlf" >.gitattributes &&
- git repo-config core.autocrlf true &&
+ git config core.autocrlf true &&
git read-tree --reset -u HEAD &&
if remove_cr dir/two >/dev/null
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 910c584..a15222c 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -225,7 +225,7 @@ test_expect_success \
! git-cvsexportcommit -c $id
)'
-case "$(git repo-config --bool core.filemode)" in
+case "$(git config --bool core.filemode)" in
false)
;;
*)
diff --git a/templates/hooks--update b/templates/hooks--update
index bd93dd1..09a99ff 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -37,9 +37,9 @@ if [ -z "$refname" -o -z "$oldrev" -o -z "$newrev" ]; then
fi
# --- Config
-allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
-allowdeletebranch=$(git-repo-config --bool hooks.allowdeletebranch)
-allowdeletetag=$(git-repo-config --bool hooks.allowdeletetag)
+allowunannotated=$(git config --bool hooks.allowunannotated)
+allowdeletebranch=$(git config --bool hooks.allowdeletebranch)
+allowdeletetag=$(git config --bool hooks.allowdeletetag)
# check for no description
projectdesc=$(sed -e '1q' "$GIT_DIR/description")
@@ -53,7 +53,7 @@ fi
if [ "$newrev" = "0000000000000000000000000000000000000000" ]; then
newrev_type=delete
else
- newrev_type=$(git-cat-file -t $newrev)
+ newrev_type=$(git cat-file -t $newrev)
fi
case "$refname","$newrev_type" in
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Linus Torvalds @ 2008-01-16 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <7v7iiabjyh.fsf_-_@gitster.siamese.dyndns.org>
On Tue, 15 Jan 2008, Junio C Hamano wrote:
>
> If a non-standard prefix is used by --no-prefix, --src-prefix,
> or --dst-prefix options, the resulting diff becomes something
> git-apply would not grok. In such a case, we should not trigger
> the more strict check git-apply does for patches in "diff --git"
> format.
I think this is wrong.
If we do any git-specific stuff, we need to have that "--git" thing there.
That is *not* just limited to the prefix, but to all the other things git
diffs can do: renames, mode changes, etc.
> Metainformation (e.g. "index", "similarity", etc.) lines will
> safely be ignored by patch and git-apply (even when the latter
> parses a non-git diff output), so this patch does not bother
> stripping them away.
It's not necessarily safe to ignore some of them, like the rename info. If
you see a rename patch and don't understand it as a rename, it's
pointless.
So I would argue that you need something stronger to say "don't do a git
diff", and that should also disallow rename detection at a minimum. Quite
frankly, any program that is so stupid as to not accept current git
patches (ie TortoiseSVN), then we damn well shouldn't just disable the
most trivial part of it. We should make sure that we do not enable *any*
of the rather important extensions: even if ToirtoiseSVN would ignore
them, if ignoring them means that it mis-understands the diff, it
shouldn't be allowed at all.
So maybe a --standard-diff option that removes the "--git" part, but also
removes everything else.
And add a "--index-header" to enable the (totally *idiotic*) "Index:"
prefix that is such a total waste of time that it's not even funny (ie it
cannot do renames, which makes it entirely pointless).
We do not want to make it particularly easy for people to create
mind-bogglingly stupid diff output.
Linus
^ permalink raw reply
* Re: [PATCH 1/3] git-submodule: rename shell functions for consistency
From: Imran M Yousuf @ 2008-01-16 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7are3qo.fsf_-_@gitster.siamese.dyndns.org>
Thanks Junio for showing how it should be done. Due to some
pre-scheduled appointment I was unavailable yesterday evening and thus
was neither able to reply nor resubmit the changes.
On Jan 15, 2008 5:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> This renames the shell functions used in git-submodule that
> implement top-level subcommands. The rule is that the
> subcommand $foo is implemented by cmd_$foo function.
>
> A noteworthy change is that modules_list() is now known as
> cmd_status(). There is no "submodule list" command.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * We could probably do something like this. This first part is
> about making the command dispatcher maintainable.
>
> Note that I haven't seriously tested this series. This and
> the next one are primarily to illustrate what I think the fix
> you are trying should look like.
>
> git-submodule.sh | 20 ++++++++++----------
> 1 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ad9fe62..3c104e3 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -86,9 +86,9 @@ module_name()
> #
> # Clone a submodule
> #
> -# Prior to calling, modules_update checks that a possibly existing
> +# Prior to calling, cmd_update checks that a possibly existing
> # path is not a git repository.
> -# Likewise, module_add checks that path does not exist at all,
> +# Likewise, cmd_add checks that path does not exist at all,
> # since it is the location of a new submodule.
> #
> module_clone()
> @@ -121,7 +121,7 @@ module_clone()
> #
> # optional branch is stored in global branch variable
> #
> -module_add()
> +cmd_add()
After reading your reply I was about to suggest renaming module to cmd
but you have done it before I could propose or submit the patch.
> {
> repo=$1
> path=$2
> @@ -174,7 +174,7 @@ module_add()
> #
> # $@ = requested paths (default to all)
> #
> -modules_init()
> +cmd_init()
> {
> git ls-files --stage -- "$@" | grep -e '^160000 ' |
> while read mode sha1 stage path
> @@ -207,7 +207,7 @@ modules_init()
> #
> # $@ = requested paths (default to all)
> #
> -modules_update()
> +cmd_update()
> {
> git ls-files --stage -- "$@" | grep -e '^160000 ' |
> while read mode sha1 stage path
> @@ -266,7 +266,7 @@ set_name_rev () {
> #
> # $@ = requested paths (default to all)
> #
> -modules_list()
> +cmd_status()
> {
> git ls-files --stage -- "$@" | grep -e '^160000 ' |
> while read mode sha1 stage path
> @@ -347,16 +347,16 @@ esac
>
> case "$add,$init,$update,$status,$cached" in
> 1,,,,)
> - module_add "$@"
> + cmd_add "$@"
> ;;
> ,1,,,)
> - modules_init "$@"
> + cmd_init "$@"
> ;;
> ,,1,,)
> - modules_update "$@"
> + cmd_update "$@"
> ;;
> ,,,*,*)
> - modules_list "$@"
> + cmd_status "$@"
> ;;
> *)
> usage
> --
> 1.5.4.rc3.11.g4e67
>
>
--
Imran M Yousuf
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-16 2:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Brandon Casey, Git Mailing List, Alex Riesen,
Kristian Høgsberg
In-Reply-To: <7vmyr6bluy.fsf@gitster.siamese.dyndns.org>
On Tue, 15 Jan 2008, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> While I think the ones that are immediately followed by
>> commit_locked_index() can drop the close(fd) safely, I am not
>> sure about Kristian's changes to the other ones that we
>> currently close(fd) but do not commit nor rollback immediately.
>> These indices are now shown to the hook with open fd to it if
>> you choose not to close them. Is that okay for Windows guys? I
>> somehow had an impression that the other process may have
>> trouble accessing a file that is still open elsewhere for
>> writing.
>>
>> So I think the approach along the lines of your "hack" to close
>> and tell lockfile API not to double-close is more appropriate.
>> We would perhaps want "close_lock_file(struct lock_file *)" that
>> calls close(lk->fd) and does lk->fd = -1 without rename/unlink,
>> and replace these close() with that.
>>
>> I am sick today, feeling feverish, and not thinking straight,
>> so I may be talking total nonsense...
> I'll aplly and push out Kristian's one that apparently got
> Tested-by from Brandon for tonight.
I've got a followup patch coming that will remove the rest of
the redundant close()'s and I'll look into your suggestion for
close_lock_file() above.
Currently everything passes the test suite, I just need to do
some manual testing.
-brandon
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Daniel Barkalow @ 2008-01-16 2:20 UTC (permalink / raw)
To: Chris Ortman; +Cc: Jean-Luc Herren, git
In-Reply-To: <c0f2d4110801151230g5843df66t62fb659375a1680e@mail.gmail.com>
On Tue, 15 Jan 2008, Chris Ortman wrote:
> You are correct about Tortoise in that it is too strict.
> I looked through their code and they have written their own patch
> program which keys off these Index: lines
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TortoiseMerge/Patch.cpp
>
> I think it could go either way as to if git-svn creates a different
> format patch or tsvn accepts multiple formats, but I anticipated
> git-svn would be easier to extend so I started here.
I think it would be worthwhile for tsvn to be less picky in some ways. It
should at least be able to accept GNU diff, since sometimes people send
maintainers patches prepared by hand (diff -u file.c.orig file.c), and
there are comments in there that suggest that they're trying to support
non-svn-generated diffs, although they seem to think that such diffs look
like:
Index: filename
============
@@ -xxx,xxx +xxx,xxx @@
...
which isn't anything I've ever seen. You're much more likely to get:
...junk...
--- junk
+++ filename junk
@@ -xxx,xxx +xxx,xxx @@
And that should be easy enough to parse as an alternative format in tsvn.
(I'd send them a patch to do it, but they wouldn't be able to apply it...)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH/RFC] Do not show "diff --git" metainfo with --no-prefix
From: Junio C Hamano @ 2008-01-16 2:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Chris Ortman, git
In-Reply-To: <alpine.LNX.1.00.0801152056030.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> At most, I think, if a_one and b_two are identical, we could use the
> "Index:" form, since "diff -ur something something" is weird (how can
> "something" be different from itself?).
I think you can have --src-prefix=a- --dst-prefix=b- and see
"diff a-foo b-foo" ;-). I really do not care much either way,
as long as it does not say "diff --git".
This is also an offtopic remark but I have been wondering how
safe those fake "diff --git" output people seem to be able to
get out of recent-enough Hg.
^ permalink raw reply
* [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Junio C Hamano @ 2008-01-16 2:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Chris Ortman, Johannes Schindelin, git
In-Reply-To: <7v4pded1rk.fsf_-_@gitster.siamese.dyndns.org>
If a non-standard prefix is used by --no-prefix, --src-prefix,
or --dst-prefix options, the resulting diff becomes something
git-apply would not grok. In such a case, we should not trigger
the more strict check git-apply does for patches in "diff --git"
format.
This checks the prefix specified when generating diff. If src
and dst prefix are not one-level of directory name followed by a
slash (i.e. the standard "diff --git a/foo b/foo" is fine, a
custom "diff --git l/foo k/foo" is Ok, but "diff --git foo foo"
is NOT Ok), we are generating with a custom prefix that would
fail git-apply's stricter check. In such a case, we do not say
"diff --git" but just say "diff" in the header.
Metainformation (e.g. "index", "similarity", etc.) lines will
safely be ignored by patch and git-apply (even when the latter
parses a non-git diff output), so this patch does not bother
stripping them away.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I am signing this off, but I am not thinking straight today
and did not test it, so I will not commit it for now and
leave it in the list archive, to be commented on.
diff.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index b18c140..8321492 100644
--- a/diff.c
+++ b/diff.c
@@ -1233,6 +1233,18 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
return NULL;
}
+static int with_standard_prefix(struct diff_options *o)
+{
+ const char *slash;
+ slash = strchr(o->a_prefix, '/');
+ if (!slash || slash[1])
+ return 0;
+ slash = strchr(o->b_prefix, '/');
+ if (!slash || slash[1])
+ return 0;
+ return 1;
+}
+
static void builtin_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
@@ -1246,12 +1258,15 @@ static void builtin_diff(const char *name_a,
char *a_one, *b_two;
const char *set = diff_get_color_opt(o, DIFF_METAINFO);
const char *reset = diff_get_color_opt(o, DIFF_RESET);
+ const char *gitdiff;
+
+ gitdiff = with_standard_prefix(o) ? " --git" : "";
a_one = quote_two(o->a_prefix, name_a + (*name_a == '/'));
b_two = quote_two(o->b_prefix, name_b + (*name_b == '/'));
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
- printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
+ printf("%sdiff%s %s %s%s\n", set, gitdiff, a_one, b_two, reset);
if (lbl[0][0] == '/') {
/* /dev/null */
printf("%snew file mode %06o%s\n", set, two->mode, reset);
^ permalink raw reply related
* Re: [PATCH/RFC] Do not show "diff --git" metainfo with --no-prefix
From: Daniel Barkalow @ 2008-01-16 2:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Chris Ortman, git
In-Reply-To: <alpine.LSU.1.00.0801160152540.17650@racer.site>
On Wed, 16 Jan 2008, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 15 Jan 2008, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > >> diff --git a/diff.c b/diff.c
> > >> index b18c140..8126a74 100644
> > >> --- a/diff.c
> > >> +++ b/diff.c
> > >> @@ -1246,30 +1258,46 @@ static void builtin_diff(const char *name_a,
> > >> char *a_one, *b_two;
> > >> const char *set = diff_get_color_opt(o, DIFF_METAINFO);
> > >> const char *reset = diff_get_color_opt(o, DIFF_RESET);
> > >> + int is_git_diff = with_standard_prefix(o);
> > >>
> > >> a_one = quote_two(o->a_prefix, name_a + (*name_a == '/'));
> > >> b_two = quote_two(o->b_prefix, name_b + (*name_b == '/'));
> > >> lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
> > >> lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
> > >> - printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
> > >> +
> > >> + if (!is_git_diff)
> > >> + printf("%sIndex: %s%s\n", set, b_two, reset);
> > >> + else
> > >> + printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
> > >> +
> > >
> > > Hmm. AFAICT plain diff outputs "diff ...", not "Index: ...". IMHO doing
> > > half of what SVN does, and half what GNU diff does, but not completely
> > > what something else does, does not help anybody.
> > >
> > > So I'm mildly negative on this hunk.
> >
> > You misread the intention of the patch.
> >
> > This whole point of this RFC patch is about not labelling a non-git
> > patch that results from --no-prefix with "diff --git". As I said in my
> > reply to Daniel, I do not like "Index:" myself, and doing printf("diff
> > %s %s\n", a_one, b_two) instead would be perfectly fine by me.
>
> Well, I commented on this hunk specifically, and think that the intention
> of the patch would be better served by just conditionally omitting
> "--git", and nothing else.
At most, I think, if a_one and b_two are identical, we could use the
"Index:" form, since "diff -ur something something" is weird (how can
"something" be different from itself?). If they're different, definitely
use "diff %s %s".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Chris Ortman @ 2008-01-16 2:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0801151728120.13593@iabervon.org>
I'm sorry I completely forgot there was username / password on that link
username: guest
password: ''
Tortoise does care about the line of equals signs, although it seems
like an unecessary one from my understanding.
>From the best I can tell it doesn't look like tortoise actually cares
that the svn revision be something valid, just that something is there
as a placeholder
^ permalink raw reply
* [PATCH] treat any file with NUL as binary
From: Dmitry Potapov @ 2008-01-16 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska, Dmitry Potapov
In-Reply-To: <7vr6gibm56.fsf@gitster.siamese.dyndns.org>
There are two heuristics in Git to detect whether a file is binary
or text. One in xdiff-interface.c (which is taken from GNU diff)
relies on existence of the NUL byte at the beginning. However,
convert.c used a different heuristic, which relied on the percent
of non-printable symbols (less than 1% for text files).
Due to differences in detection whether a file is binary or not,
it was possible that a file that diff treats as binary could be
treated as text by CRLF conversion. This is very confusing for a
user who sees that 'git diff' shows the file as binary expects it
to be added as binary.
This patch makes is_binary to consider any file that contains at
least one NUL character as binary, to ensure that the heuristics
used for CRLF conversion is tighter than what is used by diff.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
convert.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 5adef4f..a51da1f 100644
--- a/convert.c
+++ b/convert.c
@@ -17,8 +17,8 @@
#define CRLF_INPUT 2
struct text_stat {
- /* CR, LF and CRLF counts */
- unsigned cr, lf, crlf;
+ /* NUL, CR, LF and CRLF counts */
+ unsigned nul, cr, lf, crlf;
/* These are just approximations! */
unsigned printable, nonprintable;
@@ -51,6 +51,9 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
case '\b': case '\t': case '\033': case '\014':
stats->printable++;
break;
+ case 0:
+ stats->nul++;
+ /* fall through */
default:
stats->nonprintable++;
}
@@ -66,6 +69,8 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
static int is_binary(unsigned long size, struct text_stat *stats)
{
+ if (stats->nul)
+ return 1;
if ((stats->printable >> 7) < stats->nonprintable)
return 1;
/*
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH/RFC] Do not show "diff --git" metainfo with --no-prefix
From: Johannes Schindelin @ 2008-01-16 1:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Chris Ortman, git
In-Reply-To: <7vir1ubl0g.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 15 Jan 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> diff --git a/diff.c b/diff.c
> >> index b18c140..8126a74 100644
> >> --- a/diff.c
> >> +++ b/diff.c
> >> @@ -1246,30 +1258,46 @@ static void builtin_diff(const char *name_a,
> >> char *a_one, *b_two;
> >> const char *set = diff_get_color_opt(o, DIFF_METAINFO);
> >> const char *reset = diff_get_color_opt(o, DIFF_RESET);
> >> + int is_git_diff = with_standard_prefix(o);
> >>
> >> a_one = quote_two(o->a_prefix, name_a + (*name_a == '/'));
> >> b_two = quote_two(o->b_prefix, name_b + (*name_b == '/'));
> >> lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
> >> lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
> >> - printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
> >> +
> >> + if (!is_git_diff)
> >> + printf("%sIndex: %s%s\n", set, b_two, reset);
> >> + else
> >> + printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
> >> +
> >
> > Hmm. AFAICT plain diff outputs "diff ...", not "Index: ...". IMHO doing
> > half of what SVN does, and half what GNU diff does, but not completely
> > what something else does, does not help anybody.
> >
> > So I'm mildly negative on this hunk.
>
> You misread the intention of the patch.
>
> This whole point of this RFC patch is about not labelling a non-git
> patch that results from --no-prefix with "diff --git". As I said in my
> reply to Daniel, I do not like "Index:" myself, and doing printf("diff
> %s %s\n", a_one, b_two) instead would be perfectly fine by me.
Well, I commented on this hunk specifically, and think that the intention
of the patch would be better served by just conditionally omitting
"--git", and nothing else.
> I do not mind keeping the metainformation such as rename/deleted labels
> in the output of non-git case (iow, dropping all the other hunks that
> pay attention to is_git_diff in the RFC patch). As long as the patch is
> not labelled with "diff --git", stricter checks in git-apply will not
> trigger, and it knows to skip these non-patch lines. Also a plain GNU
> patch would ignore those metainformation lines, so there is no strong
> reason to remove them from the output, unless somebody wants to use non
> patch non git tool that is stricter for no good reason (and I'd agree
> with you that the solution to such a tool is a postprocessing filter
> outside of git).
Fair enough.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] Do not show "diff --git" metainfo with --no-prefix
From: Junio C Hamano @ 2008-01-16 1:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Chris Ortman, git
In-Reply-To: <alpine.LSU.1.00.0801160133150.17650@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> diff --git a/diff.c b/diff.c
>> index b18c140..8126a74 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -1246,30 +1258,46 @@ static void builtin_diff(const char *name_a,
>> char *a_one, *b_two;
>> const char *set = diff_get_color_opt(o, DIFF_METAINFO);
>> const char *reset = diff_get_color_opt(o, DIFF_RESET);
>> + int is_git_diff = with_standard_prefix(o);
>>
>> a_one = quote_two(o->a_prefix, name_a + (*name_a == '/'));
>> b_two = quote_two(o->b_prefix, name_b + (*name_b == '/'));
>> lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
>> lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
>> - printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
>> +
>> + if (!is_git_diff)
>> + printf("%sIndex: %s%s\n", set, b_two, reset);
>> + else
>> + printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
>> +
>
> Hmm. AFAICT plain diff outputs "diff ...", not "Index: ...". IMHO doing
> half of what SVN does, and half what GNU diff does, but not completely
> what something else does, does not help anybody.
>
> So I'm mildly negative on this hunk.
You misread the intention of the patch.
This whole point of this RFC patch is about not labelling a
non-git patch that results from --no-prefix with "diff --git".
As I said in my reply to Daniel, I do not like "Index:" myself,
and doing printf("diff %s %s\n", a_one, b_two) instead would be
perfectly fine by me.
I do not mind keeping the metainformation such as rename/deleted
labels in the output of non-git case (iow, dropping all the
other hunks that pay attention to is_git_diff in the RFC patch).
As long as the patch is not labelled with "diff --git", stricter
checks in git-apply will not trigger, and it knows to skip these
non-patch lines. Also a plain GNU patch would ignore those
metainformation lines, so there is no strong reason to remove
them from the output, unless somebody wants to use non patch non
git tool that is stricter for no good reason (and I'd agree with
you that the solution to such a tool is a postprocessing filter
outside of git).
^ permalink raw reply
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Johannes Schindelin @ 2008-01-16 1:40 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, git
In-Reply-To: <478D5D07.3030202@gmail.com>
Hi,
On Tue, 15 Jan 2008, Mark Levedahl wrote:
> Johannes Schindelin wrote:
>
> > There's got to be a way to fix this _without_ affecting other users.
> I believe the only normally visible change from my proposal is that
> git-submodule update will follow top-level's branch from
> branch.<name>.remote, which is a good thing. The other changes are only
> visible if using clone -o or otherwise explicitly asking that "origin"
> not be used or defined, which again is actually following the user's
> request.
>
> If you know of other effects, please explain them.
Do I really have to explain this late in the game for 1.5.4 how such
intrusive changes can affect stability of code paths which would be
otherwise unaffected by submodules? I think not.
Ciao,
Dscho
^ 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