* Re: Deciding between Git/Mercurial
From: Leo Razoumov @ 2009-09-30 0:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Anteru, git
In-Reply-To: <200909292058.53045.jnareb@gmail.com>
On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 29 Sep 2009, Leo Razoumov wrote:
> > On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> > > [..snip..]
> > > Besides with nonlinear history with
> > > revision numbers such as 12678 and 12687 you know that 12678 is older
> > > than 12687 if and only if 12678 and 12687 are on the same line of
> > > development.
> >
> > The statement above is incorrect!! In a Mercurial repo local revision
> > numbers are strictly ordered in commit time. 12678 < 12687 means that
> > 12678 was committed prior to 12687. But these two commits could belong
> > to two completely unrelated lines of development.
>
>
> This is impossible with distributed development. If the second branch
> comes from other repository, with commits _created_ (in that repository)
> earlier than commits in current repository, but commits in first
> branch (from current repository) were created earlier than _fetching_
> those commits in second branch:
>
> .---.---.---.---x---1---2---3---M---.
> \ /
> \-A---B---C-/ <-- from repository B
>
>
> Either you would have to change commits numbers, and therefore they would
> be not stable, or you would have to change commit time to mean 'time this
> commit got into current repository', which would kill performance for sure.
>
Jakub,
in Mercurial sequential commit numbers are local to a repo and are not
unique between the clones. Unique ID is SHA1 as in git. So mercurial
commit 127:aaf123453dfgdfgddd...
means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
In another clone commit 127 might mean completely different thing.
Sequential commit numbers are strictly for "local convenience".
--Leo--
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Björn Steinbrink @ 2009-09-30 6:28 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Jakub Narebski, Anteru, git
In-Reply-To: <ee2a733e0909291749s71801b29ufa827cab715d0abb@mail.gmail.com>
On 2009.09.29 20:49:52 -0400, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Tue, 29 Sep 2009, Leo Razoumov wrote:
> > > On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> > > > [..snip..]
> > > > Besides with nonlinear history with
> > > > revision numbers such as 12678 and 12687 you know that 12678 is older
> > > > than 12687 if and only if 12678 and 12687 are on the same line of
> > > > development.
> > >
> > > The statement above is incorrect!! In a Mercurial repo local revision
> > > numbers are strictly ordered in commit time. 12678 < 12687 means that
> > > 12678 was committed prior to 12687. But these two commits could belong
> > > to two completely unrelated lines of development.
> >
> > This is impossible with distributed development. If the second branch
> > comes from other repository, with commits _created_ (in that repository)
> > earlier than commits in current repository, but commits in first
> > branch (from current repository) were created earlier than _fetching_
> > those commits in second branch:
> >
> > .---.---.---.---x---1---2---3---M---.
> > \ /
> > \-A---B---C-/ <-- from repository B
> >
> >
> > Either you would have to change commits numbers, and therefore they would
> > be not stable, or you would have to change commit time to mean 'time this
> > commit got into current repository', which would kill performance for sure.
> >
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
To quote his first mail:
First, you have to remember that this 'number of commit' thingy
is *local* to your repository, so you cannot use commit numbers
to communicate with other developers.
With the above example, he has just shown that even with those local
commit numbers, you can't tell that commit X is older than commit Y just
because X < Y.
Björn
^ permalink raw reply
* Re: [PATCH 5/6 (v4)] full integration of rev-cache into git, completed test suite
From: Chris Johnsen @ 2009-09-30 7:53 UTC (permalink / raw)
To: Nick Edelen
Cc: Chris Johnsen, git, Sam Vilain, Junio C Hamano, Nicolas Pitre,
Johannes Schindelin, Michael J Gruber, Jeff King, Shawn O. Pearce,
Andreas Ericsson, Christian Couder
In-Reply-To: <op.uzv4covmtdk399@sirnot.private>
(The Cc list of the parent message was truncated.
The Cc list of this message was adopted from later messages.)
I needed something like the following to get the tests to pass.
If you like it, squash it into 5/6.
-->8--
Subject: [PATCH] t6017: use 'tr -d' to strip spaces from 'wc -c' output
The previous use of 'grep -o "[0-9]*"' was producing an empty string
(GNU grep 2.5.1 on Mac OS X 10.4.11). Additionally, since 'wc' echos
its filename arguments when stdin is not the source, the 'grep -o'
might have also extracted additional decimal strings embedded in the
filename (a SHA-1 hash value).
This 'tr -d' style is used in git-filter-branch.sh, and t6003.
Another alternative (in t1006) is to use 'sed' to strip off the
leading spaces.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
t/t6017-rev-cache-list.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6017-rev-cache-list.sh b/t/t6017-rev-cache-list.sh
index 6ada7ac..3f49cb3 100755
--- a/t/t6017-rev-cache-list.sh
+++ b/t/t6017-rev-cache-list.sh
@@ -246,7 +246,7 @@ test_expect_success 'make fragmented slices' '
test `grep "final return value: 0" output.err | wc -l` -eq 3
'
-cache_size=`wc -c .git/rev-cache/$cache_sha1 | grep -o "[0-9]*"`
+cache_size=`wc -c < .git/rev-cache/$cache_sha1 | tr -d ' '`
test_expect_success 'test --ignore-size function in fuse' '
git-rev-cache fuse --ignore-size=$cache_size 2>output.err &&
grep "final return value: 0" output.err &&
--
1.6.5.rc1.183.g23fa6
^ permalink raw reply related
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Chris Johnsen @ 2009-09-30 8:00 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nick Edelen, Junio C Hamano, Nicolas Pitre, Johannes Schindelin,
Sam Vilain, Michael J Gruber, Jeff King, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <20090929163414.GA25756@spearce.org>
On 2009 Sep 29, at 11:34, Shawn O. Pearce wrote:
> Nick Edelen <sirnot@gmail.com> wrote:
>> diff --git a/builtin-rev-cache.c b/builtin-rev-cache.c
>> index 4c1766d..b36bc39 100644
>
> This doesn't apply against ne/rev-cache^, and I don't have the
> blobs in my repostiory. So I'm dropping this patch and will wait
> for a resend of the series or something...
It appears that the patch suffers from "format=flowed" whitespace
mangling. This caused the context lines to have an extra leading
space character.
After running a ham-fisted "sed -e 's/^ / /'" over the patch,
'git am' was able to apply it to ne/rev-cache^ (d05c9be9fa) even
though one of the referenced blobs (6c96297; rev-cache.c) was missing.
--
Chris
^ permalink raw reply
* Re: [PATCH 5/6 (v4)] full integration of rev-cache into git, completed test suite
From: Johannes Sixt @ 2009-09-30 8:09 UTC (permalink / raw)
To: Chris Johnsen
Cc: Nick Edelen, git, Sam Vilain, Junio C Hamano, Nicolas Pitre,
Johannes Schindelin, Michael J Gruber, Jeff King, Shawn O. Pearce,
Andreas Ericsson, Christian Couder
In-Reply-To: <1254297229-14806-1-git-send-email-chris_johnsen@pobox.com>
Chris Johnsen schrieb:
> -cache_size=`wc -c .git/rev-cache/$cache_sha1 | grep -o "[0-9]*"`
> +cache_size=`wc -c < .git/rev-cache/$cache_sha1 | tr -d ' '`
> test_expect_success 'test --ignore-size function in fuse' '
> git-rev-cache fuse --ignore-size=$cache_size 2>output.err &&
> grep "final return value: 0" output.err &&
You can also have the shell strip the blanks:
cache_size=$(wc -c < .git/rev-cache/$cache_sha1)
test_expect_success 'test --ignore-size function in fuse' '
git-rev-cache fuse --ignore-size=${cache_size##* } 2>output.err &&
grep "final return value: 0" output.err &&
-- Hannes
^ permalink raw reply
* [gitk] after exiting gitk the X11 clipboard is "messed up" - it contains the wrong commit
From: Christoph Duelli @ 2009-09-30 8:38 UTC (permalink / raw)
To: git
(Using git 1.6.5.rc1.19.g8426 on SLES10 Linux) I am having the following
problem:
1) gitk somefile.c
2) find the interesting commit, double click the sha1 id to bring it
into the clipboard (works)
3) exit gitk
4) gitk <paste from clipboard>
-> the id that is pasted is NOT the one I double clicked but the first
one in the list
As a workaround I paste the ID first and exit gitk later, but this is a
bit annoying (and a trap for gitk users).
See also
http://article.gmane.org/gmane.comp.version-control.git/65845/match=gitk+clipboard
Best regards and thank you for a helpful tool.
--
Christoph Duelli
---------------------------------------------------------------------------------
MELOS GmbH
Medizinische Labor-Organisations-Systeme GmbH
Franz-Beer-Straße 6
86459 Gessertshausen
Tel.: +49 8238/9611-0
Fax: +49 8238/9611-99
mailto: info@melosgmbh.de
URL: www.melosgmbh.de
Amtsgericht Augsburg, HRB 13226
USt-IdNr. DE 130 958 139
Geschäftsführer:
Herbert Mayer, Andreas Manntz, Helmut Welsch
--------------------------------------------
This e-mail (including any attachments) is confidential and may be privileged. If you have received it by mistake, please notify the sender by e-mail and delete it from your system.
Any unauthorised use or dissemination of this e-mail or its contents in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change.
MELOS GmbH shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt.
MELOS GmbH does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Andreas Ericsson @ 2009-09-30 9:17 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Jakub Narebski, Anteru, git
In-Reply-To: <ee2a733e0909291749s71801b29ufa827cab715d0abb@mail.gmail.com>
On 09/30/2009 02:49 AM, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski<jnareb@gmail.com> wrote:
>> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>> > On 2009-09-28, Jakub Narebski<jnareb@gmail.com> wrote:
>> > > [..snip..]
>> > > Besides with nonlinear history with
>> > > revision numbers such as 12678 and 12687 you know that 12678 is older
>> > > than 12687 if and only if 12678 and 12687 are on the same line of
>> > > development.
>> >
>> > The statement above is incorrect!! In a Mercurial repo local revision
>> > numbers are strictly ordered in commit time. 12678< 12687 means that
>> > 12678 was committed prior to 12687. But these two commits could belong
>> > to two completely unrelated lines of development.
>>
>>
>> This is impossible with distributed development. If the second branch
>> comes from other repository, with commits _created_ (in that repository)
>> earlier than commits in current repository, but commits in first
>> branch (from current repository) were created earlier than _fetching_
>> those commits in second branch:
>>
>> .---.---.---.---x---1---2---3---M---.
>> \ /
>> \-A---B---C-/<-- from repository B
>>
>>
>> Either you would have to change commits numbers, and therefore they would
>> be not stable, or you would have to change commit time to mean 'time this
>> commit got into current repository', which would kill performance for sure.
>>
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
>
Personally I much prefer the "commit'ish-backward" notation of git,
where HEAD~4 means "the commit 4 commits back from HEAD".
You'd get awfully tired of writing the six-digit "shorthand" numbers
of large projects fairly quickly, I imagine.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthias Andree @ 2009-09-30 11:09 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
Anteru schrieb:
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...
That tale is told all over, but that doesn't make it truer. I've never had
issues getting a Cygwin version of git to work properly (haven't tried the
msysgit or jgit variants, never felt the need), and integration went smooth.
With Mercurial, getting it integrated with a Windows-native Emacs (Cygwin emacs
doesn't work for me but hangs on startup) was somewhat of an undertaking even
with Cygwin's bash (rather than cmdproxy) underneath Emacs. It boiled down to
building Mercurial with py2exe and create an installer and use the compiled
hg.exe which I find starts rather slowly.
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).
Yes, but beware of git-svn under Cygwin 1.5 - that works for svn+ssh:// URLs,
but https:// or file:// don't work well because the underdocumented gazillion of
dependencies piece of sh.. called apr does stupid things WRT temporary files
since the Cygwin Subversion 1.6 days. Cygwin's Subversion 1.5 fared better.
I'm not sure about msysgit or jgit projects, but for Cygwin you'll definitely
want to take the plunge and go for Cygwin 1.7 which is still in Beta (because
that allows you to remove a file and create a file with the same name, which
doesn't work with Cygwin 1.5).
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Jakub Narebski @ 2009-09-30 11:09 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Anteru, git
In-Reply-To: <ee2a733e0909291749s71801b29ufa827cab715d0abb@mail.gmail.com>
On Wed, 30 Sep 2009, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>>> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> [..snip..]
>>>> Besides with nonlinear history with
>>>> revision numbers such as 12678 and 12687 you know that 12678 is older
>>>> than 12687 if and only if 12678 and 12687 are on the same line of
>>>> development.
>>>
>>> The statement above is incorrect!! In a Mercurial repo local revision
>>> numbers are strictly ordered in commit time. 12678 < 12687 means that
>>> 12678 was committed prior to 12687. But these two commits could belong
>>> to two completely unrelated lines of development.
>>
>> This is impossible with distributed development. If the second branch
>> comes from other repository, with commits _created_ (in that repository)
>> earlier than commits in current repository, but commits in first
>> branch (from current repository) were created earlier than _fetching_
>> those commits in second branch:
>>
>> .---.---.---.---x---1---2---3---M---.
>> \ /
>> \-A---B---C-/ <-- from repository B
>>
>>
>> Either you would have to change commits numbers, and therefore they would
>> be not stable, or you would have to change commit time to mean 'time this
>> commit got into current repository', which would kill performance for sure.
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
Yes, I know that in Mercurial commit numbers are local to repository,
and even written about it (that sequential commit numbers are possible
only either as local identifiers, or in centralized workflow).
The issue I was writing about that sequential commit numbers cannot
tell us if commit was earlier or later than some other commit based
solely on those commit numbers. As other people in this thread wrote
Mercurial numbers commits not in order of commit creation, but in
order of commit arriving (being present) in given repository. So
commit numbers are not 'strictly ordered in commit time', but ordered
in 'time commit got into current (local) repository'.
I'd like also to note that this means that at some time Mercurial has
to number all those commit it got on fetch / pull from remote repository.
This can be a lot of work... work which Git doesn't have to do (OTOH Git
creates index for packfile on local side after fetch...).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthias Andree @ 2009-09-30 11:14 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0909281059180.4985@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> I tried to refrain from commenting in this thread, because I do not want
> to encourage people just to use msysGit and never even attempt to fix
> their own issues.
>
> But I cannot let this go uncommented:
>
> On Mon, 28 Sep 2009, Felipe Contreras wrote:
>
>> IMO the key difference between hg and git is the storage model: hg
>> stores deltas, while git stores snapshots. That would mean that certain
>> operations are theoretically faster in git (e.g. checkout, diff) while
>> others faster in hg, although with git's packed format I guess there's
>> no operation faster in hg. This means that it doesn't matter how much
>> hg's python code improves, or if they even re-write parts in C, they
>> will never be able to match git's performance (unless they change the
>> storage model, which essentially means changing the whole design --
>> won't happen).
>
> That is wrong. "git log -- <file>" will always be slightly faster in
> Mercurial, for all the reasons you mentioned.
>
> In addition, Mercurial _has_ parts re-written in C for performance, which
> renders it not-exactly more portable if you ask me. Last time I checked,
> there was no way to compile a Python module with MinGW (or for that
> matter, Python itself), but you needed MSVC...
I have a shortish mercurial build script that works under Cygwin 1.5 and uses
msys, py2exe and iscc to build an installable Mercurial package, but I'm not
sure what this boils down to WRT C-versions of "modules". Maybe these are lumped
into the resulting hg.exe, I never bothered to check the details.
^ permalink raw reply
* Re: [PATCH] send-email: fix mutt regex for grouped aliases
From: Jeff King @ 2009-09-30 11:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Eric Wong
In-Reply-To: <1254269323-16600-1-git-send-email-felipe.contreras@gmail.com>
On Wed, Sep 30, 2009 at 03:08:43AM +0300, Felipe Contreras wrote:
> For example:
> alias -group friends foo Foo Bar <foo@bar.com>
Hmm. If I am reading the mutt docs correctly, is it also legal to have:
alias -group group1 -group group2 foo Foo Bar <foo@bar.com>
?
Which would need just:
> - if (/^\s*alias\s+(\S+)\s+(.*)$/) {
> + if (/^\s*alias\s+(?:-group\s+\S+\s+)?(\S+)\s+(.*)$/) {
(?:-group\s+\S+\s+)*
I think.
-Peff
^ permalink raw reply
* search branches which contain a blob id
From: Reto Glauser @ 2009-09-30 12:38 UTC (permalink / raw)
To: git
To get a list of branches which contain a specific commit we use:
$ git branch --contains <commit id>
Is there a similar way to get a list of branches with respect to a
specific blob (e.g. the actual code change a commit introduces)?
Obvious use-case: One isn't interested in the commit information (author,
parent, date) but merely in the set of changes a commit introduces.
^ permalink raw reply
* Re: search branches which contain a blob id
From: Tomas Carnecky @ 2009-09-30 13:43 UTC (permalink / raw)
To: Reto Glauser; +Cc: git
In-Reply-To: <8a906e45ab8e0252a0be11e4d4e9389e@blinkeye.ch>
On Sep 30, 2009, at 2:38 PM, Reto Glauser wrote:
> To get a list of branches which contain a specific commit we use:
>
> $ git branch --contains <commit id>
>
> Is there a similar way to get a list of branches with respect to a
> specific blob (e.g. the actual code change a commit introduces)?
Blob == contents of a file. To see what code changed you need to
compare two blobs (or trees).
> Obvious use-case: One isn't interested in the commit information
> (author,
> parent, date) but merely in the set of changes a commit introduces.
git log -S'string to search for'
searches the history for commits which introduced or removed that
string from a file.
Or 'git log -p', if you want to see the diff alongside the other
information that log gives you.
tom
^ permalink raw reply
* [JGIT PATCH] Include description for missing prereqs
From: Sasa Zivkov @ 2009-09-30 14:41 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git, Sasa Zivkov
From: Sasa Zivkov <sasa.zivkov@sap.com>
When throwing MissingBundlePrerequisiteException we
also include the short description, if available, of
each missing object.
This is the fix for the following issue:
http://code.google.com/p/egit/issues/detail?id=25
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
---
.../errors/MissingBundlePrerequisiteException.java | 19 +++++++++++--------
.../jgit/transport/BundleFetchConnection.java | 20 +++++++++++++-------
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java b/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java
index cc7b34b..b91f3cd 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java
@@ -37,7 +37,7 @@
package org.eclipse.jgit.errors;
-import java.util.Collection;
+import java.util.Map;
import org.eclipse.jgit.lib.ObjectId;
import org.eclipse.jgit.transport.URIish;
@@ -48,12 +48,14 @@
public class MissingBundlePrerequisiteException extends TransportException {
private static final long serialVersionUID = 1L;
- private static String format(final Collection<ObjectId> ids) {
+ private static String format(final Map<ObjectId, String> missingCommits) {
final StringBuilder r = new StringBuilder();
r.append("missing prerequisite commits:");
- for (final ObjectId p : ids) {
+ for (final Map.Entry<ObjectId, String> e : missingCommits.entrySet()) {
r.append("\n ");
- r.append(p.name());
+ r.append(e.getKey().name());
+ if (e.getValue() != null)
+ r.append(" ").append(e.getValue());
}
return r.toString();
}
@@ -63,11 +65,12 @@ private static String format(final Collection<ObjectId> ids) {
*
* @param uri
* URI used for transport
- * @param ids
- * the ids of the base/common object(s) we don't have.
+ * @param missingCommits
+ * the Map of the base/common object(s) we don't have. Keys are
+ * ids of the missing objects and values are short descriptions.
*/
public MissingBundlePrerequisiteException(final URIish uri,
- final Collection<ObjectId> ids) {
- super(uri, format(ids));
+ final Map<ObjectId, String> missingCommits) {
+ super(uri, format(missingCommits));
}
}
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java b/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java
index 42888cf..ceb51d9 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java
@@ -44,9 +44,10 @@
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
-import java.util.HashSet;
+import java.util.HashMap;
import java.util.LinkedHashMap;
import java.util.List;
+import java.util.Map;
import java.util.Set;
import org.eclipse.jgit.errors.MissingBundlePrerequisiteException;
@@ -75,7 +76,7 @@
InputStream bin;
- final Set<ObjectId> prereqs = new HashSet<ObjectId>();
+ final Map<ObjectId, String> prereqs = new HashMap<ObjectId, String>();
private String lockMessage;
@@ -120,7 +121,11 @@ private void readBundleV2() throws IOException {
break;
if (line.charAt(0) == '-') {
- prereqs.add(ObjectId.fromString(line.substring(1, 41)));
+ ObjectId id = ObjectId.fromString(line.substring(1, 41));
+ String shortDesc = null;
+ if (line.length() > 42)
+ shortDesc = line.substring(42);
+ prereqs.put(id, shortDesc);
continue;
}
@@ -199,9 +204,10 @@ private void verifyPrerequisites() throws TransportException {
final RevFlag PREREQ = rw.newFlag("PREREQ");
final RevFlag SEEN = rw.newFlag("SEEN");
- final List<ObjectId> missing = new ArrayList<ObjectId>();
+ final Map<ObjectId, String> missing = new HashMap<ObjectId, String>();
final List<RevObject> commits = new ArrayList<RevObject>();
- for (final ObjectId p : prereqs) {
+ for (final Map.Entry<ObjectId, String> e : prereqs.entrySet()) {
+ ObjectId p = e.getKey();
try {
final RevCommit c = rw.parseCommit(p);
if (!c.has(PREREQ)) {
@@ -209,7 +215,7 @@ private void verifyPrerequisites() throws TransportException {
commits.add(c);
}
} catch (MissingObjectException notFound) {
- missing.add(p);
+ missing.put(p, e.getValue());
} catch (IOException err) {
throw new TransportException(transport.uri, "Cannot read commit "
+ p.name(), err);
@@ -243,7 +249,7 @@ private void verifyPrerequisites() throws TransportException {
if (remaining > 0) {
for (final RevObject o : commits) {
if (!o.has(SEEN))
- missing.add(o);
+ missing.put(o, prereqs.get(o));
}
throw new MissingBundlePrerequisiteException(transport.uri, missing);
}
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v2] send-email: fix mutt regex for grouped aliases
From: Felipe Contreras @ 2009-09-30 14:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong, Jeff King, Felipe Contreras
In-Reply-To: <20090930112833.GA4984@sigio.peff.net>
For example:
alias -group friends foo Foo Bar <foo@bar.com>
Comments by Jeff King.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0700d80..93b7ed2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -401,7 +401,7 @@ my %aliases;
my %parse_alias = (
# multiline formats can be supported in the future
mutt => sub { my $fh = shift; while (<$fh>) {
- if (/^\s*alias\s+(\S+)\s+(.*)$/) {
+ if (/^\s*alias\s+(?:-group\s+\S+\s+)*(\S+)\s+(.*)$/) {
my ($alias, $addr) = ($1, $2);
$addr =~ s/#.*$//; # mutt allows # comments
# commas delimit multiple addresses
--
1.6.5.rc2.1.g9071
^ permalink raw reply related
* Re: [PATCH] send-email: fix mutt regex for grouped aliases
From: Felipe Contreras @ 2009-09-30 14:50 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Eric Wong
In-Reply-To: <20090930112833.GA4984@sigio.peff.net>
On Wed, Sep 30, 2009 at 2:28 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Sep 30, 2009 at 03:08:43AM +0300, Felipe Contreras wrote:
>
>> For example:
>> alias -group friends foo Foo Bar <foo@bar.com>
>
> Hmm. If I am reading the mutt docs correctly, is it also legal to have:
>
> alias -group group1 -group group2 foo Foo Bar <foo@bar.com>
>
> ?
>
> Which would need just:
>
>> - if (/^\s*alias\s+(\S+)\s+(.*)$/) {
>> + if (/^\s*alias\s+(?:-group\s+\S+\s+)?(\S+)\s+(.*)$/) {
>
> (?:-group\s+\S+\s+)*
>
> I think.
Yeap, that is correct. Resent.
--
Felipe Contreras
^ permalink raw reply
* [PATCH 1/2] increase portability of NORETURN declarations
From: Erik Faye-Lund @ 2009-09-30 18:05 UTC (permalink / raw)
To: git; +Cc: msysgit, gitster, Erik Faye-Lund
Some compilers (including at least MSVC) supports NORETURN
on function declarations, but only before the function-name.
This patch makes it possible to define NORETURN to something
meaningful for those compilers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
git-compat-util.h | 8 ++++----
index-pack.c | 4 ++--
usage.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..33dd4f3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -177,13 +177,13 @@ extern char *gitbasename(char *);
#endif
/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern void die_errno(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+extern NORETURN void usage(const char *err);
+extern NORETURN void die(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern NORETURN void die_errno(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
-extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+extern void set_die_routine(NORETURN void (*routine)(const char *err, va_list params));
extern int prefixcmp(const char *str, const char *prefix);
extern time_t tm_to_time_t(const struct tm *tm);
diff --git a/index-pack.c b/index-pack.c
index 340074f..b4f8278 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -206,8 +206,8 @@ static void parse_pack_header(void)
use(sizeof(struct pack_header));
}
-static void bad_object(unsigned long offset, const char *format,
- ...) NORETURN __attribute__((format (printf, 2, 3)));
+static NORETURN void bad_object(unsigned long offset, const char *format,
+ ...) __attribute__((format (printf, 2, 3)));
static void bad_object(unsigned long offset, const char *format, ...)
{
diff --git a/usage.c b/usage.c
index b6aea45..0555ce6 100644
--- a/usage.c
+++ b/usage.c
@@ -36,12 +36,12 @@ static void warn_builtin(const char *warn, va_list params)
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
-static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
-static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static NORETURN void (*usage_routine)(const char *err) = usage_builtin;
+static NORETURN void (*die_routine)(const char *err, va_list params) = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
-void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+void set_die_routine(NORETURN void (*routine)(const char *err, va_list params))
{
die_routine = routine;
}
--
1.6.4.msysgit.0.17.g82372.dirty
^ permalink raw reply related
* [PATCH 2/2] add NORETURN_PTR for function pointers
From: Erik Faye-Lund @ 2009-09-30 18:05 UTC (permalink / raw)
To: git; +Cc: msysgit, gitster, Erik Faye-Lund
In-Reply-To: <1254333950-2440-1-git-send-email-kusmabite@gmail.com>
Some compilers (including at least MSVC and ARM RVDS) supports
NORETURN on function declarations, but not on function pointers.
This patch makes it possible to define NORETURN for these compilers,
by splitting the NORETURN macro into two - one for function
declarations and one for function pointers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
git-compat-util.h | 4 +++-
usage.c | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 33dd4f3..ac7cc66 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -169,8 +169,10 @@ extern char *gitbasename(char *);
#ifdef __GNUC__
#define NORETURN __attribute__((__noreturn__))
+#define NORETURN_PTR __attribute__((__noreturn__))
#else
#define NORETURN
+#define NORETURN_PTR
#ifndef __attribute__
#define __attribute__(x)
#endif
@@ -183,7 +185,7 @@ extern NORETURN void die_errno(const char *err, ...) __attribute__((format (prin
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
-extern void set_die_routine(NORETURN void (*routine)(const char *err, va_list params));
+extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params));
extern int prefixcmp(const char *str, const char *prefix);
extern time_t tm_to_time_t(const struct tm *tm);
diff --git a/usage.c b/usage.c
index 0555ce6..c488f3a 100644
--- a/usage.c
+++ b/usage.c
@@ -36,12 +36,12 @@ static void warn_builtin(const char *warn, va_list params)
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
-static NORETURN void (*usage_routine)(const char *err) = usage_builtin;
-static NORETURN void (*die_routine)(const char *err, va_list params) = die_builtin;
+static NORETURN_PTR void (*usage_routine)(const char *err) = usage_builtin;
+static NORETURN_PTR void (*die_routine)(const char *err, va_list params) = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
-void set_die_routine(NORETURN void (*routine)(const char *err, va_list params))
+void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params))
{
die_routine = routine;
}
--
1.6.4.msysgit.0.17.g82372.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-30 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, Jeff King, git, Johannes Sixt
In-Reply-To: <40aa078e0909250656j4b791a99naf632b5b8d8e1038@mail.gmail.com>
On Fri, Sep 25, 2009 at 3:56 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
>> Anything happened to this series?
>
> No, I'm sorry for not updating. I'm currently on vacation, and I
> didn't get time to fix it up before going, due to my dayjob. I'll pick
> it up again as soon as I get back home, in a bit more than a week.
Alright, I fond time to fix this up a little earlier than I expected.
A new round had been sent to the mailing list.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Compact view of history in gitk
From: Dirk Süsserott @ 2009-09-30 18:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Sixt, Yakup Akbay, git
In-Reply-To: <46a038f90909290821g4bb9cecewace8c8a516b74c78@mail.gmail.com>
Am 29.09.2009 17:21 schrieb Martin Langhoff:
> On Tue, Sep 29, 2009 at 2:07 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I think, --simplify-by-decoration comes close, even though it may not be
>> 100% what you describe.
>
> That is awesome.
>
> Awesomer would be teaching gitk to expand (un-simplify) parts of it.
> Probably a pig of a project to do though :-/
>
>
>
> m
I'm proud to tell that one might also use gitk's
dialog 'View -> Edit view... (F4)' and then activate
the 'Simple history' checkbox. :-)
Gitk knows about that since Git v1.6.4-rc0.
However, it doesn't do the awesomer part.
Dirk
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Heiko Voigt @ 2009-09-30 19:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0909250810270.4985@pacific.mpi-cbg.de>
Hello,
On Fri, Sep 25, 2009 at 08:19:44AM +0200, Johannes Schindelin wrote:
> as some of you already know, I will be unable to Git Together with other
> Gits in California this year. So the only version of such a Git Together
> I will have this year is the Berlin one.
Just announcing that Jens Lehmann and me will also come. Just added
us to the wiki page. What about important stuff like coffee during the
day? Is there access to such things nearby or is it better to bring
everything needed?
cheers Heiko
^ permalink raw reply
* Re: How can I download a git commit as a diff patch?
From: Alejandro Riveira Fernández @ 2009-09-30 19:38 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Randy Dunlap, Andy, linux-kernel, git
In-Reply-To: <20090930190014.GA22161@csclub.uwaterloo.ca>
El Wed, 30 Sep 2009 15:00:14 -0400
CCing git@vger.kernel.org ??
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) escribió:
> On Wed, Sep 30, 2009 at 08:55:00AM -0700, Randy Dunlap wrote:
> > On Wed, 30 Sep 2009 10:44:10 -0500 Andy wrote:
> >
> > > I just want to down a particular git commit as a patch, not a git commit or
> > > anything. Yes, I can see the diffs on the web, but unless I am missing
> > > something all are in unless html formats for me. And cut and past from the
> > > web page does not help either because some lines get mangled. Is there some
> > > site, or git itself, that would allow be to get the git commit as a simple
> > > patch?
> >
> > Look at the commitdiff using the web interface, then click on "raw" near
> > the upper left corner.
>
> Of course some git diff's are not in a format that patch will like as
> far as I can tell.
>
> For example commit 6cdee2f96a97f6da26bd3759c3f8823332fbb438 which has
> stuff like:
> diff --cc drivers/net/ixp2000/ixpdev.c
> index 588b44d,92fb823..1272434
> --- a/drivers/net/ixp2000/ixpdev.c
> +++ b/drivers/net/ixp2000/ixpdev.c
> @@@ -67,9 -68,9 +68,9 @@@ static int ixpdev_xmit(struct sk_buff *
> ip->tx_queue_entries++;
> if (ip->tx_queue_entries == TX_BUF_COUNT_PER_CHAN)
> netif_stop_queue(dev);
> - local_irq_enable();
> + local_irq_restore(flags);
>
> - return 0;
> + return NETDEV_TX_OK;
> }
>
>
>
> Ehm, what does that mean? patch doesn't like it.
>
> Do git merges cause weird diffs?
>
^ permalink raw reply
* Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
From: Mark Struberg @ 2009-09-30 19:51 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Robin Rosenberg, git, spearce, Jason van Zyl
In-Reply-To: <2c6b72b30909280546l62a6ef9cm21112ca071cdef4c@mail.gmail.com>
Hi Jonas!
answers inside
LieGrue,
strub
--- On Mon, 9/28/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Robin Rosenberg" <robin.rosenberg.lists@dewire.com>, git@vger.kernel.org, spearce@spearce.org, "Jason van Zyl" <jvanzyl@sonatype.com>
> Date: Monday, September 28, 2009, 2:46 PM
> On Sat, Sep 26, 2009 at 15:50, Mark
> Struberg <struberg@yahoo.de>
> wrote:
> > Hi Robin!
> >
> > a) Actually git-format-patch only created 0001-0009 so
> there is no 0/9.
>
> For larger patch series, it is good practice (at least on
> git@vger) to
> provide a "cover letter" (see git-format-patch
> --cover-letter) to give
> reviewers of the patch series an idea of what code is
> touched and for
> you to give additional information, such as the state of
> the patch
> series.
txs 4 pointing this out.
>
> > b) 2/9 is the actual directory structure moving. I
> received it, but since it is pretty large (330k already with
> -M -l0) it might got filtered out?
> > If so then may I ask you to please fetch it from http://github.com/sonatype/JGit branch 'mavenize'? It
> has the same content I sent to the list.
>
> Some general notes on the patch series. First, I am glad
> you posted it
> to have something to discuss and as I have stated in a
> private mail I
> am glad you are doing this. However, I also think it needs
> a lot more
> polish before being integrated.
>
> While I understand that you want to credit Jason for doing
> the initial
> probe into fully mavenizing JGit, I now think it is wrong
> to base the
> patch series on his patch. My first impression is that it
> actually
> removes features (by not keeping the JGit specific
> settings), which
> you then try to amend later in the patch series.
I'm not sure what JGit specific settings you speak about?
> In terms of making the patch series more manageable for
> you, I think
> the best approach is to start with the patches not relevant
> to the
> mavenizing (renaming PathSuffixTestCase).
In fact the fix of the PathSuffixTestCase came a few days later after I found the reason why I miss a few tests. This should be fixed in the current master anyway and has not so much todo with the mavenization itself.
> After this comespatches
> which only touch pom.xml files. For example, move
> jgit-maven/jgit/pom.xml to the top-level pom.xml, extract
> relevant
> pieces to org.spearce.jgit/pom.xml and
> org.spearce.jgit.test/pom.xml,
> improving the pom.xml`s by adding checkstyle/<scm>
> integration, and
> mavenizing org.spearce.jgit.pgm/. The final and most
> invasive parts
> (renaming/(re)moving code/eclipse files etc) should come
> last!
I had the following in mind: every single commit should be compileable and working. So it's not easily manageable to move the directory structure in one patch and apply all the changes into the poms in another commit.
We could for sure squash the later few commits, but I didn't liked to rebase and push since there have been a few forks of the mavenize branch and I hoped I could pull back a few commits from others and later do a rebase -i.
> Taking this approach Robin and Spearce can start
> integrating initial
> patces and we can all start testing the "mavenization"
> sooner rather
> than after deciding how to rename things and whether or not
> to remove
> certain files.
>
> The above is a proposal and if you and other agree that it
> is the
> right approach _and_ you do not feel you have the time
> necessary to
> realize it, I am willing to work on it.
Any help is always welcome :)
^ permalink raw reply
* Re: How can I download a git commit as a diff patch?
From: Jakub Narebski @ 2009-09-30 20:10 UTC (permalink / raw)
To: Alejandro Riveira Fernández
Cc: Lennart Sorensen, Randy Dunlap, Andy, linux-kernel, git
In-Reply-To: <20090930213809.71c2a8e8@varda>
Alejandro Riveira Fernández <ariveira@gmail.com> writes:
> El Wed, 30 Sep 2009 15:00:14 -0400
>
> CCing git@vger.kernel.org ??
>
> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) escribió:
>
>> On Wed, Sep 30, 2009 at 08:55:00AM -0700, Randy Dunlap wrote:
>>> On Wed, 30 Sep 2009 10:44:10 -0500 Andy wrote:
>>>
>>>> I just want to down a particular git commit as a patch, not a git commit or
>>>> anything. Yes, I can see the diffs on the web, but unless I am missing
>>>> something all are in unless html formats for me. And cut and past from the
>>>> web page does not help either because some lines get mangled. Is there some
>>>> site, or git itself, that would allow be to get the git commit as a simple
>>>> patch?
>>>
>>> Look at the commitdiff using the web interface, then click on "raw" near
>>> the upper left corner.
Or better yet, if given installation of gitweb supports it, on the
'patch' link just on the right of 'raw' view. Such patch can be
applied better by git-am (but both should work for GNU patch or
git-apply).
>>
>> Of course some git diff's are not in a format that patch will like as
>> far as I can tell.
>>
>> For example commit 6cdee2f96a97f6da26bd3759c3f8823332fbb438 which has
>> stuff like:
>> diff --cc drivers/net/ixp2000/ixpdev.c
>> index 588b44d,92fb823..1272434
>> --- a/drivers/net/ixp2000/ixpdev.c
>> +++ b/drivers/net/ixp2000/ixpdev.c
>> @@@ -67,9 -68,9 +68,9 @@@ static int ixpdev_xmit(struct sk_buff *
>> ip->tx_queue_entries++;
>> if (ip->tx_queue_entries == TX_BUF_COUNT_PER_CHAN)
>> netif_stop_queue(dev);
>> - local_irq_enable();
>> + local_irq_restore(flags);
>>
>> - return 0;
>> + return NETDEV_TX_OK;
>> }
>>
>>
>>
>> Ehm, what does that mean? patch doesn't like it.
>>
>> Do git merges cause weird diffs?
Yes, by default for merges the 'commitdiff' view (and the 'raw'
version, i.e. 'commitdiff_plain' view) shows **combined** diff of
changes brought by merge (see git-diff manpage for details on this
format).
For merge commit you have to choose which of parents you want to have
diff from. Go to 'commit' view, there in the header would be two or
more parents. Click on the 'diff' link beside chosen parent, check if
it is the diff you want to get, and then click on 'patch' (or 'raw')
link.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Do not show 'patch' link in 'commit' view for merges
From: Jakub Narebski @ 2009-09-30 20:21 UTC (permalink / raw)
To: git
Show 'patch' link in the 'commit' view only for commits which have
exactly one parent, otherwise call to git-format-patch would fail for
the hyperlinked 'patch' action.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Just noticed this issue, thanks indirectly to
"Re: How can I download a git commit as a diff patch?"
thread.
This is conservative change: perhaps we could extend 'patch' view to
work also for root commit...
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..fb045a1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5328,7 +5328,7 @@ sub git_commit {
} @$parents ) .
')';
}
- if (gitweb_check_feature('patches')) {
+ if (gitweb_check_feature('patches') && @$parents == 1) {
$formats_nav .= " | " .
$cgi->a({-href => href(action=>"patch", -replay=>1)},
"patch");
^ permalink raw reply related
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