* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-16 6:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20071015231242.GR27899@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
>> have to fall back to git-fetch on the command line.
>>
>> [*] Note the distinction between "not available" and "does not work".
>
> What's broken? Is this that Git protocol dump showing up in
> git-gui's console window thing?
>
> Are you using the C based fetch that is in git.git's next branch,
> or the shell script based one that is in master? Which Tcl/Tk
> version are you using to run git-gui?
It's the scripted fetch that does not work. The symptom is that the output
of at least one of the commands (upload-pack, I think, because what I see is
wire protocol) goes to a newly spawned console instead of wherever it was
redirected to.
I didn't bother reporting since builtin-fetch is on the way (which will
hopefully make this a moot point) and our team here is comfortable with
calling git fetch on the command line.
-- Hannes
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-16 6:17 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Git Mailing List, Alex Riesen, Eli Zaretskii, Andreas Ericsson,
tsuna, Johannes Schindelin
In-Reply-To: <fcaeb9bf0710151924r258dd561hd13c22319d17f80f@mail.gmail.com>
On Oct 16, 2007, at 4:24 AM, Nguyen Thai Ngoc Duy wrote:
> On 10/16/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:
>>> There is a port of BusyBox' dash, which is nearing completion. Once
>>> Nguyen says it is ready enough, we will try to integrate it into
>>> msysGit.
>>
>> Gnuarch [1] recommends zsh from the unxutils project [2].
>
> All zsh links in [2] are dead. I did try hard to find the legendary
> zsh for Windows before giving up and porting busybox's ash instead. If
> you have zsh source of the port, please send me. Thank you.
It is included in UnxUtilsSrc.zip, updated on 2007-03-01 06:22, from
http://sourceforge.net/projects/unxutils
http://sourceforge.net/project/showfiles.php?group_id=9328
Steffen
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-16 6:17 UTC (permalink / raw)
To: David Symonds
Cc: Geert Bosch, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <ee77f5c20710152307n48431a6eu5dc95ee504968e4e@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> On 16/10/2007, David Kastrup <dak@gnu.org> wrote:
>> Geert Bosch <bosch@adacore.com> writes:
>>
>> > On Oct 15, 2007, at 13:53, David Symonds wrote:
>> >> That's also why I suggested "skip"; you might not be able to test a
>> >> particular commit, but you might also not *want* to test a particular
>> >> commit for some reason.
>> >
>> > Skip seems a great choice: it directly expresses the wish to
>> > not consider a certain commit. The reason is unimportant.
>>
>> But it is an _action_, while "good" and "bad" are properties.
>
> "skipped", then.
"good" and "bad" are descriptive. "to be skipped" would be necessary
to fit it.
> Either way, something like this has got to be much better than
> "dunno".
"undecided" still has my vote, and I could live with "unknown".
Everything that has been proposed since then is, in my opinion,
strictly worse.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
From: Christian Couder @ 2007-10-16 6:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710151338000.25221@racer.site>
Hi Dscho,
Le lundi 15 octobre 2007, Johannes Schindelin a écrit :
> Hi,
>
> On Mon, 15 Oct 2007, Christian Couder wrote:
> >
> > But the new "bisect_state" takes one more argument, because the first
> > one must be "good" "bad" or "dunno".
> >
> > So when there is only one argument HEAD is used, and when there are 2
> > arguments, $2 is used as the good|bad|dunno rev.
>
> Ah, that explains it! But do you not need to do "2,bad|2,good|2,dunno"
> in that case? Or even better: "2,*"?
Perhaps it would be an improvement at least in speed for "2,good"
or "2,dunno".
I wanted to keep exactly the same processing as there was before, in case
something like "git bisect good v1.5.3.3..v1.5.3.4" was supported. But it
seems it doesn't work. I don't know if it's a bug or a feature.
Christian.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Shawn O. Pearce @ 2007-10-16 6:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git list
In-Reply-To: <471455ED.8070408@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> >Johannes Sixt <j.sixt@viscovery.net> wrote:
> >>Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
> >>have to fall back to git-fetch on the command line.
>
> It's the scripted fetch that does not work. The symptom is that the output
> of at least one of the commands (upload-pack, I think, because what I see
> is wire protocol) goes to a newly spawned console instead of wherever it
> was redirected to.
>
> I didn't bother reporting since builtin-fetch is on the way (which will
> hopefully make this a moot point) and our team here is comfortable with
> calling git fetch on the command line.
Hmm. The way the builtin-fetch works this shouldn't happen, but
I'd appreciate it if you could test and report back before that
topic merges into master.
--
Shawn.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 6:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: barkalow, raa.lkml, Johannes.Schindelin, tsuna, git, make-w32
In-Reply-To: <471448D0.6080200@op5.se>
> Date: Tue, 16 Oct 2007 07:14:56 +0200
> From: Andreas Ericsson <ae@op5.se>
> CC: Daniel Barkalow <barkalow@iabervon.org>, raa.lkml@gmail.com,
> Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org,
> make-w32@gnu.org
>
> > Sorry I'm asking potentially stupid questions out of ignorance: why
> > would you want readdir to return `README' when you have `readme'?
> >
>
> Because it might have been checked in as README, and since git is case
> sensitive that is what it'll think should be there when it reads the
> directories. If it's not, users get to see
>
> removed: README
> untracked: readme
This is a non-issue, then: Windows filesystems are case-preserving, so
if `README' became `readme', someone deliberately renamed it, in which
case it's okay for git to react as above.
> could be an intentional rename, but we don't know for sure.
It _must_ have been an intentional rename. While years ago there used
to be old DOS programs that could cause such a rename as a side effect
of modifying a file, that time is long gone. There's no longer a need
to cater to such programs, as even DOS programs can support
case-preserving APIs on Windows.
> To be honest though, there are so many places which do the readdir+stat
> that I don't think it'd be worth factoring it out
Something for Windows users to decide, I guess. It's not hard to
refactor this, it just needs a motivated volunteer.
> especially since it
> *works* on windows. It's just slow, and only slow compared to various
> unices.
I think only the Linux filesystem is as fast as you say. But I may be
wrong (did someone compare with *BSD, say?).
> I *think* (correct me if I'm wrong) that git is still faster
> than a whole bunch of other scm's on windows, but to one who's used to
> its performance on Linux that waiting several seconds to scan 10k files
> just feels wrong.
Unless that 10K is a typo and you really meant 100K, I don't think 10K
files should take several seconds to scan on Windows. I just tried
"find -print" on a directory with 32K files in 4K subdirectories, and
it took 8 sec elapsed with a hot cache. So 10K files should take at
most 2 seconds, even without optimizing file traversal code. Doing
the same with native Windows system calls ("dir /s") brings that down
to 4 seconds for 32K files.
On the other hand, what packages have 100K files? If there's only one
-- the Linux kernel -- then I think this kind of performance is for
all practical purposes unimportant on Windows, because while it is
reasonable to assume that someone would like to use git on Windows,
assuming that someone will develop the Linux kernel on Windows is --
how should I put it -- _really_ far-fetched ;-)
As for speed of file ops ``just feeling wrong'': it's not limited to
git in any way. You will see the same with "tar -x", with "find" and
even with "cp -r", when you compare Linux filesystems, especially on a
fast 64-bit machine, with comparable Windows operations. A Windows
user who occasionally works on GNU/Linux already knows that, so seeing
the same in git will not come as a surprise. Again, I wonder how this
compares with other free OSes, like FreeBSD (unless they use the same
filesystem), and with proprietary Unices, like AIX and Solaris.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-16 6:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20071016062144.GD13801@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Johannes Sixt <j.sixt@viscovery.net> wrote:
>>>> Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
>>>> have to fall back to git-fetch on the command line.
>> It's the scripted fetch that does not work. The symptom is that the output
^^^^^^^^^^^^^^
>> of at least one of the commands (upload-pack, I think, because what I see
>> is wire protocol) goes to a newly spawned console instead of wherever it
>> was redirected to.
>>
>> I didn't bother reporting since builtin-fetch is on the way (which will
>> hopefully make this a moot point) and our team here is comfortable with
>> calling git fetch on the command line.
>
> Hmm. The way the builtin-fetch works this shouldn't happen, but
> I'd appreciate it if you could test and report back before that
> topic merges into master.
This happens with git 1.5.3 plus the git-gui that comes with that.
FWIW, I'm in the process of merging master of git.git into git/mingw.git,
and then the builtin-fetch series (because on top of that there is my
fork/exec removal series, which I'd like to adjust for Windows). And *then*
I'll be able to report back to you.
-- Hannes
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-16 6:42 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Daniel Barkalow, raa.lkml, Johannes.Schindelin, ae,
Benoit SIGOURE, git@vger.kernel.org >> Git Mailing List,
Make Windows
In-Reply-To: <uodezisvg.fsf@gnu.org>
Eli Zaretskii schrieb:
> If that's the issue, then it's not a good idea to call `stat' and
> `readdir' on Windows at all. `stat' is a single system call on Posix
> systems, while on Windows it usually needs to go out of its way
> calling half a dozen system services to gather the `struct stat' info.
Thanks to Marius Storm-Olsen we already have a stat replacement that's twice
as fast as msvcrt's stat. I calls only one API function
(GetFileAttributesEx, but of course I don't know what's going on under its
hood), because we need only a small part of struct stat filled in correctly.
-- Hannes
^ permalink raw reply
* On Tabs and Spaces
From: Michael Witten @ 2007-10-16 6:45 UTC (permalink / raw)
To: git
What are the rules about tabs and spaces in source code?
I'm having a terrible time with formatting,
especially in the perl scripts; there is a
mix of spaces and tabs.
from what I can deduce, single tabs are used
to introduce the equivalent of 8 spaces while
4 explicit spaces are used for half a tab.
I would recommend using all spaces, but the C
code seems to prefer all tabs.
In any case, some kind of standards need to be
set, because no one is following anything curr-
ently.
Sincerely,
Michael Witten
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 7:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: raa.lkml, Johannes.Schindelin, ae, tsuna, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710160032020.7638@iabervon.org>
> Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> From: Daniel Barkalow <barkalow@iabervon.org>
> cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se,
> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
>
> Ah, that's helpful. We don't actually care too much about the particular
> info in stat; we just want to know quickly if the file has changed, so we
> can hash only the ones that have been touched and get the actual content
> changes.
As I wrote in my other message, using native APIs improves performance
by at least a factor of two.
> The tricky thing is that, while the optimization
> process is running, other programs may be reading the database, so (1) the
> files that are no longer needed, because better-optimized versions are in
> place, may be open in another task
Is this because another user might be accessing the database, or are
there other popular use cases that cause this? If the former, then
this is not terribly important on Windows, since the situation when
more than one user is logged and actively works is quite rare,
basically limited to some scheduled task (the equivalent of a cron
job) running for some user while another one is logged in
interactively.
This might be different on machines that use Cygwin, though.
> Now, it's entirely possible that a completely different database
> implementation would be better on Windows, but our current one does a lot
> of creating files under different names, moving them to names where
> they'll be seen (since this is atomic under POSIX, and partial files are
> never seen by other tasks). Also, once we have new files in place, we
> unlink the files that they replace, so that new tasks will use the new
> ones and tasks that already have old ones open can still get the data out
> of them. Also, the files generally get mmaped,
Perhaps mmap introduces complications (I simply don't know), but in
general, as I show elsewhere in this thread, you can do similar things
on Windows, if you use native APIs (as opposed to emulations of Posix,
like `open'), although you may need to rename the old file to get it
out of the way of the new one with the same name, because otherwise
the old file will still be seen, even if deleted, as long as it's open
in some process.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Shawn O. Pearce @ 2007-10-16 7:04 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu>
Michael Witten <mfwitten@MIT.EDU> wrote:
> What are the rules about tabs and spaces in source code?
>
> I'm having a terrible time with formatting,
> especially in the perl scripts; there is a
> mix of spaces and tabs.
>
> from what I can deduce, single tabs are used
> to introduce the equivalent of 8 spaces while
> 4 explicit spaces are used for half a tab.
The C code is all tabs, with the tabs set at 8 spaces, but the
actual tab width isn't too important here as we never use the tab
for alignment beyond the left indent.
The bulk of the Perl/shell is also done that way, but you may
run into a place where it isn't. In which case try to match the
existing identation within that block as best as you can so the diff
is minimal and the resulting file still indents just as good/bad
as it did before.
You may also consider submitting a whitespace correction patch in
front of your actual code change to correct the offending part of
the file, but every line you touch is that much more work for your
peers to review and test. In short changing code is bad unless
there is a really compelling reason...
--
Shawn.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Daniel Barkalow @ 2007-10-16 7:07 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Andreas Ericsson, raa.lkml, Johannes.Schindelin, tsuna, git,
make-w32
In-Reply-To: <E1Ihfrl-0007w1-3I@fencepost.gnu.org>
On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Tue, 16 Oct 2007 07:14:56 +0200
> > From: Andreas Ericsson <ae@op5.se>
> > CC: Daniel Barkalow <barkalow@iabervon.org>, raa.lkml@gmail.com,
> > Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org,
> > make-w32@gnu.org
> >
> > > Sorry I'm asking potentially stupid questions out of ignorance: why
> > > would you want readdir to return `README' when you have `readme'?
> > >
> >
> > Because it might have been checked in as README, and since git is case
> > sensitive that is what it'll think should be there when it reads the
> > directories. If it's not, users get to see
> >
> > removed: README
> > untracked: readme
>
> This is a non-issue, then: Windows filesystems are case-preserving, so
> if `README' became `readme', someone deliberately renamed it, in which
> case it's okay for git to react as above.
>
> > could be an intentional rename, but we don't know for sure.
>
> It _must_ have been an intentional rename. While years ago there used
> to be old DOS programs that could cause such a rename as a side effect
> of modifying a file, that time is long gone. There's no longer a need
> to cater to such programs, as even DOS programs can support
> case-preserving APIs on Windows.
I'm partially worried about cases where checking out a "README" fails to
replace the name of an existing "readme", or something of that sort.
> > To be honest though, there are so many places which do the readdir+stat
> > that I don't think it'd be worth factoring it out
>
> Something for Windows users to decide, I guess. It's not hard to
> refactor this, it just needs a motivated volunteer.
>
> > especially since it
> > *works* on windows. It's just slow, and only slow compared to various
> > unices.
>
> I think only the Linux filesystem is as fast as you say. But I may be
> wrong (did someone compare with *BSD, say?).
I think you're right (nothing else can compete with Linux for doing half a
million trivial syscalls), but other unixes aren't terrible, either.
IIRC, on OS X, we had problems when we were doing 4 times as many syscalls
as necessary, but was fine with that fixed.
> > I *think* (correct me if I'm wrong) that git is still faster
> > than a whole bunch of other scm's on windows, but to one who's used to
> > its performance on Linux that waiting several seconds to scan 10k files
> > just feels wrong.
>
> Unless that 10K is a typo and you really meant 100K, I don't think 10K
> files should take several seconds to scan on Windows. I just tried
> "find -print" on a directory with 32K files in 4K subdirectories, and
> it took 8 sec elapsed with a hot cache. So 10K files should take at
> most 2 seconds, even without optimizing file traversal code. Doing
> the same with native Windows system calls ("dir /s") brings that down
> to 4 seconds for 32K files.
>
> On the other hand, what packages have 100K files? If there's only one
> -- the Linux kernel -- then I think this kind of performance is for
> all practical purposes unimportant on Windows, because while it is
> reasonable to assume that someone would like to use git on Windows,
> assuming that someone will develop the Linux kernel on Windows is --
> how should I put it -- _really_ far-fetched ;-)
Actually, there are a number of projects much bigger than the Linux
kernel; I think KDE was considering using git, and wanted Windows support,
and KDE is insanely huge, mostly as a result of having one big repository
for everything.
> As for speed of file ops ``just feeling wrong'': it's not limited to
> git in any way. You will see the same with "tar -x", with "find" and
> even with "cp -r", when you compare Linux filesystems, especially on a
> fast 64-bit machine, with comparable Windows operations. A Windows
> user who occasionally works on GNU/Linux already knows that, so seeing
> the same in git will not come as a surprise. Again, I wonder how this
> compares with other free OSes, like FreeBSD (unless they use the same
> filesystem), and with proprietary Unices, like AIX and Solaris.
For most things, Unix filesystems are fast enough that the bulk of the
time is spent elsewhere. "git status" without any changes and a hot cache
is unusual in being both a common operation and entirely trivial syscalls
if the filesystem makes it efficient.
The problem we've had is that Linux users who occasionally work on Windows
say git seems impossibly slow on Windows.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-16 7:14 UTC (permalink / raw)
To: Git Mailing List
Cc: Eli Zaretskii, Daniel Barkalow, Alex Riesen, Johannes Schindelin,
tsuna, make-w32, Andreas Ericsson
In-Reply-To: <471448D0.6080200@op5.se>
On Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:
> Eli Zaretskii wrote:
>>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
>>> From: Daniel Barkalow <barkalow@iabervon.org>
>>> cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de,
>>> ae@op5.se, tsuna@lrde.epita.fr, git@vger.kernel.org, make-
>>> w32@gnu.org
>>>
>>> I believe the hassle is that readdir doesn't necessarily report a
>>> README in a directory which is supposed to have a README, when it
>>> has a readme instead.
>> Sorry I'm asking potentially stupid questions out of ignorance: why
>> would you want readdir to return `README' when you have `readme'?
>
> Because it might have been checked in as README, and since git is case
> sensitive that is what it'll think should be there when it reads the
> directories. If it's not, users get to see
>
> removed: README
> untracked: readme
>
> and there's really no easy way out of this one, since users on a case-
> sensitive filesystem might be involved in this project too, so it
> could be an intentional rename, but we don't know for sure. Just
> clobbering the in-git file is wrong, but overwriting a file on disk
> is wrong too. git tries hard to not ever lose any data for the user.
Maybe we need a configuration similar to core.autocrlf (which controls
newline conversion) to control filename comparison and normalization?
Most obviously for the case (in-)sensitivity on Windows, but I also
remember the unicode normalization happening on Mac's HFS filesystem
that caused trouble in the past.
Steffen
^ permalink raw reply
* Re: git-fast-import crashes
From: Shun Kei Leung @ 2007-10-16 7:13 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Shawn O. Pearce
In-Reply-To: <e66701d40710150119y7c9e0ff6n83c5fbd25d351fc6@mail.gmail.com>
Hi Pierre,
I have tested with your patch applied, and it still crashed badly.
I compiled the b449f4c version and I got a different backtrace from
GDB. I am still not sure about how the error occurs. I attached the
memory usage from various command line tools.
Regards,
Kevin Leung
GDB output
===========
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x756c7463
0x90018d0c in szone_realloc ()
(gdb) bt
#0 0x90018d0c in szone_realloc ()
#1 0x90018898 in realloc ()
#2 0x0001f8c8 in strbuf_grow (sb=0x75ef8, extra=0) at git-compat-util.h:223
#3 0x0001fc14 in read_line (sb=0x75ef8, fp=0xa0001b9c, term=10) at strbuf.c:107
#4 0x00002da8 in read_next_command () at fast-import.c:1599
#5 0x0000742c in cmd_new_commit () at fast-import.c:2118
#6 0x00007e80 in main (argc=1, argv=0xbffff828) at fast-import.c:2390
(gdb) frame 3
#3 0x0001fc14 in read_line (sb=0x75ef8, fp=0xa0001b9c, term=10) at strbuf.c:107
107 strbuf_grow(sb, 1);
(gdb) print *sb
$1 = {
alloc = 60,
len = 23,
eof = 0,
buf = 0x5020b0 "D windows/packages/cdc/ces/adm"
}
(gdb) frame 2
#2 0x0001f8c8 in strbuf_grow (sb=0x75ef8, extra=0) at git-compat-util.h:223
223 void *ret = realloc(ptr, size);
(gdb) print (char *) ptr
$2 = 0x5020b0 "D windows/packages/cdc/ces/adm"
(gdb) print (char *)ret
$3 = 0xd <Address 0xd out of bounds>
(gdb)
The output of `leaks'
=================
Process 27075: 88 nodes malloced for 2335 KB
Process 27075: 6 leaks for 624 total leaked bytes.
Leak: 0x005012b0 size=208 string 'EOT'
Leak: 0x00501e60 size=128 string 'EOT'
Leak: 0x00501c80 size=128 string 'EOT'
Leak: 0x00500f10 size=64 string 'EOT'
Leak: 0x00501fa0 size=64 string 'EOT'
Leak: 0x00501f60 size=32
0x00000000 0x02008000 0x00000000 0x01000000 ................
0x02000000 0x0000001a 0x00000000 0x00000000 ................
Below is the output of `malloc_history'
==============================
Deallocation of 5020b0 - no corresponding allocation
67 calls for 2874 bytes: thread_a000ed88 |0x0 | start | _start | main
| cmd_new_commit | read_next_command | read_line | strbuf_grow
12 calls for 2016 bytes: thread_a000ed88 |0x0 | start | _start | main
| prepare_packed_git | prepare_packed_git_one | add_packed_git
8 calls for 831 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | cmd_data | read_line | strbuf_grow
4 calls for 160 bytes: thread_a000ed88 |0x0 | start | _start |
__keymgr_dwarf2_register_sections | _dyld_register_func_for_add_image
| dyld::registerAddCallback(void (*)(mach_header const*, long)) |
ImageLoader::runNotification(ImageLoader::LinkContext const&,
unsigned) | ImageLoader::recursiveImageNotification(ImageLoader::LinkContext
const&, unsigned) | dyld::imageNotification(ImageLoader*, unsigned) |
dwarf2_unwind_dyld_add_image_hook
3 calls for 1976 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set | load_tree |
read_sha1_file | read_packed_sha1 | unpack_entry | unpack_entry |
patch_delta
3 calls for 84 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set | load_tree |
read_sha1_file | read_packed_sha1 | unpack_entry |
unpack_object_header | use_pack
2 calls for 1200 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | patch_delta
2 calls for 1200 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
patch_delta
2 calls for 1200 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | patch_delta
2 calls for 80 bytes: thread_a000ed88 |0x0 | start | _start |
__keymgr_dwarf2_register_sections | _dyld_register_func_for_add_image
| dyld::registerAddCallback(void (*)(mach_header const*, long)) |
ImageLoader::runNotification(ImageLoader::LinkContext const&,
unsigned) | ImageLoader::recursiveImageNotification(ImageLoader::LinkContext
const&, unsigned) | dyld::imageNotification(ImageLoader*, unsigned) |
dwarf2_unwind_dyld_add_image_hook
2 calls for 56 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_object_header | use_pack
1 calls for 2097152 bytes: thread_a000ed88 |0x0 | start | _start |
main | pool_calloc | pool_alloc
1 calls for 160012 bytes: thread_a000ed88 |0x0 | start | _start | main
| alloc_objects
1 calls for 52000 bytes: thread_a000ed88 |0x0 | start | _start | main
| cmd_new_commit | load_tree | new_tree_entry
1 calls for 17804 bytes: thread_a000ed88 |0x0 | start | _start | main
1 calls for 8192 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | cmd_data
1 calls for 4156 bytes: thread_a000ed88 |0x0 | start | _start | main
1 calls for 4096 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | store_tree | store_tree | store_tree | mktree |
size_dbuf
1 calls for 4096 bytes: thread_a000ed88 |0x0 | start | _start | main |
read_next_command | read_line | fgetc | __srget | __srefill |
__smakebuf
1 calls for 3072 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | store_tree | store_tree | store_tree | mktree |
size_dbuf
1 calls for 2048 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | size_dbuf
1 calls for 1149 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set | load_tree |
read_sha1_file | read_packed_sha1 | unpack_entry | unpack_entry |
unpack_entry | patch_delta
1 calls for 1149 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set | load_tree |
read_sha1_file | read_packed_sha1 | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_compressed_entry
1 calls for 1032 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | unpack_compressed_entry
1 calls for 822 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set |
tree_content_set | load_tree | read_sha1_file | read_packed_sha1 |
unpack_entry | unpack_entry | unpack_compressed_entry
1 calls for 522 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry |
unpack_compressed_entry
1 calls for 436 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set |
tree_content_set | tree_content_set | tree_content_set |
tree_content_set | load_tree | read_sha1_file | read_packed_sha1 |
unpack_entry | unpack_entry | unpack_compressed_entry
1 calls for 400 bytes: thread_a000ed88 |0x0 | start | _start | main
1 calls for 285 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set |
tree_content_set | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry |
unpack_compressed_entry
1 calls for 258 bytes: thread_a000ed88 |0x0 | start | _start | main |
start_packfile | mkstemp | arc4random
1 calls for 212 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set |
tree_content_set | tree_content_set | tree_content_set | load_tree |
read_sha1_file | read_packed_sha1 | unpack_entry | unpack_entry |
unpack_compressed_entry
1 calls for 168 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | patch_delta
1 calls for 168 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | patch_delta
1 calls for 168 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | patch_delta
1 calls for 168 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | unpack_compressed_entry
1 calls for 168 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | load_tree | read_sha1_file |
read_packed_sha1 | unpack_entry | unpack_entry | unpack_entry |
unpack_entry | unpack_entry | unpack_entry | unpack_entry |
patch_delta
1 calls for 129 bytes: thread_a000ed88 |0x0 | start | _start | main |
start_packfile
1 calls for 122 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set | load_tree |
read_sha1_file | read_packed_sha1 | unpack_entry | unpack_entry |
unpack_compressed_entry
1 calls for 64 bytes: thread_a000ed88 |0x0 | start | _start | main |
git_config | git_path | get_git_dir | setup_git_env | sprintf$LDBL128
| __vfprintf$LDBL128 | localeconv_l
1 calls for 61 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | parse_ident
1 calls for 60 bytes: thread_a000ed88 |0x0 | start | _start |
__keymgr_dwarf2_register_sections | _dyld_register_func_for_add_image
| dyld::registerAddCallback(void (*)(mach_header const*, long)) |
ImageLoader::runNotification(ImageLoader::LinkContext const&,
unsigned) | dyld::imageNotification(ImageLoader*, unsigned) |
dwarf2_unwind_dyld_add_image_hook |
_keymgr_get_and_lock_processwide_ptr_2 | get_or_create_key_element
1 calls for 52 bytes: thread_a000ed88 |0x0 | start | _start | main |
git_config | git_path | get_git_dir | setup_git_env | strdup
1 calls for 48 bytes: thread_a000ed88 |0x0 | start | _start | main |
git_config | git_path | get_git_dir | setup_git_env
1 calls for 46 bytes: thread_a000ed88 |0x0 | start | _start | main |
git_config | git_path | get_git_dir | setup_git_env
1 calls for 45 bytes: thread_a000ed88 |0x0 | start | _start | main |
git_config | git_path | get_git_dir | setup_git_env
1 calls for 40 bytes: thread_a000ed88 |0x0 | start | _start |
__keymgr_dwarf2_register_sections | _dyld_register_func_for_add_image
| dyld::registerAddCallback(void (*)(mach_header const*, long)) |
ImageLoader::runNotification(ImageLoader::LinkContext const&,
unsigned) | dyld::imageNotification(ImageLoader*, unsigned) |
dwarf2_unwind_dyld_add_image_hook
1 calls for 40 bytes: thread_a000ed88 |0x0 | start | _start |
__keymgr_dwarf2_register_sections | _dyld_register_func_for_add_image
| dyld::registerAddCallback(void (*)(mach_header const*, long)) |
ImageLoader::runNotification(ImageLoader::LinkContext const&,
unsigned) | ImageLoader::recursiveImageNotification(ImageLoader::LinkContext
const&, unsigned) | dyld::imageNotification(ImageLoader*, unsigned) |
dwarf2_unwind_dyld_add_image_hook
1 calls for 28 bytes: thread_a000ed88 |0x0 | start | _start | main |
cmd_new_commit | tree_content_set | tree_content_set |
tree_content_set | tree_content_set | tree_content_set |
tree_content_set | load_tree | read_sha1_file | read_packed_sha1 |
unpack_entry | unpack_object_header | use_pack
1 calls for 18 bytes: thread_a000ed88 |0x0 | start | _start |
__keymgr_dwarf2_register_sections | _dyld_register_func_for_add_image
| dyld::registerAddCallback(void (*)(mach_header const*, long)) |
ImageLoader::runNotification(ImageLoader::LinkContext const&,
unsigned) | dyld::imageNotification(ImageLoader*, unsigned) |
dwarf2_unwind_dyld_add_image_hook | calloc
1 calls for 4 bytes: thread_a000ed88 |0x0 | start | _start | main |
start_packfile
Output of `vmmap'
===============
Virtual Memory Map of process 27270 (git-fast-import)
Output report format: 2.0
==== Non-writable regions for process 27270
__PAGEZERO 00000000-00001000 [ 4K] ---/--- SM=NUL
/Users/developer/bin/git-fast-import
__TEXT 00001000-00034000 [ 204K] r-x/rwx SM=COW
/Users/developer/bin/git-fast-import
__LINKEDIT 00080000-000f3000 [ 460K] r--/rwx SM=COW
/Users/developer/bin/git-fast-import
mapped file 000f7000-000f8000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-b7cda23e237f38b466d2f7b54f665a7d0c8a32ed.idx
mapped file 000f8000-000f9000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-5f301a4b08a7f7d44b288f2a96d33f3c3efbf7fb.idx
mapped file 000f9000-000fa000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-ee6298d97a1154422169e66d6655071a49cb8686.idx
__TEXT 00205000-00216000 [ 68K] r-x/rwx SM=COW
/opt/local/lib/libz.1.dylib
__LINKEDIT 00217000-00219000 [ 8K] r--/rwx SM=COW
/opt/local/lib/libz.1.dylib
__TEXT 00219000-00313000 [ 1000K] r-x/rwx SM=COW
/opt/local/lib/libiconv.2.dylib
__LINKEDIT 00314000-0031e000 [ 40K] r--/rwx SM=COW
/opt/local/lib/libiconv.2.dylib
__TEXT 0031e000-00421000 [ 1036K] r-x/rwx SM=COW
/opt/local/lib/libcrypto.0.9.8.dylib
__LINKEDIT 00438000-0048d000 [ 340K] r--/rwx SM=COW
/opt/local/lib/libcrypto.0.9.8.dylib
__TEXT 0048d000-004c8000 [ 236K] r-x/rwx SM=COW
/opt/local/lib/libssl.0.9.8.dylib
__LINKEDIT 004cc000-004dd000 [ 68K] r--/rwx SM=COW
/opt/local/lib/libssl.0.9.8.dylib
mapped file 004dd000-004df000 [ 8K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-5f301a4b08a7f7d44b288f2a96d33f3c3efbf7fb.pack
mapped file 004ec000-004ed000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-ea2fe30b68a19c9cd6a4bf1dd345377b4dd77df0.idx
mapped file 004ed000-004ee000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-97e365a44e20cb37576362c81afdaa879a871a10.idx
mapped file 004ee000-004ef000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-f1bcc0635a35caff73d8ccac60ec6656f0527a10.idx
mapped file 004ef000-004f0000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-f1bcc0635a35caff73d8ccac60ec6656f0527a10.pack
mapped file 004f0000-004f1000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-60dd3fcceddf3eacbe2279ef191f87668b97fb57.idx
mapped file 004f1000-004f2000 [ 4K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-8a733b7ccad3eb85b4286a011eccdff20441d9e4.idx
mapped file 004f2000-004f7000 [ 20K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-8acbc2151777eb8a2093e5229897d5711dab175b.idx
mapped file 004f7000-004fa000 [ 12K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-3d264397b577400c2277f1b89f2065e0cc9846e3.idx
mapped file 004fa000-004fc000 [ 8K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-010e1c06a07ef38c31f8e01782eeda433b007709.idx
mapped file 004fc000-00500000 [ 16K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-ea2fe30b68a19c9cd6a4bf1dd345377b4dd77df0.pack
mapped file 006ad000-006e4000 [ 220K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-3294c669f264ef7a21e2280bfd934e7459140022.idx
mapped file 01208000-01363000 [ 1388K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-8acbc2151777eb8a2093e5229897d5711dab175b.pack
mapped file 01363000-0146c000 [ 1060K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-010e1c06a07ef38c31f8e01782eeda433b007709.pack
mapped file 02008000-052fe000 [52184K] r--/rwx SM=COW
/Volumes/data/kevin/test_gitp4/cdc/.git/objects/pack/pack-3294c669f264ef7a21e2280bfd934e7459140022.pack
__TEXT 8fe00000-8fe01000 [ 4K] r-x/rwx SM=COW /usr/lib/dyld
__TEXT 8fe01000-8fe02000 [ 4K] r-x/rwx SM=COW /usr/lib/dyld
__TEXT 8fe02000-8fe53000 [ 324K] r-x/rwx SM=COW /usr/lib/dyld
__LINKEDIT 8fe5d000-8fe71000 [ 80K] r--/rwx SM=COW /usr/lib/dyld
__TEXT 90000000-901bd000 [ 1780K] r-x/r-x SM=COW
/usr/lib/libSystem.B.dylib
__LINKEDIT 901bd000-90214000 [ 348K] r--/r-- SM=COW
/usr/lib/libSystem.B.dylib
__TEXT 90214000-9021a000 [ 24K] r-x/r-x SM=COW
/usr/lib/system/libmathCommon.A.dylib
__LINKEDIT 9021a000-9021b000 [ 4K] r--/r-- SM=COW
/usr/lib/system/libmathCommon.A.dylib
__TEXT 91433000-9143f000 [ 48K] r-x/r-x SM=COW
/usr/lib/libgcc_s.1.dylib
__LINKEDIT 9143f000-91443000 [ 16K] r--/r-- SM=COW
/usr/lib/libgcc_s.1.dylib
__DATA a0214000-a0215000 [ 4K] r--/r-- SM=COW
/usr/lib/system/libmathCommon.A.dylib
STACK GUARD fffec000-ffff0000 [ 16K] ---/rwx SM=NUL
system ffff8000-ffffa000 [ 8K] r--/r-- SM=SHM
commpage [libSystem.B.dylib]
==== Writable regions for process 27270
__DATA 00034000-00035000 [ 4K] rw-/rwx SM=COW
/Users/developer/bin/git-fast-import
__DATA 00035000-00080000 [ 300K] rw-/rwx SM=PRV
/Users/developer/bin/git-fast-import
VM_ALLOCATE ? 000fa000-000fb000 [ 4K] rw-/rwx SM=NUL
MALLOC_LARGE 000fb000-00100000 [ 20K] rw-/rwx SM=PRV
DefaultMallocZone_0x500000
MALLOC_TINY (freed?) 00100000-00102000 [ 8K] rw-/rwx SM=COW
MALLOC_TINY (freed?) 00102000-00205000 [ 1036K] rw-/rwx SM=ZER
__DATA 00216000-00217000 [ 4K] rw-/rwx SM=COW
/opt/local/lib/libz.1.dylib
__DATA 00313000-00314000 [ 4K] rw-/rwx SM=COW
/opt/local/lib/libiconv.2.dylib
__DATA 00421000-00435000 [ 80K] rw-/rwx SM=COW
/opt/local/lib/libcrypto.0.9.8.dylib
__DATA 00435000-00438000 [ 12K] rw-/rwx SM=NUL
/opt/local/lib/libcrypto.0.9.8.dylib
__DATA 004c8000-004cc000 [ 16K] rw-/rwx SM=COW
/opt/local/lib/libssl.0.9.8.dylib
MALLOC_LARGE 004df000-004ec000 [ 52K] rw-/rwx SM=PRV
DefaultMallocZone_0x500000
MALLOC_TINY 00500000-00605000 [ 1044K] rw-/rwx SM=COW
DefaultMallocZone_0x500000
Performance tool data 00605000-00685000 [ 512K] rw-/rwx SM=COW
MALLOC_LARGE 00685000-006ad000 [ 160K] rw-/rwx SM=PRV
DefaultMallocZone_0x500000
Performance tool data 006e4000-006ed000 [ 36K] rw-/rwx SM=COW
MALLOC (freed?) 00800000-01008000 [ 8224K] rw-/rwx SM=PRV
MALLOC_LARGE 01008000-01208000 [ 2048K] rw-/rwx SM=PRV
DefaultMallocZone_0x500000
MALLOC 01800000-02008000 [ 8224K] rw-/rwx SM=COW
DefaultMallocZone_0x500000
__DATA 8fe53000-8fe54000 [ 4K] rw-/rwx SM=COW /usr/lib/dyld
__DATA 8fe54000-8fe5a000 [ 24K] rw-/rwx SM=COW /usr/lib/dyld
__DATA 8fe5a000-8fe5d000 [ 12K] rw-/rwx SM=PRV /usr/lib/dyld
__DATA a0000000-a0002000 [ 8K] rw-/rw- SM=COW
/usr/lib/libSystem.B.dylib
__DATA a0002000-a0003000 [ 4K] rw-/rw- SM=COW
/usr/lib/libSystem.B.dylib
__DATA a0003000-a0004000 [ 4K] rw-/rw- SM=COW
/usr/lib/libSystem.B.dylib
__DATA a0004000-a0005000 [ 4K] rw-/rw- SM=COW
/usr/lib/libSystem.B.dylib
__DATA a0005000-a000b000 [ 24K] rw-/rw- SM=COW
/usr/lib/libSystem.B.dylib
__DATA a000b000-a0010000 [ 20K] rw-/rw- SM=ZER
/usr/lib/libSystem.B.dylib
__DATA a0010000-a0011000 [ 4K] rw-/rw- SM=COW
/usr/lib/libSystem.B.dylib
__DATA a0011000-a0012000 [ 4K] rw-/rw- SM=ZER
/usr/lib/libSystem.B.dylib
__DATA a1433000-a1434000 [ 4K] rw-/rw- SM=COW
/usr/lib/libgcc_s.1.dylib
Stack bf800000-bffff000 [ 8188K] rw-/rwx SM=PRV
Stack bffff000-c0000000 [ 4K] rw-/rwx SM=COW thread 0
==== Legend
SM=sharing mode:
COW=copy_on_write PRV=private NUL=empty ALI=aliased
SHM=shared ZER=zero_filled S/A=shared_alias
==== Summary for process 27270
ReadOnly portion of Libraries: Total=6092KB resident=2944KB(48%)
swapped_out_or_unallocated=3148KB(52%)
Writable regions: Total=30036KB written=504KB(2%) resident=968KB(3%)
swapped_out=0KB(0%) unallocated=29068KB(97%)
REGION TYPE [ VIRTUAL]
=========== [ =======]
MALLOC [ 20816K]
Performance tool data [ 548K]
STACK GUARD [ 16K]
Stack [ 8192K]
VM_ALLOCATE ? [ 4K]
__DATA [ 540K]
__LINKEDIT [ 1364K]
__PAGEZERO [ 4K]
__TEXT [ 4728K]
mapped file [ 54952K]
system [ 8K]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 7:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: barkalow, raa.lkml, Johannes.Schindelin, ae, tsuna, git, make-w32
In-Reply-To: <47145D6D.80001@viscovery.net>
> Date: Tue, 16 Oct 2007 08:42:53 +0200
> From: Johannes Sixt <j.sixt@viscovery.net>
> Cc: Daniel Barkalow <barkalow@iabervon.org>, raa.lkml@gmail.com,
> Johannes.Schindelin@gmx.de, ae@op5.se,
> Benoit SIGOURE <tsuna@lrde.epita.fr>,
> "git@vger.kernel.org >> Git Mailing List" <git@vger.kernel.org>,
> Make Windows <make-w32@gnu.org>
>
> Thanks to Marius Storm-Olsen we already have a stat replacement that's twice
> as fast as msvcrt's stat. I calls only one API function
> (GetFileAttributesEx, but of course I don't know what's going on under its
> hood), because we need only a small part of struct stat filled in correctly.
Yes, I've seen that. What I'm saying is that you can combine
`readdir' with `stat' in one API call (FindFirstFile/FindNextFile),
which will both read the directory and return you the attributes you
get from `stat'. Think about `readdir' that brings you mode bits and
modification time together with the name, as some modern systems do.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Michael Witten @ 2007-10-16 7:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071016070421.GE13801@spearce.org>
On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote:
> The C code is all tabs, with the tabs set at 8 spaces, but the
> actual tab width isn't too important here as we never use the tab
> for alignment beyond the left indent.
Consider this from diff-lib.c:
> /* A file entry went away or appeared */
> static void diff_index_show_file(struct rev_info *revs,
> const char *prefix,
> struct cache_entry *ce,
> unsigned char *sha1, unsigned int mode)
> {
> diff_addremove(&revs->diffopt, prefix[0], ntohl(mode),
> sha1, ce->name, NULL);
> }
There are mixed tabs and spaces for alignment.
I suppose I'll be fine if I just set tab widths to 8.
But 8 spaces! Good Lord. ;-)
I really hate tabs.
Thanks,
Michael Witten
^ permalink raw reply
* SLES 10 git packages
From: Thomas Glanzmann @ 2007-10-16 7:27 UTC (permalink / raw)
To: GIT
Hello,
is there someone out there who maintains up2date git packages for SuSE
Linux Enterprise Server 10?
Thomas
^ permalink raw reply
* Re: [PATCH 1/5] Add a generic tree traversal to fetch SVN properties.
From: Eric Wong @ 2007-10-16 7:43 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git
In-Reply-To: <1192462506-3783-1-git-send-email-tsuna@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> * git-svn.perl (&traverse_ignore): Remove.
> (&prop_walk): New.
> (&cmd_show_ignore): Use prop_walk.
>
> Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Although I myself have never needed this functionality, this series
looks pretty good in general.
Thanks.
One comment below about property selection (whitelist vs blacklist).
It would be possible to get identical information out of unhandled.log,
but older repositories may not have complete information... Maybe some
local option would be good for people with complete unhandled.log files;
but it could be really incomplete/insufficient.
I'm not sure about 5/5, it's purely a style issue, however I don't
really feel strongly about a trailing "\n" either way... Nevertheless,
it is definitely not part of this series and should be treated
independently.
Coding style
Other than that, I prefer to keep braces on the same line as foreach,
if, else statements. I generally follow the git and Linux coding
style for C in my Perl code.
One exception that I make for Perl (but not C) is that I keep the "{"
for subs on the same line (since subs can be nested and anonymous ones
passed as arguments and such); unlike their C counterparts[1]
[1] - well, nesting functions is allowed in C99 or GNU C, I can't
remember which or both...
> ---
> git-svn.perl | 66 ++++++++++++++++++++++++++++++++++++++++-----------------
> 1 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..abc83ec 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -488,7 +488,15 @@ sub cmd_show_ignore {
> my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> $gs ||= Git::SVN->new;
> my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
> - $gs->traverse_ignore(\*STDOUT, $gs->{path}, $r);
> + $gs->prop_walk($gs->{path}, $r, sub {
> + my ($gs, $path, $props) = @_;
> + print STDOUT "\n# $path\n";
> + my $s = $props->{'svn:ignore'} or return;
> + $s =~ s/[\r\n]+/\n/g;
> + chomp $s;
> + $s =~ s#^#$path#gm;
> + print STDOUT "$s\n";
> + });
> }
>
> sub cmd_multi_init {
> @@ -1480,28 +1488,46 @@ sub rel_path {
> $url;
> }
>
> -sub traverse_ignore {
> - my ($self, $fh, $path, $r) = @_;
> - $path =~ s#^/+##g;
> - my $ra = $self->ra;
> - my ($dirent, undef, $props) = $ra->get_dir($path, $r);
> +# prop_walk(PATH, REV, SUB)
> +# -------------------------
> +# Recursively traverse PATH at revision REV and invoke SUB for each
> +# directory that contains a SVN property. SUB will be invoked as
> +# follows: &SUB(gs, path, props); where `gs' is this instance of
> +# Git::SVN, `path' the path to the directory where the properties
> +# `props' were found. The `path' will be relative to point of checkout,
> +# that is, if url://repo/trunk is the current Git branch, and that
> +# directory contains a sub-directory `d', SUB will be invoked with `/d/'
> +# as `path' (note the trailing `/').
> +sub prop_walk {
> + my ($self, $path, $rev, $sub) = @_;
> +
> + my ($dirent, undef, $props) = $self->ra->get_dir($path, $rev);
> + $path =~ s#^/*#/#g;
> my $p = $path;
> - $p =~ s#^\Q$self->{path}\E(/|$)##;
> - print $fh length $p ? "\n# $p\n" : "\n# /\n";
> - if (my $s = $props->{'svn:ignore'}) {
> - $s =~ s/[\r\n]+/\n/g;
> - chomp $s;
> - if (length $p == 0) {
> - $s =~ s#\n#\n/$p#g;
> - print $fh "/$s\n";
> - } else {
> - $s =~ s#\n#\n/$p/#g;
> - print $fh "/$p/$s\n";
> - }
> - }
> + # Strip the irrelevant part of the path.
> + $p =~ s#^/+\Q$self->{path}\E(/|$)#/#;
> + # Ensure the path is terminated by a `/'.
> + $p =~ s#/*$#/#;
> +
> + # The properties contain all the internal SVN stuff nobody
> + # (usually) cares about.
How about having a blacklist (for the author, date, log, uuid?) instead
of a whitelist? I can't remember all of them that should be blacklisted,
but maybe it's just author, date and log)..
> + my $interesting_props = 0;
> + foreach(keys %{$props})
> + {
> + # If it doesn't start with `svn:', it must be a
> + # user-defined property.
> + ++$interesting_props and next if $_ !~ /^svn:/;
> + # FIXME: Fragile, if SVN adds new public properties,
> + # this needs to be updated.
> + ++$interesting_props if /^svn:(?:ignore|keywords|executable
> + |eol-style|mime-type
> + |externals|needs-lock)$/x;
> + }
> + &$sub($self, $p, $props) if $interesting_props;
> +
> foreach (sort keys %$dirent) {
> next if $dirent->{$_}->{kind} != $SVN::Node::dir;
> - $self->traverse_ignore($fh, "$path/$_", $r);
> + $self->prop_walk($path . '/' . $_, $rev, $sub);
> }
> }
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: use "no warnings 'once'" to disable false-positives
From: Eric Wong @ 2007-10-16 7:43 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20071015071912.GG984@void.codelabs.ru>
Thanks, minor nit regarding fixed in the patch below.
"{ no warnings 'once';"
on the same line as the "{"
From: Eygene Ryabinkin <rea-git@codelabs.ru>
Date: Mon, 15 Oct 2007 11:19:12 +0400
Subject: [PATCH] git-svn: use "no warnings 'once'" to disable false-positives
Some variables coming from the Subversion's Perl bindings are used
in our code only once, so the interpreter warns us about it. These
warnings are false-positives, because the variables themselves are
initialized in the binding's guts, that are made by SWIG.
Credits to Sam Vilain for his note about "no warnings 'once'".
[ew: minor formatting change]
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 87 ++++++++++++++++++++++++++++-----------------------------
1 files changed, 43 insertions(+), 44 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 2c8a158..1130a09 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2303,23 +2303,31 @@ sub ssl_server_trust {
my ($cred, $realm, $failures, $cert_info, $may_save, $pool) = @_;
$may_save = undef if $_no_auth_cache;
print STDERR "Error validating server certificate for '$realm':\n";
- if ($failures & $SVN::Auth::SSL::UNKNOWNCA) {
- print STDERR " - The certificate is not issued by a trusted ",
- "authority. Use the\n",
- " fingerprint to validate the certificate manually!\n";
- }
- if ($failures & $SVN::Auth::SSL::CNMISMATCH) {
- print STDERR " - The certificate hostname does not match.\n";
- }
- if ($failures & $SVN::Auth::SSL::NOTYETVALID) {
- print STDERR " - The certificate is not yet valid.\n";
- }
- if ($failures & $SVN::Auth::SSL::EXPIRED) {
- print STDERR " - The certificate has expired.\n";
- }
- if ($failures & $SVN::Auth::SSL::OTHER) {
- print STDERR " - The certificate has an unknown error.\n";
- }
+ {
+ no warnings 'once';
+ # All variables SVN::Auth::SSL::* are used only once,
+ # so we're shutting up Perl warnings about this.
+ if ($failures & $SVN::Auth::SSL::UNKNOWNCA) {
+ print STDERR " - The certificate is not issued ",
+ "by a trusted authority. Use the\n",
+ " fingerprint to validate ",
+ "the certificate manually!\n";
+ }
+ if ($failures & $SVN::Auth::SSL::CNMISMATCH) {
+ print STDERR " - The certificate hostname ",
+ "does not match.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::NOTYETVALID) {
+ print STDERR " - The certificate is not yet valid.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::EXPIRED) {
+ print STDERR " - The certificate has expired.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::OTHER) {
+ print STDERR " - The certificate has ",
+ "an unknown error.\n";
+ }
+ } # no warnings 'once'
printf STDERR
"Certificate information:\n".
" - Hostname: %s\n".
@@ -2403,20 +2411,6 @@ sub _read_password {
$password;
}
-package main;
-
-{
- my $kill_stupid_warnings = $SVN::Node::none.$SVN::Node::file.
- $SVN::Node::dir.$SVN::Node::unknown.
- $SVN::Node::none.$SVN::Node::file.
- $SVN::Node::dir.$SVN::Node::unknown.
- $SVN::Auth::SSL::CNMISMATCH.
- $SVN::Auth::SSL::NOTYETVALID.
- $SVN::Auth::SSL::EXPIRED.
- $SVN::Auth::SSL::UNKNOWNCA.
- $SVN::Auth::SSL::OTHER;
-}
-
package SVN::Git::Fetcher;
use vars qw/@ISA/;
use strict;
@@ -2833,16 +2827,21 @@ sub open_or_add_dir {
if (!defined $t) {
die "$full_path not known in r$self->{r} or we have a bug!\n";
}
- if ($t == $SVN::Node::none) {
- return $self->add_directory($full_path, $baton,
- undef, -1, $self->{pool});
- } elsif ($t == $SVN::Node::dir) {
- return $self->open_directory($full_path, $baton,
- $self->{r}, $self->{pool});
- }
- print STDERR "$full_path already exists in repository at ",
- "r$self->{r} and it is not a directory (",
- ($t == $SVN::Node::file ? 'file' : 'unknown'),"/$t)\n";
+ {
+ no warnings 'once';
+ # SVN::Node::none and SVN::Node::file are used only once,
+ # so we're shutting up Perl's warnings about them.
+ if ($t == $SVN::Node::none) {
+ return $self->add_directory($full_path, $baton,
+ undef, -1, $self->{pool});
+ } elsif ($t == $SVN::Node::dir) {
+ return $self->open_directory($full_path, $baton,
+ $self->{r}, $self->{pool});
+ } # no warnings 'once'
+ print STDERR "$full_path already exists in repository at ",
+ "r$self->{r} and it is not a directory (",
+ ($t == $SVN::Node::file ? 'file' : 'unknown'),"/$t)\n";
+ } # no warnings 'once'
exit 1;
}
@@ -3068,11 +3067,11 @@ sub new {
my $dont_store_passwords = 1;
my $conf_t = ${$config}{'config'};
{
+ no warnings 'once';
# The usage of $SVN::_Core::SVN_CONFIG_* variables
# produces warnings that variables are used only once.
# I had not found the better way to shut them up, so
- # warnings are disabled in this block.
- no warnings;
+ # the warnings of type 'once' are disabled in this block.
if (SVN::_Core::svn_config_get_bool($conf_t,
$SVN::_Core::SVN_CONFIG_SECTION_AUTH,
$SVN::_Core::SVN_CONFIG_OPTION_STORE_PASSWORDS,
@@ -3087,7 +3086,7 @@ sub new {
1) == 0) {
$Git::SVN::Prompt::_no_auth_cache = 1;
}
- }
+ } # no warnings 'once'
my $self = SVN::Ra->new(url => $url, auth => $baton,
config => $config,
pool => SVN::Pool->new,
--
1.5.3.4.1173.gcfeee
--
Eric Wong
^ permalink raw reply related
* Re: git-fast-import crashes
From: Pierre Habouzit @ 2007-10-16 7:46 UTC (permalink / raw)
To: Shun Kei Leung; +Cc: git, Shawn O. Pearce
In-Reply-To: <e66701d40710160013h270f685sef57f80382089f3c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]
On Tue, Oct 16, 2007 at 07:13:31AM +0000, Shun Kei Leung wrote:
> Hi Pierre,
>
> I have tested with your patch applied, and it still crashed badly.
okay
> I compiled the b449f4c version and I got a different backtrace from
> GDB. I am still not sure about how the error occurs. I attached the
> memory usage from various command line tools.
I believe you should rather test master as any of the strbuf stages is
broken for you, and that there has been some issues with strbuf fixed
lately (not only the patch I asked you to try, but also an issue with
empty strubufs, and you _need_ that patch).
> GDB output
> ===========
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x756c7463
> 0x90018d0c in szone_realloc ()
> (gdb) bt
> #0 0x90018d0c in szone_realloc ()
> #1 0x90018898 in realloc ()
> #2 0x0001f8c8 in strbuf_grow (sb=0x75ef8, extra=0) at git-compat-util.h:223
> #3 0x0001fc14 in read_line (sb=0x75ef8, fp=0xa0001b9c, term=10) at strbuf.c:107
> #4 0x00002da8 in read_next_command () at fast-import.c:1599
> #5 0x0000742c in cmd_new_commit () at fast-import.c:2118
> #6 0x00007e80 in main (argc=1, argv=0xbffff828) at fast-import.c:2390
> (gdb) frame 3
> #3 0x0001fc14 in read_line (sb=0x75ef8, fp=0xa0001b9c, term=10) at strbuf.c:107
> 107 strbuf_grow(sb, 1);
> (gdb) print *sb
> $1 = {
> alloc = 60,
> len = 23,
> eof = 0,
> buf = 0x5020b0 "D windows/packages/cdc/ces/adm"
> }
> (gdb) frame 2
> #2 0x0001f8c8 in strbuf_grow (sb=0x75ef8, extra=0) at git-compat-util.h:223
> 223 void *ret = realloc(ptr, size);
> (gdb) print (char *) ptr
> $2 = 0x5020b0 "D windows/packages/cdc/ces/adm"
> (gdb) print (char *)ret
> $3 = 0xd <Address 0xd out of bounds>
This does not make sense, ptr should be either valid or NULL.
> The output of `leaks'
> =================
>
> Process 27075: 88 nodes malloced for 2335 KB
> Process 27075: 6 leaks for 624 total leaked bytes.
> Leak: 0x005012b0 size=208 string 'EOT'
> Leak: 0x00501e60 size=128 string 'EOT'
> Leak: 0x00501c80 size=128 string 'EOT'
> Leak: 0x00500f10 size=64 string 'EOT'
> Leak: 0x00501fa0 size=64 string 'EOT'
> Leak: 0x00501f60 size=32
> 0x00000000 0x02008000 0x00000000 0x01000000 ................
> 0x02000000 0x0000001a 0x00000000 0x00000000 ................
What I _really_ need is that you run your test into valgrind (the easy
way is to rename git-fast-import into git-fast-import.bin, and make
git-fast-import be a shell-script doing:
exec valgrind --log-file /tmp/git-fast-import git-fast-import "$@"
and please send to me the /tmp/git-fast-import.<pid> from the one that
crashes.
And please do that on the most recent tip of master so that you have a
(at least believe to be) full and sane strbuf series. Thanks.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: should git command and git-command be equivalent?
From: Matthieu Moy @ 2007-10-16 7:48 UTC (permalink / raw)
To: franky; +Cc: git
In-Reply-To: <20071016032240.AD2FD7E80@mail.kooxoo.com>
"franky" <yinping@kooxoo.com> writes:
> I use git-init frequently and it confuses me for a long time that I
> can't init a bare repository.
> I just found I can do that by "git -bare init". However, I get used
> to "git-init" and I always tried "git-init -bare" (of course failed)
> And I thought git-init and "git init" were always the same as most
> newbies of git.
AFAIK, git-init and "git init" are equivalent, but as you noticed
already, the advantage of "git init" is that you can pass options to
the git command, not only to the "init" subcommand.
Also, you can use aliases (for example, I type "git st" to do "git
status") with "git whatever", but not with "git-whatever" (unless you
define the alias in your shell).
The git-whatever syntax is more or less deprecated, although I guess
it will stay forever at least for compatibility.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Git homepage: remove all the references to Cogito
From: Matthieu Moy @ 2007-10-16 7:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20071016021933.GH12156@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm not sure this is good idea, Cogito is still quite frequently used
> and it should be documented that it exists.
I think reformulating the mention to cogito (use past sentence like
"cogito was a popular ...") would be better. As a side-effect, it
would also credit you for your work, which I think is fair :-).
--
Matthieu
^ permalink raw reply
* Re: .gitignore and svn:ignore [WAS: git-svn and submodules]
From: Eric Wong @ 2007-10-16 7:58 UTC (permalink / raw)
To: Chris Shoemaker
Cc: Karl Hasselström, Benoit SIGOURE, git list,
Johannes Schindelin
In-Reply-To: <20071015151405.GA1655@pe.Belkin>
Chris Shoemaker <c.shoemaker@cox.net> wrote:
> On Mon, Oct 15, 2007 at 04:45:13PM +0200, Karl Hasselström wrote:
> > On 2007-10-15 09:07:21 +0200, Benoit SIGOURE wrote:
> >
> > > - git svn create-ignore (to create one .gitignore per directory
> > > from the svn:ignore properties. This has the disadvantage of
> > > committing the .gitignore during the next dcommit,
> >
> > I built ignore support for git-svnignore a long time ago. It converts
> > the per-directory svn:ignore to per-directory .gitignore at commit
> > import time, which is very handy:
> >
> > -I <ignorefile_name>::
> > Import the svn:ignore directory property to files with this
> > name in each directory. (The Subversion and GIT ignore
> > syntaxes are similar enough that using the Subversion patterns
> > directly with "-I .gitignore" will almost always just work.)
> >
> > The only downside with that is that svn ignore patterns are
> > non-recursive, while git ignore patterns are recursive. This could be
> > solved by prefixing them with a "/".
>
> Has anyone put any thought into mapping the other direction?
> i.e. .gitignore -> svn:ignore
If we support .gitignore <-> svn:ignore in git-svn; bidirectional,
transparent mapping is the only way I want to go.
This means that *all* .gitignore files will be translated to svn:ignore
files and vice versa; and the .gitignore files will be NOT be committed
to SVN itself, but present in the git-svn created mirrors. Recursive
.gitignore definitions will be mapped to svn:ignore recursively on the
client side; and non-recursive ones will only map to one directory.
Sound good?
I may be sleepy at the moment, but the thought of implementing this is
sounding complicated now...
One goal of git-svn is that other users shouldn't be able to tell if a
user is using git-svn or plain svn; even.
But back to submodules, I plan on mapping svn:externals <=> .gitmodules
files in a similar fashion. .gitmodule files will never be seen by SVN
users, period.
That being said, the first step to submodule/externals support in
git-svn will be to allow /any/ git repository to use a submodule that
points to SVN; and then git-submodule will invoke git-svn if it
sees such a submodule.
Yes, I have a plan, sort of...
Since externals/submodules don't operate recursively in either
system like .gitignore; supporting svn:externals <=> submodules
will be much easier and done first[1] :)
[1] - I've personally rarely bothered with putting svn:ignores in the
repository and have been very much spoiled by .git/info/exclude;
whereas externals support I have semi-immediate use for.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Git homepage: remove all the references to Cogito
From: Paolo Ciarrocchi @ 2007-10-16 8:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Petr Baudis, git
In-Reply-To: <vpqlka3sdka.fsf@bauges.imag.fr>
On 10/16/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > I'm not sure this is good idea, Cogito is still quite frequently used
> > and it should be documented that it exists.
>
> I think reformulating the mention to cogito (use past sentence like
> "cogito was a popular ...") would be better. As a side-effect, it
> would also credit you for your work, which I think is fair :-).
Yes, I probably be too rude. Sorry abot that Pasky, I just feel like
the home page is a bit confusing with regards to Cogito. My
understanding is that it is no longer maintained and therefore we
probably should not encourage new user to use it.
Maybe changing:
Cogito
Cogito is a popular version control system on top of Git. It aims
at seamless user interface and ease of use, providing generally
smoother user experience than the "raw" Git interface and indeed also
many other version control systems. However, it also lacks many
advanced capabilities of Git and is currently being slowly phased out.
into
Cogito
Cogito was a popular version control system on top of Git. It aims
at seamless user interface and ease of use, providing generally
smoother user experience than the "raw" Git interface and indeed also
many other version control systems. However, it also lacks many
advanced capabilities of Git and is not actively maintained any
longer.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: git-fast-import crashes
From: Shun Kei Leung @ 2007-10-16 8:01 UTC (permalink / raw)
To: Pierre Habouzit, Shun Kei Leung, git, Shawn O. Pearce
In-Reply-To: <20071016074645.GA6919@artemis.corp>
> What I _really_ need is that you run your test into valgrind (the easy
> way is to rename git-fast-import into git-fast-import.bin, and make
> git-fast-import be a shell-script doing:
...
valgrind is not yet ported to Mac OS X, sadly enough.
Regards,
Kevin Leung
^ 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