* Re: git-rebase nukes multiline comments
From: Junio C Hamano @ 2006-06-16 23:21 UTC (permalink / raw)
To: David Kowis; +Cc: git
In-Reply-To: <1150494975.DBA8A55@be12.dngr.org>
David Kowis <dkowis@shlrm.org> writes:
>>> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>>> Author: David Kowis <dkowis@kain.org>
>>> Date: Fri Jun 16 12:20:08 2006 -0500
>>>
>>> this is a multi
>>>
>>> line comment
>>> with three lines
>>>
>>>
>>> I'm using git 1.4.0. It added a blank line in there...
>>
>> Actually, this is an odd but intended behaviour ;-).
>
> Why is this behaviour intended? Just because I'm curoius. :)
You are not alone; sorry for the terse and confusing initial
response (I am just back from a long flight, finished
unpacking and quite tired).
At the lowest level of git that defines the object format, a
commit object consists of structural header in fixed format,
followed by any binary blob you feed git-commit-tree from the
standard input. I do not recall the details of the
implementation offhand, but we _might_ chomp at the first NUL
and if we did so I may say it is a bug -- commit-tree should not
care what "the log message" part consists of.
It is however quite a different story when it comes to the
higher level tools that come with git. The log summarize
facilities to let humans interact with the commits expect that a
commit log message consists of a one-line "summary", a blank
line, and then the body of the message. These "log listers" are:
. git log --pretty=oneline
. gitk
. gitweb
. gitview
. git shortlog
The "one-line summary plus body of the message" has a strong
correlation with how we communicate patches via e-mail. You do
not start a sentence on the "Subject: " header and continue on
to the body of the message, starting the body halfway of the
sentence. Instead, you try to make sure you write something
sensible by itself on the "Subject: " header to help the
recipient when later scanning for it among bunch of messages,
and you write a full paragraph that you can understand without
reading the subject line first. The following commands that
deal with e-mailed patches expect you to follow that convention:
. git am
. git applymbox
. git format-patch
Now, answer to your question why rebase bahaves that way are
because:
(1) I was lazy and reused the e-mailed patch machinery to
implement it, although rebase is something that _should_
work at a level closer to the core level than the human
level (e.g. it should be able to commute a patch that
affects binary content changes -- which it does).
(2) The user should be following the convention to make the
output from the log listers reasonable anyway, so the only
people who are harmed by reusing the e-mailed patch
machinery were people who did not finish a short-and-sweet
summary sentence on the first line, and it is better to
train users to do so anyway.
Having said that, I would say it is a bug. We should be able to
rebase, cherry-pick and/or rebase a patch with an arbitrary
binary garbage in the commit log message (I think the latter two
command do). But because of the reason (2) above, it is very
low on my priority to change it.
^ permalink raw reply
* Re: Collecting cvsps patches
From: Junio C Hamano @ 2006-06-16 23:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6v7vr$ila$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Yann Dirson wrote:
>
>> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>>
>>> > http://ydirson.free.fr/soft/git/cvsps.git
>>>
>>> I think you need to chmod +x hooks/post-update
>>>
>>> and then run 'git-update-server-info'.
>>
>> Unfortunately, I only have FTP access to push to this site, so I have
>> to run git-update-server-info myself, and occasionally forget. I'll
>> have to bring up-to-date my old cg-ftppush script some day :)
>
> Or extend git to allow push/pull also via ftp?
Patches welcome.
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: Linus Torvalds @ 2006-06-17 0:22 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <44931AFD.4070809@zytor.com>
On Fri, 16 Jun 2006, H. Peter Anvin wrote:
>
> Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of
> the protocol itself.
Absolutely. I'm just irritated at myself for not going that way in the
first place, but when I originally wrote it, I had my eyes on other
issues, and the nice status updates got added later..
Linus
^ permalink raw reply
* Re: Porcelain specific metadata under .git?
From: Shawn Pearce @ 2006-06-17 0:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
In-Reply-To: <44900A2F.7050704@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Jakub Narebski wrote:
> >Andreas Ericsson wrote:
> >
> >
> >>Shawn Pearce wrote:
> >>
> >>>I already assume/know that refs/heads and refs/tags are completely
> >>>off-limits as they are for user refs only.
> >>>
> >>>I also think the core GIT tools already assume that anything
> >>>directly under .git which is strictly a file and which is named
> >>>entirely with uppercase letters (aside from "HEAD") is strictly a
> >>>temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
> >>>Porcelain.
> >>>
> >>>But is saying ".git/refs/eclipse-workspaces" is probably able to
> >>>be used for this purpose safe? :-)
> >>>
> >>
> >>.git/eclipse/whatever-you-like
> >>
> >>would probably be better. Heads can be stored directly under .git/refs
> >>too. Most likely, nothing will ever be stored under ./git/eclipse by
> >>either core git or the current (other) porcelains though.
> >
> >
> >I think if it is a ref, which one wants to be visible to git-fsck (and
> >git-prune), it should be under .git/refs.
> >
>
> Yes, but I understood him to mean "it's a tree-sha" instead of a
> branch/head thing, which would mean it doesn't fit the .git/refs
> definition of ref.
Sorry for the late response to this but I've been busy with real
work for the past few days and have not been able to get around to
fun work. :-)
Yes, its a tree-sha. There's no point in generating a commit for
this tree as it is serving a purpose similar to the index in core
GIT. It is a tree which represents the current directory state,
or something recently near to it anyway. Not enough information
exists to warrant building a commit however, nor is there really
any suitable parent for such a commit. Ditto with a tag.
I'm planning on periodically performing a write-tree of the current
working directory whenever Eclipse has notified the team provider of
tracked resources being modified, with the write-tree occuring no
more frequently then a user set threshold, or whenever the project
is closed or the workbench is shutdown.
I figure that if the user hasn't re-modified an already "known to
be changed" (due to different stat data) file in the last 5 minutes
and we haven't written a tree out (for any reason) in the last 15
minutes then maybe we should generate a tree right now as the user
is likely to commit one soon. Generating a tree in the background
on a low priority thread while the user is busy thinking will make
commits "go faster", especially if all I need to do is generate the
commit object itself as the tree is already made. :-)
It also just makes things easier, as I need the diff-tree code
anyway so making use of that to also track the working directory
just seems to make sense.
I want it under .git/refs as I don't really want my in progress
tree to go away due to a prune issued by the user. At least not
until I have a different tree stored there anyway.
So I'm going to store them under .git/refs/eclipse/some-path.
--
Shawn.
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Juergen Ruehle @ 2006-06-17 1:02 UTC (permalink / raw)
To: Niklas Frykholm, git
In-Reply-To: <17554.48926.852000.679014@lapjr.intranet.kiel.bmiag.de>
Juergen Ruehle writes:
> The following hack is a workaround, but is probably not safe.
Please just ignore it, it only helps on FAT32 partitions. Sorry for
the confusion.
jr
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-17 1:23 UTC (permalink / raw)
To: git, Juergen Ruehle
In-Reply-To: <17555.21858.292000.494454@lapjr.intranet.kiel.bmiag.de>
On Sat, Jun 17, 2006 at 03:05:38AM +0200, Juergen Ruehle wrote:
>Christopher Faylor writes:
> > I also meant to ask if there was an i is nonzero after the call to the
> > rename() above? If so, what was the errno? If not, it is a huge
> > problem if rename is reporting that it is able to rename a file but is
> > not actually doing it.
>
>After some testing the conclusion is that it's not lying, but only
>failing in interesting ways on my (and seemingly also Niklas') system:
>
> - rename on NTFS succeeds (and returns 0)
>
> - rename on FAT32 succeeds if target does not exist (and returns 0)
>
> rename on FAT32 fails if target exists with EACCESS
>
> (manual mv on commandline works)
>
> - rename on a network share always hangs for a while and then fails
> with EBUSY (even if target does not exist)
>
> (share served by XP, tested both NTFS and FAT32)
>
> (manual mv still works)
>
>Various combinations of server, ntsec, and smbntsec didn't seem to
>make a difference; /etc/{passwd,group} have been freshly created.
Thanks. I really appreciate the details. I've passed them on to the
last person to touch the rename code.
cgf
^ permalink raw reply
* git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 2:18 UTC (permalink / raw)
To: git
I downloaded the git-1.4.0.tar.bz2 recently and encountered a few problems.
1) The untar process creates a stray file "pax_global_header".
I am using GNU tar v1.13.22 and I get this message :
======================================================================
> tar jxf ~/u/source/git-1.4.0.tar.bz2
tar: pax_global_header: Unknown file type 'g', extracted as normal file
======================================================================
2) The make install process ignores the "prefix=..." argument. I have
to comment out one line for this :
======================================================================
> diff Makefile git-1.4.0/
94c94
< #prefix = $(HOME)
---
> prefix = $(HOME)
======================================================================
3) The make has a problem with "expat" include and libararies.
I have to add more lines to the Makefile to handle this like some
of the other include and libraries :
======================================================================
351,358c351
< endif
<
< ifndef NO_EXPAT
< ifdef EXPATDIR
< # This is still problematic -- gcc does not always want -R.
< ALL_CFLAGS += -I$(EXPATDIR)/include
< EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
< else
---
> ifndef NO_EXPAT
360c353
< endif
---
> endif
======================================================================
Other than that, it installed okay. I will have to read the docs and
use it to see how it goes otherwise.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 3:02 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
Error: branch cycle
*** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
*** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
======= Backtrace: =========
/lib/libc.so.6[0x45a502c6]
/lib/libc.so.6[0x45a5235a]
/lib/libc.so.6(calloc+0x8d)[0x45a539a1]
/lib/ld-linux.so.2[0x459db1ba]
/lib/ld-linux.so.2[0x459d6f8a]
/lib/ld-linux.so.2[0x459d91e1]
/lib/ld-linux.so.2[0x459e2204]
/lib/ld-linux.so.2[0x459de7b9]
/lib/ld-linux.so.2[0x459e1d0a]
/lib/libc.so.6[0x45ae9c3e]
/lib/ld-linux.so.2[0x459de7b9]
/lib/libc.so.6(__libc_dlopen_mode+0x55)[0x45ae9dc9]
/lib/libc.so.6[0x45ac90f6]
/lib/libc.so.6(backtrace+0x109)[0x45ac9295]
/lib/libc.so.6[0x45a4aa61]
/lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
parsecvs[0x804dec8]
parsecvs[0x804df1e]
parsecvs[0x804ccce]
/lib/libc.so.6(__libc_start_main+0xdc)[0x45a03724]
parsecvs[0x8049cc1]
======= Memory map: ========
08048000-08065000 r-xp 00000000 09:01 4052384
/home/jonsmirl/workspace/parsecvs/parsecvs
08065000-08067000 rw-p 0001c000 09:01 4052384
/home/jonsmirl/workspace/parsecvs/parsecvs
08067000-459c9000 rw-p 08067000 00:00 0 [heap]
459d1000-459ea000 r-xp 00000000 03:06 4243239 /lib/ld-2.4.so
459ea000-459eb000 r--p 00018000 03:06 4243239 /lib/ld-2.4.so
459eb000-459ec000 rw-p 00019000 03:06 4243239 /lib/ld-2.4.so
459ee000-45b1b000 r-xp 00000000 03:06 4243241 /lib/libc-2.4.so
45b1b000-45b1d000 r--p 0012d000 03:06 4243241 /lib/libc-2.4.so
45b1d000-45b1e000 rw-p 0012f000 03:06 4243241 /lib/libc-2.4.so
45b1e000-45b21000 rw-p 45b1e000 00:00 0
45b23000-45b25000 r-xp 00000000 03:06 4243258 /lib/libdl-2.4.so
45b25000-45b26000 r--p 00001000 03:06 4243258 /lib/libdl-2.4.so
45b26000-45b27000 rw-p 00002000 03:06 4243258 /lib/libdl-2.4.so
45c6e000-45c80000 r-xp 00000000 03:06 1782100 /usr/lib/libz.so.1.2.3
45c80000-45c81000 rw-p 00011000 03:06 1782100 /usr/lib/libz.so.1.2.3
46497000-46499000 r-xp 00000000 03:06 4244426 /lib/libcom_err.so.2.1
46499000-4649a000 rw-p 00001000 03:06 4244426 /lib/libcom_err.so.2.1
4649c000-464ab000 r-xp 00000000 03:06 4244425 /lib/libresolv-2.4.so
464ab000-464ac000 r--p 0000e000 03:06 4244425 /lib/libresolv-2.4.so
464ac000-464ad000 rw-p 0000f000 03:06 4244425 /lib/libresolv-2.4.so
464ad000-464af000 rw-p 464ad000 00:00 0
464bb000-465da000 r-xp 00000000 03:06 4244427 /lib/libcrypto.so.0.9.8a
465da000-465ed000 rw-p 0011e000 03:06 4244427 /lib/libcrypto.so.0.9.8a
465ed000-465f0000 rw-p 465ed000 00:00 0
465f2000-465f5000 r-xp 00000000 03:06 1785207 /usr/lib/libkrb5support.so.0.0
465f5000-465f6000 rw-p 00002000 03:06 1785207 /usr/lib/libkrb5support.so.0.0
465f8000-4666b000 r-xp 00000000 03:06 1788263 /usr/lib/libkrb5.so.3.2
4666b000-4666d000 rw-p 00073000 03:06 1788263 /usr/lib/libkrb5.so.3.2
4666f000-46687000 r-xp 00000000 03:06 1788264 /usr/lib/libgssapi_krb5.so.2.2
46687000-46688000 rw-p 00017000 03:06 1788264 /usr/lib/libgssapi_krb5.so.2.2
4668a000-466ae000 r-xp 00000000 03:06 1788262 /usr/lib/libk5crypto.so.3.0
466ae000-466af000 rw-p 00024000 03:06 1788262 /usr/lib/libk5crypto.so.3.0
467e0000-46821000 r-xp 00000000 03:06 4244428 /lib/libssl.so.0.9.8a
46821000-46825000 rw-p 00040000 03:06 4244428 /lib/libssl.so.0.9.8a
84400000-84421000 rw-p 84400000 00:00 0
84421000-84500000 ---p 84421000 00:00 0
84518000-84523000 r-xp 00000000 03:06 4244801
/lib/libgcc_s-4.1.1-20060525.so.1
84523000-84524000 rw-p 0000a000 03:06 4244801
/lib/libgcc_s-4.1.1-20060525.so.1
84538000-85438000 rw-p 84538000 00:00 0
854bc000-856bc000 rw-p 854bc000 00:00 0
8577f000-86b7f000 rw-p 8577f000 00:00 0
86bc1000-86dc1000 rw-p 86bc1000 00:00 0
86e65000-88465000 rw-p 86e65000 00:00 0
884e8000-893e8000 rw-p 884e8000 00:00 0
893e9000-896e9000 rw-p 893e9000 00:00 0
896ea000-89bea000 rw-p 896ea000 00:00 0
89c2c000-89f2c000 rw-p 89c2c000 00:00 0
89f4d000-8a14d000 rw-p 89f4d000 00:00 0
8a16e000-8a76e000 rw-p 8a16e000 00:00 0
8a76f000-8af6f000 rw-p 8a76f000 00:00 0
8b056000-8b156000 rw-p 8b056000 00:00 0
8b177000-8b477000 rw-p 8b177000 00:00 0
8b478000-8b978000 rw-p 8b478000 00:00 0
8b979000-8ba79000 rw-p 8b979000 00:00 0
8ba9a000-8bc9a000 rw-p 8ba9a000 00:00 0
8bd1e000-8c11e000 rw-p 8bd1e000 00:00 0
8c11f000-8c41f000 rw-p 8c11f000 00:00 0
8c420000-8c520000 rw-p 8c420000 00:00 0
8c582000-8c682000 rw-p 8c582000 00:00 0
8c683000-8d383000 rw-p 8c683000 00:00 0
8d426000-8d5260Aborted
[jonsmirl@jonsmirl parsecvs]$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 3:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162002x508ec6ccjbc36e4220ca44fd6@mail.gmail.com>
Hi, Jon!
On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
>
> Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
>
> Error: branch cycle
> *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
Obviously, memory corruption. Valgrind is likely to help, but it may
take 50 hours rather than 5. It may still be worth it. Make sure to
use the latest version of Valgrind and compile parsecvs without
optimization with full debug information. If you can get debug info for
libc, install it (on Fedora: "yum install glibc-debuginfo").
> /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> parsecvs[0x804dec8]
You see, even some libc symbols can be found, but parsecvs is opaque.
That's why debug information is useful. Make sure to keep the sources
around for debugging.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 3:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Keith Packard, git
In-Reply-To: <1150513943.29738.15.camel@dv>
On 6/16/06, Pavel Roskin <proski@gnu.org> wrote:
> Hi, Jon!
>
> On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> > My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
> >
> > Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
> >
> > Error: branch cycle
> > *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> > *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
>
> Obviously, memory corruption. Valgrind is likely to help, but it may
> take 50 hours rather than 5. It may still be worth it. Make sure to
> use the latest version of Valgrind and compile parsecvs without
> optimization with full debug information. If you can get debug info for
> libc, install it (on Fedora: "yum install glibc-debuginfo").
>
> > /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> > parsecvs[0x804dec8]
>
> You see, even some libc symbols can be found, but parsecvs is opaque.
> That's why debug information is useful. Make sure to keep the sources
> around for debugging.
Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
The 'Error: branch cycle' message was critical, the app was in the
process of doing exit clean up with the link list error was found. If
the list is linked in a circle it is likely that the routine freeing
it corrupted memory. So the real error is why did I get 'Error: branch
cycle'.
> --
> Regards,
> Pavel Roskin
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 4:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162031o69df27fdje50c88949ed990b5@mail.gmail.com>
On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:
> Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
Sorry, I was too quick to put blame on you. Maybe glibc can only list
its own symbols.
I could reproduce the problem trivially with a single file, and here's
what Valgrind says:
==11154== Invalid free() / delete / delete[]
==11154== at 0x4905423: free (vg_replace_malloc.c:233)
==11154== by 0x40C136: git_pack_directory (git.c:620)
==11154== by 0x40C1B4: git_rev_list_pack (git.c:639)
==11154== by 0x4067DA: main (parsecvs.c:785)
git_pack_directory() tries to free() the result of
git_system_to_string(), which is in turn a result of atom(). My
understanding is that atoms should not be freed. They are not freed in
other cases.
Patch:
diff --git a/README b/README
diff --git a/git.c b/git.c
index 33b29c7..7312568 100644
--- a/git.c
+++ b/git.c
@@ -617,7 +617,6 @@ git_pack_directory (void)
}
free (objects_dir);
pack_dir = git_format_command ("%s/objects/pack", git_dir);
- free (git_dir);
if (!pack_dir)
return NULL;
if (access (pack_dir, F_OK) == -1 &&
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 4:15 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Keith Packard, git
In-Reply-To: <1150517336.9144.8.camel@dv>
On 6/17/06, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:
>
> > Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
>
> Sorry, I was too quick to put blame on you. Maybe glibc can only list
> its own symbols.
>
> I could reproduce the problem trivially with a single file, and here's
> what Valgrind says:
>
> ==11154== Invalid free() / delete / delete[]
> ==11154== at 0x4905423: free (vg_replace_malloc.c:233)
> ==11154== by 0x40C136: git_pack_directory (git.c:620)
> ==11154== by 0x40C1B4: git_rev_list_pack (git.c:639)
> ==11154== by 0x4067DA: main (parsecvs.c:785)
>
>
> git_pack_directory() tries to free() the result of
> git_system_to_string(), which is in turn a result of atom(). My
> understanding is that atoms should not be freed. They are not freed in
> other cases.
>
> Patch:
>
> diff --git a/README b/README
> diff --git a/git.c b/git.c
> index 33b29c7..7312568 100644
> --- a/git.c
> +++ b/git.c
> @@ -617,7 +617,6 @@ git_pack_directory (void)
> }
> free (objects_dir);
> pack_dir = git_format_command ("%s/objects/pack", git_dir);
> - free (git_dir);
> if (!pack_dir)
> return NULL;
> if (access (pack_dir, F_OK) == -1 &&
I had already caught that one, the fix was a few mails back.
git_dir is an atom and shouldn't be freed with free.
After five hours I hit this:
fprintf (stderr, "Error: branch cycle\n");
static rev_ref *
rev_ref_tsort (rev_ref *refs, rev_list *head)
{
rev_ref *done = NULL;
rev_ref **done_tail = &done;
rev_ref *r, **prev;
// fprintf (stderr, "Tsort refs:\n");
while (refs) {
for (prev = &refs; (r = *prev); prev = &(*prev)->next) {
if (rev_ref_is_ready (r->name, head, done)) {
break;
}
}
if (!r) {
fprintf (stderr, "Error: branch cycle\n");
>> hit this test
return NULL;
}
*prev = r->next;
*done_tail = r;
// fprintf (stderr, "\t%s\n", r->name);
r->next = NULL;
done_tail = &r->next;
}
return done;
}
which returned null up to here
if (rev_mode == ExecuteGit && pack_objcount && autopack)
git_rev_list_pack (pack_start, strip);
load_status_next ();
rl = rev_list_merge (head);
>> null to here
if (rl) {
switch (rev_mode) {
case ExecuteGraph:
dump_rev_graph (rl, NULL);
break;
case ExecuteSplits:
dump_splits (rl);
break;
case ExecuteGit:
git_rev_list_commit (rl, strip);
break;
}
}
if (rl)
rev_list_free (rl, 0);
while (head) {
rl = head;
head = head->next;
rev_list_free (rl, 1);
>> tries to free the list, but the list is a loop.
>> after it wraps it will mangle memory
}
discard_atoms ();
rev_free_dirs ();
rev_commit_cleanup ();
git_free_author_map ();
return err;
>>But the real problem is why does it think the branches are in a loop?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 4:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com>
On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
> I had already caught that one, the fix was a few mails back.
> git_dir is an atom and shouldn't be freed with free.
I see it now. My patch was wrong - there is another free(git_dir) in
the same function. Keith, please remove both.
> After five hours I hit this:
> fprintf (stderr, "Error: branch cycle\n");
This is more like a logical error. Maybe you actually have circling
branches due to causality violations or something :-)
Sure, Valgrind would be still useful to make sure it's not something
mundane.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-17 5:26 UTC (permalink / raw)
To: Santi; +Cc: git, Yakov Lerner
In-Reply-To: <8aa486160606150426q19b0a661s@mail.gmail.com>
Santi <sbejar@gmail.com> writes:
> Wed, 14 Jun 2006 22:26 +0300, Yakov Lerner <iler.ml@gmail.com>:
>> Many times, I mistakenly used 'make prefix=... install' where prefix value
>> was different from prefix value during build. This resulted in broken
>> install. This patch adds auto-detection of $prefix change to the Makefile.
>> This results in correct install whenever prefix is changed.
>
> I do this each time I install packages from source. I keep them with
> "stow" and the usual sequence is:
>
> make prefix=/home/santi/usr
> make install prefix=/home/santi/usr/stow/git
> cd /home/santi/usr/stow/
> stow -v git
>
> so with this auto-detection I'll compile some programs twice.
I do not know what "stow" is about, but if it is to allow you to
run make-install to install things in somewhere else, examine
the result, and then move the result to the real location
(implying that you should be able to nuke the "somewhere else"
after you have done so), with the patch, the above sequence
would install the binaries pointing at a wrong directory,
because the second compilation would make them point at the
temporary installation directory ~/usr/stow/git, not the final
location ~/usr/.
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-17 5:28 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606150440l544455c7r5c52609b360d0f74@mail.gmail.com>
"Yakov Lerner" <iler.ml@gmail.com> writes:
> BTW, is it possible to have git use argv[0] to automatically determine
> the executable_dir without compiled-in paths ?
It is possible and I think we did that some time ago.
We fixed it since then, so that you can migrate away from
assuming bindir==gitexecdir.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-17 5:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Pavel Roskin, git
In-Reply-To: <9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
> >>But the real problem is why does it think the branches are in a loop?
I haven't figured it out yet either; mine didn't detect the loop though,
it just ended up spinning in the tsort code, unable to compute a valid
order to execute branches in. Something funky must be up with the
mozilla branches.
What this code does is find an order that will 'work' when computing
branch contents. The requirement is that the 'parent' branch be computed
before any 'child' branches.
It does this with a nice quadratic algorithm, building a list of 'ready'
branches who have no 'unready' dependencies in any of the incoming file
objects. If there are conflicts where one incoming file shows branch 'B'
as the parent of branch 'A' while another shows branch 'A' as the parent
of branch 'B', the sorting cannot succeed.
Ideally, I'd figure out a way to eliminate the parent/child relationship
and just treat the branches as peers with a common ancestor. I haven't
figure out how to manage that yet; attempting to find the precise
divergence point where the child forks from the parent remains
complicated, it seems like trying to do that without a strong
parent/child relationship would be even more error prone.
Better error messsages here would clearly help discover which branches
were in conflict, and show the files causing problems.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Collecting cvsps patches
From: Junio C Hamano @ 2006-06-17 5:50 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060616212334.GN7766@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>
>> > http://ydirson.free.fr/soft/git/cvsps.git
>>
>> I think you need to chmod +x hooks/post-update
>>
>> and then run 'git-update-server-info'.
>
> Unfortunately, I only have FTP access to push to this site, so I have
> to run git-update-server-info myself, and occasionally forget. I'll
> have to bring up-to-date my old cg-ftppush script some day :)
When I only had "serving HTTP, published via FTP" ISP accounts,
I essentially ended up having a bare repository on my local
machine, update it with real git-push (with the post-update hook
there), and copied that to the ISP via lftp batch.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 5:51 UTC (permalink / raw)
To: Keith Packard; +Cc: Pavel Roskin, git
In-Reply-To: <1150522246.6983.52.camel@neko.keithp.com>
On 6/17/06, Keith Packard <keithp@keithp.com> wrote:
> On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
>
> > >>But the real problem is why does it think the branches are in a loop?
>
> I haven't figured it out yet either; mine didn't detect the loop though,
> it just ended up spinning in the tsort code, unable to compute a valid
> order to execute branches in. Something funky must be up with the
> mozilla branches.
Have you checked parsecvs on the 38 test repositories in the cvs2svn source?
> What this code does is find an order that will 'work' when computing
> branch contents. The requirement is that the 'parent' branch be computed
> before any 'child' branches.
>
> It does this with a nice quadratic algorithm, building a list of 'ready'
> branches who have no 'unready' dependencies in any of the incoming file
> objects. If there are conflicts where one incoming file shows branch 'B'
> as the parent of branch 'A' while another shows branch 'A' as the parent
> of branch 'B', the sorting cannot succeed.
>
> Ideally, I'd figure out a way to eliminate the parent/child relationship
> and just treat the branches as peers with a common ancestor. I haven't
> figure out how to manage that yet; attempting to find the precise
> divergence point where the child forks from the parent remains
> complicated, it seems like trying to do that without a strong
> parent/child relationship would be even more error prone.
>
> Better error messsages here would clearly help discover which branches
> were in conflict, and show the files causing problems.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEk5OGQp8BWwlsTdMRAuyZAKC3URBHR/SWgG7azMqKe3efGNxNZwCdFAVA
> GEIKF8z/MtdbBnKRMDneSH8=
> =ShEA
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Update gitweb README: gitweb is now included with git
From: Jakub Narebski @ 2006-06-17 6:53 UTC (permalink / raw)
To: git
---
ftp://ftp.kernel.org/pub/software/scm/gitweb/ and
http://www.kernel.org/pub/software/scm/gitweb/ are empty.
http://www.kernel.org/git/?p=git/gitweb.git;a=summary
does not exist.
gitweb/README | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
52fffe22be5fc02045ee630c755dab5713afb4fb
diff --git a/gitweb/README b/gitweb/README
index 3014d73..8d67276 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -3,14 +3,7 @@ GIT web Interface
The one working on:
http://www.kernel.org/git/
-Get the gitweb.cgi by ftp:
- ftp://ftp.kernel.org/pub/software/scm/gitweb/
-
-It reqires the git-core binaries installed on the system:
- http://www.kernel.org/git/?p=git/git.git;a=summary
-
-The gitweb repository is here:
- http://www.kernel.org/git/?p=git/gitweb.git;a=summary
+From the git version 1.4.0 gitweb is bundled with git.
Any comment/question/concern to:
Kay Sievers <kay.sievers@vrfy.org>
--
1.3.0
^ permalink raw reply related
* [PATCH] Update gitweb README: gitweb is now included with git
From: Jakub Narebski @ 2006-06-17 6:57 UTC (permalink / raw)
To: git
---
ftp://ftp.kernel.org/pub/software/scm/gitweb/ and
http://www.kernel.org/pub/software/scm/gitweb/ are empty.
http://www.kernel.org/git/?p=git/gitweb.git;a=summary
does not exist.
gitweb/README | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
52fffe22be5fc02045ee630c755dab5713afb4fb
diff --git a/gitweb/README b/gitweb/README
index 3014d73..8d67276 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -3,14 +3,7 @@ GIT web Interface
The one working on:
http://www.kernel.org/git/
-Get the gitweb.cgi by ftp:
- ftp://ftp.kernel.org/pub/software/scm/gitweb/
-
-It reqires the git-core binaries installed on the system:
- http://www.kernel.org/git/?p=git/git.git;a=summary
-
-The gitweb repository is here:
- http://www.kernel.org/git/?p=git/gitweb.git;a=summary
+From the git version 1.4.0 gitweb is bundled with git.
Any comment/question/concern to:
Kay Sievers <kay.sievers@vrfy.org>
--
1.3.0
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Rene Scharfe @ 2006-06-17 6:58 UTC (permalink / raw)
To: Michael Somos; +Cc: git
In-Reply-To: <200606170218.k5H2I0o0003192@grail.cba.csuohio.edu>
| I downloaded the git-1.4.0.tar.bz2 recently and encountered a few
| problems.
|
| 1) The untar process creates a stray file "pax_global_header".
| I am using GNU tar v1.13.22 and I get this message :
|
| ======================================================================
| > tar jxf ~/u/source/git-1.4.0.tar.bz2
| tar: pax_global_header: Unknown file type 'g', extracted as normal
| file
| ======================================================================
You can ignore or delete that file. It is a pax extended global header,
containing the git commit ID as a comment. GNU tar started supporting
pax headers with version 1.13.93 (released 2004-02-23). Version 1.13.22
was released on 2001-08-29, by the way. May I ask what operating system
and version you are using?
| 2) The make install process ignores the "prefix=..." argument. I have
| to comment out one line for this :
|
| ======================================================================
| > diff Makefile git-1.4.0/
| 94c94
| < #prefix = $(HOME)
| ---
| > prefix = $(HOME)
| ======================================================================
It took me a while to realize that your diffs are reversed. It's too
early for me, I think I'll go to bed again. :)
Anyway, prefix handling is currently being worked on. Yakov Lerner sent
a patch which seems to make make do what you need.
| 3) The make has a problem with "expat" include and libararies.
| I have to add more lines to the Makefile to handle this like some
| of the other include and libraries :
|
| ======================================================================
| 351,358c351
| < endif
| <
| < ifndef NO_EXPAT
| < ifdef EXPATDIR
| < # This is still problematic -- gcc does not always want -R.
| < ALL_CFLAGS += -I$(EXPATDIR)/include
| < EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
|
| < else
| ---
| > ifndef NO_EXPAT
| 360c353
| < endif
| ---
| > endif
| ======================================================================
Looks sensible, except for the formatting.
| Other than that, it installed okay. I will have to read the docs and
| use it to see how it goes otherwise.
A good first exercise would be to fetch the git repository, edit Makefile
and commit your change, and then send a patch to this list -- all using
git (except the editing part). :-) Care to try that? Please let us know
of any difficulties you may encounter.
Thanks,
René
^ permalink raw reply
* Re: [PATCH] Update gitweb README: gitweb is now included with git
From: Jakub Narebski @ 2006-06-17 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <200606170857.02111.jnareb@gmail.com>
I'm sorry for doubled email; sending via GMane NNTP (Usenet) interface
produced error, but I haven't noticed that it was sent successfully
regardless.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Just added Now you could grant your wish Relax with
From: Joanne @ 2006-06-17 7:37 UTC (permalink / raw)
To: git
Good day to you Sir!
Make your girlfriend or wife speechless with increased hardness, richer orgsms and more power in bed
Order our magical stuff now for the amazing prices, and we will dispatch it right away
These brands keep thousands and thousands of their customers pleased worldwide
Check up here: http://www.unpraiselk.com
We offer reliable service and 5 years expirience on the marcket!
^ permalink raw reply
* [PATCH] Move gitweb style to gitweb.css
From: Jakub Narebski @ 2006-06-17 9:23 UTC (permalink / raw)
To: git; +Cc: Kay Sievers
Move gitweb style from embedded <style> element in gitweb/gitweb.cgi
to external CSS file gitweb/gitweb.css.
---
External CSS file can be downloaded only once and cached.
gitweb/gitweb.cgi | 64 +++--------------------------------------------------
gitweb/gitweb.css | 54 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 60 deletions(-)
create mode 100644 gitweb/gitweb.css
a056a67d019c513754ae33e2b2c6b75da7323b38
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index ea21fbe..9d902b7 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -38,6 +38,9 @@ my $home_link = $my_uri;
# html text to include at home page
my $home_text = "indextext.html";
+# URI of default stylesheet
+my $stylesheet = "gitweb.css";
+
# source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
@@ -257,68 +260,9 @@ sub git_header_html {
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
+<link rel="stylesheet" href="$stylesheet"/>
<title>$title</title>
$rss_link
-<style type="text/css">
-body {
- font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
- margin:10px; background-color:#ffffff; color:#000000;
-}
-a { color:#0000cc; }
-a:hover, a:visited, a:active { color:#880000; }
-div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
-div.page_header a:visited, a.header { color:#0000cc; }
-div.page_header a:hover { color:#880000; }
-div.page_nav { padding:8px; }
-div.page_nav a:visited { color:#0000cc; }
-div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
-div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
-div.page_footer_text { float:left; color:#555555; font-style:italic; }
-div.page_body { padding:8px; }
-div.title, a.title {
- display:block; padding:6px 8px;
- font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
-}
-a.title:hover { background-color: #d9d8d1; }
-div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
-div.log_body { padding:8px 8px 8px 150px; }
-span.age { position:relative; float:left; width:142px; font-style:italic; }
-div.log_link {
- padding:0px 8px;
- font-size:10px; font-family:sans-serif; font-style:normal;
- position:relative; float:left; width:136px;
-}
-div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
-a.list { text-decoration:none; color:#000000; }
-a.list:hover { text-decoration:underline; color:#880000; }
-a.text { text-decoration:none; color:#0000cc; }
-a.text:visited { text-decoration:none; color:#880000; }
-a.text:hover { text-decoration:underline; color:#880000; }
-table { padding:8px 4px; }
-th { padding:2px 5px; font-size:12px; text-align:left; }
-tr.light:hover { background-color:#edece6; }
-tr.dark { background-color:#f6f6f0; }
-tr.dark:hover { background-color:#edece6; }
-td { padding:2px 5px; font-size:12px; vertical-align:top; }
-td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
-div.pre { font-family:monospace; font-size:12px; white-space:pre; }
-div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
-div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
-div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
-a.linenr { color:#999999; text-decoration:none }
-a.rss_logo {
- float:right; padding:3px 0px; width:35px; line-height:10px;
- border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
- color:#ffffff; background-color:#ff6600;
- font-weight:bold; font-family:sans-serif; font-size:10px;
- text-align:center; text-decoration:none;
-}
-a.rss_logo:hover { background-color:#ee5500; }
-span.tag {
- padding:0px 4px; font-size:10px; font-weight:normal;
- background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
-}
-</style>
</head>
<body>
EOF
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
new file mode 100644
index 0000000..6b1fd23
--- /dev/null
+++ b/gitweb/gitweb.css
@@ -0,0 +1,54 @@
+a { color:#0000cc; }
+a:hover, a:visited, a:active { color:#880000; }
+div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
+div.page_header a:visited, a.header { color:#0000cc; }
+div.page_header a:hover { color:#880000; }
+div.page_nav { padding:8px; }
+div.page_nav a:visited { color:#0000cc; }
+div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
+div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
+div.page_footer_text { float:left; color:#555555; font-style:italic; }
+div.page_body { padding:8px; }
+div.title, a.title {
+ display:block; padding:6px 8px;
+ font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
+}
+a.title:hover { background-color: #d9d8d1; }
+div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
+div.log_body { padding:8px 8px 8px 150px; }
+span.age { position:relative; float:left; width:142px; font-style:italic; }
+div.log_link {
+ padding:0px 8px;
+ font-size:10px; font-family:sans-serif; font-style:normal;
+ position:relative; float:left; width:136px;
+}
+div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
+a.list { text-decoration:none; color:#000000; }
+a.list:hover { text-decoration:underline; color:#880000; }
+a.text { text-decoration:none; color:#0000cc; }
+a.text:visited { text-decoration:none; color:#880000; }
+a.text:hover { text-decoration:underline; color:#880000; }
+table { padding:8px 4px; }
+th { padding:2px 5px; font-size:12px; text-align:left; }
+tr.light:hover { background-color:#edece6; }
+tr.dark { background-color:#f6f6f0; }
+tr.dark:hover { background-color:#edece6; }
+td { padding:2px 5px; font-size:12px; vertical-align:top; }
+td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
+div.pre { font-family:monospace; font-size:12px; white-space:pre; }
+div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
+div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
+div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
+a.linenr { color:#999999; text-decoration:none }
+a.rss_logo {
+ float:right; padding:3px 0px; width:35px; line-height:10px;
+ border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
+ color:#ffffff; background-color:#ff6600;
+ font-weight:bold; font-family:sans-serif; font-size:10px;
+ text-align:center; text-decoration:none;
+}
+a.rss_logo:hover { background-color:#ee5500; }
+span.tag {
+ padding:0px 4px; font-size:10px; font-weight:normal;
+ background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
+}
--
1.3.0
^ permalink raw reply related
* Re: git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 10:16 UTC (permalink / raw)
To: rene.scharfe; +Cc: git
Rene Scharfe wrote :
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> You can ignore or delete that file. It is a pax extended global header,
Yes, I knew I could ignore the file right away. I figured it was due
to some new feature of GNU tar.
> was released on 2001-08-29, by the way. May I ask what operating system
> and version you are using?
Mandrake 8,1 for i586. I had not encountered problems with GNU tar 1.13.22
before. A quick google showed this was not a rare problem, but nothing in
the tarball for git-1.4.0 mentioned this problem. I understand that it may
be a rare or nonexistant problem for the target audience of "git", but just
a sentence or two would be enough clue to help out those who may need it.
> It took me a while to realize that your diffs are reversed. It's too
Yes, unfortunately, I did reverse it, but even patch can handle that.
> A good first exercise would be to fetch the git repository, edit Makefile
> and commit your change, and then send a patch to this list -- all using
A good suggestion, but I am a newbie as you can tell, and would prefer to
play in a sandbox for some time before I would attempt it. Of more concern
to me now is a failed test :
> * FAIL 12: apply diff between 3 and 2
> git-apply <diff.3-2 && diff frotz.2 frotz
> * failed 2 among 12 test(s)
> make[1]: *** [t4101-apply-nonl.sh] Error 1
All the other tests worked which is great. Thanks for your reply. Shalom,
Michael
^ 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