* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Sergey Vlasov @ 2005-08-13 12:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Dave Jones, git
In-Reply-To: <20050813110050.GA5608@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Sat, 13 Aug 2005 13:00:51 +0200 Petr Baudis wrote:
> Dear diary, on Sat, Aug 13, 2005 at 07:05:11AM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> told me that...
[...]
> > snap=git-snapshot-$(date +"%Y%m%d")
> > git-tar-tree HEAD $snap | gzip -9 > $snap.tar.gz
> >
> > which is even easier, and a hell of a lot more efficient.
>
> To put my two cents too, Cogito has cg-export for this:
>
> cg-export tmp-dir
>
> to export to a temporary directory and
>
> cg-export git-snapshot.tar.gz
>
> to export to a gzipped tarball (it can also do .tar, .tgz and .tar.bz2).
However, cg-export is buggy - if you use the second argument
(cg-export DESTFILE TREE_ID), the resulting tar file is different
from what git-tar-tree produces for the same TREE_ID (unless that
TREE_ID actually points to a tree - but in practice a commit or even
tag ID is typically used).
The problem is in this line:
id=$(tree-id "$2")
This converts the passed commit or tag to the underlying tree, which
is then passed to git-tar-tree. However, git-tar-tree can follow
such links itself, and, what's more important, it actually uses some
information from the passed commit (it writes the commit ID to the
tar file as an extended header, and sets timestamp of all archive
members to the time of the commit). Therefore reducing the ID
passed to git-tar-tree to a plain tree ID is wrong - if a commit ID
is available, it should be used.
--
Sergey Vlasov
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ANNOUNCE] qgit-0.9
From: Marco Costalba @ 2005-08-13 12:12 UTC (permalink / raw)
To: git
Hi all,
qgit-0.9 has been released and can be downloaded from
http://prdownloads.sourceforge.net/qgit/qgit-0.9.tar.bz2?download
This version fixes a couple of nasty bugs, notably one in
annotate, crept in after recent changes. Anyone interested in
annotate function should upgrade.
Big new feature is the commit dialog.
When enabled with 'edit->settings->cache->diff against working dir'
and there is something committable, qgit shows a special highlighted
first revision with the status of the archive and the possible pending
stuff. From edit->commit you can, then, invoke the commit viewer to
select the files to commit or, simply, to call git-update-cache
on them (with sync button).
It is possible to use a template for commit message, use
edit->settings->cache to define template file path.
QGit checks for possible new files added in working directory using
ignoring rules according to git-ls-files specifications,
--exclude-from and --exclude-per-directory files can be set in
menu->edit->settings->cache. Behaviour should be similar to cg-status.
Core commit function is performed by git-commit-script, although the
script itself is not enough to handle all the possibilities and some
work is necessary to prepare/restore the cache.
Commit feature and new files checking use some (transalted) code from
Fredrik Kuivinen 'gct' tool (although commit logic is different) and
Petr Baudis cg-status. Thanks to both ;-)
New select tag dialog
Another ineteresting new feature is a 'select tag' dialog shown when
qgit is launched without arguments. I found this useful to quickly
select revision range to display.
On the dialog are listed the tags, but you can paste anything that
is 'eatable' by git-rev-parse.
Complete changelog:
- added commit dialog to commit or simply update cache on selected files
- added revisions range select dialog when calling qgit
without arguments or when changing archive
- replace SHA's with short logs in commit messages links
- added F3 accelerator in file viewer for find button
- fix a nasty bug in git-diff-tree interface that sometimes
led to missing revision files
- fix proper closing of file and diff window when quitting
- fix a corner case in annotate
- fix annotation broke by a recent change
- fix spurious LF in diff viewer
Marco
P.S: Sorry for the tarball, but SF doesn't yet answerd about
my request to setup a git archive on their site.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Petr Baudis @ 2005-08-13 12:33 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Linus Torvalds, Dave Jones, git
In-Reply-To: <20050813161053.29593972.vsu@altlinux.ru>
Dear diary, on Sat, Aug 13, 2005 at 02:10:53PM CEST, I got a letter
where Sergey Vlasov <vsu@altlinux.ru> told me that...
> However, cg-export is buggy - if you use the second argument
> (cg-export DESTFILE TREE_ID), the resulting tar file is different
> from what git-tar-tree produces for the same TREE_ID (unless that
> TREE_ID actually points to a tree - but in practice a commit or even
> tag ID is typically used).
>
> The problem is in this line:
>
> id=$(tree-id "$2")
>
> This converts the passed commit or tag to the underlying tree, which
> is then passed to git-tar-tree. However, git-tar-tree can follow
> such links itself, and, what's more important, it actually uses some
> information from the passed commit (it writes the commit ID to the
> tar file as an extended header, and sets timestamp of all archive
> members to the time of the commit). Therefore reducing the ID
> passed to git-tar-tree to a plain tree ID is wrong - if a commit ID
> is available, it should be used.
Aha! Good catch, fixed, thanks.
BTW, I also changed cg-export usage to be more consistent and flexible,
by changing it from
cg-export DESTFILE [TREE_ID]
to
cg-export [-r TREE_ID] DESTFILE
since I think not many people are using cg-export anyway and much less
of them passing it TREE_ID explicitly.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [PATCH] fix git-checkout-cache segfault on parisc
From: James Bottomley @ 2005-08-13 15:29 UTC (permalink / raw)
To: junkio; +Cc: git, PARISC list
This one I think is Linus' fault, so send him a brown paper bag with my
complements ...
The index cleanup code is executed via atexit() which is *after* main
has completed, so the stack allocated cache_file has gone out of scope.
Parisc seems to use stack in the destructor functions, so cache_file
gets partially overwritten leading to the predictable disastrous
consequences.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
---
James
diff --git a/checkout-cache.c b/checkout-cache.c
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -80,10 +80,11 @@ static int checkout_all(void)
static const char checkout_cache_usage[] =
"git-checkout-cache [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...";
+static struct cache_file cache_file;
+
int main(int argc, char **argv)
{
int i, force_filename = 0;
- struct cache_file cache_file;
int newfd = -1;
if (read_cache() < 0) {
diff --git a/index.c b/index.c
^ permalink raw reply
* Merge conflict.
From: Kenneth Johansson @ 2005-08-13 14:45 UTC (permalink / raw)
To: git
I used cogito to do a cg-update and got conflicts and the exact files are
printed to the screen. But say I somehow lost that output is there anyway
to list conflicting files ??
cg-status shows the files as modified but that also includes non
conflicting files.
The best I could find was to do a "git-update-cache --refresh" but that
still do not tell me if I already have removed the conflict in the file.
Is this not something that needs to be answered if we ever are going to
have a graphical merge tool?
^ permalink raw reply
* Re: Merge conflict.
From: Petr Baudis @ 2005-08-13 16:17 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <pan.2005.08.13.14.45.32.401071@canit.se>
Dear diary, on Sat, Aug 13, 2005 at 04:45:32PM CEST, I got a letter
where Kenneth Johansson <ken@canit.se> told me that...
> I used cogito to do a cg-update and got conflicts and the exact files are
> printed to the screen. But say I somehow lost that output is there anyway
> to list conflicting files ??
>
> cg-status shows the files as modified but that also includes non
> conflicting files.
>
> The best I could find was to do a "git-update-cache --refresh" but that
> still do not tell me if I already have removed the conflict in the file.
>
> Is this not something that needs to be answered if we ever are going to
> have a graphical merge tool?
Yes, I know about this problem and something should be done about it.
The possible approaches:
* Check for /^<<<<<<</ lines (that's what CVS does)
+: User does not need to take an explicit action to indicate
resolved conflict.
-: False positives if the file with conflict contains that
string naturally.
* Make auxiliary files and check for their existence (what SVN does)
+: User can use the auxiliary files (usually containing the
to-be-merged revisions) for better conflict resolution,
or run some own merging tool on it later.
-: Extremely rare false positives.
-: User needs to explicitly get rid of the files to get rid
of the conflict.
* Keep the conflict recorded in index
+: No junk in working directory, cg-status should start working
right away.
-: Unknown caveats wrt. index files containing conflicts...?
-: User needs to explicitly run cg-resolve or something to
get rid of the conflict.
Ideas? Opinions?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [RFC] Improving compression in git network protocols
From: Sergey Vlasov @ 2005-08-13 16:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 5754 bytes --]
Hello!
The git pack format has two uses:
1) A space-optimized format for local repository storage.
2) A compact format for transferring repository data over network.
However, these uses have some conflicting requirements, and currently
the pack format is not as optimal for the task of network transfer as
it could be. In particular, because using pack files in a local
repository requires random access to the contained objects, all
objects in the pack are compressed separately, which negatively
impacts the compression rate.
I have made a patch which adds the "--compression-level=N" option to
git-pack-objects and tried to look what kind of improvement in the
compression rate we can get if we compress the whole pack file instead
of individual objects. The patch is in a separate message, however,
I'm not sure if it should be applied immediately - currently there is
no infrastructure for using this option, and maybe we will choose to
implement the same idea in some different way.
Here are the results of my tests:
===========================================================================
1. Packing the whole linux-2.4 repository (13390 objects):
-rw-r--r-- 1 vsu 159632105 Aug 13 17:12 pack-0-ef502d3d97088a8b1da4594fda438c268dc5c692.pack
-rw-r--r-- 1 vsu 30878501 Aug 13 17:16 pack-0-ef502d3d97088a8b1da4594fda438c268dc5c692.pack.bz2
-rw-r--r-- 1 vsu 38035157 Aug 13 17:14 pack-0-ef502d3d97088a8b1da4594fda438c268dc5c692.pack.gz
-rw-r--r-- 1 vsu 37739041 Aug 13 17:17 pack-0-ef502d3d97088a8b1da4594fda438c268dc5c692.pack.gz-9
-rw-r--r-- 1 vsu 43035924 Aug 13 17:12 pack-9-ef502d3d97088a8b1da4594fda438c268dc5c692.pack
-rw-r--r-- 1 vsu 43288931 Aug 13 17:11 pack-default-ef502d3d97088a8b1da4594fda438c268dc5c692.pack
The "pack-default-*" file is made without the --compression-level
option; the "pack-0-*" and "pack-9-*" files are made with level 0 (no
compression) and 9 (max compression) respectively. From this we can
see:
- Using maximum compression for objects in the pack provides little
benefit - about 0.6%.
- Creating a pack with uncompressed objects and compressing it with
gzip gives a 12% improvement over the pack with compressed objects.
Using "gzip -9" at this stage gives about 0.7% more compression.
- For an offline compression, bzip2 could be used instead of gzip -
the pack compressed with bzip2 is 28% smaller than the pack with
zlib-compressed objects.
2. Packing the whole linux-2.6 repository (67111 objects):
-rw-r--r-- 1 vsu 232977930 Aug 13 17:47 pack-0-af8d554c2a184c1ebbaab13a8f844329bcbfe763.pack
-rw-r--r-- 1 vsu 49245784 Aug 13 17:52 pack-0-af8d554c2a184c1ebbaab13a8f844329bcbfe763.pack.bz2
-rw-r--r-- 1 vsu 59767656 Aug 13 17:49 pack-0-af8d554c2a184c1ebbaab13a8f844329bcbfe763.pack.gz
-rw-r--r-- 1 vsu 59323808 Aug 13 17:50 pack-0-af8d554c2a184c1ebbaab13a8f844329bcbfe763.pack.gz-9
-rw-r--r-- 1 vsu 70067732 Aug 13 17:45 pack-9-af8d554c2a184c1ebbaab13a8f844329bcbfe763.pack
-rw-r--r-- 1 vsu 70415173 Aug 13 17:43 pack-default-af8d554c2a184c1ebbaab13a8f844329bcbfe763.pack
- Again, --compression-level=9 does not help much - only 0.5%
reduction.
- Using gzip on the pack with uncompressed objects gives 15%
improvement over the pack with compressed objects; "gzip -9" does
not help much.
- The pack with uncompressed objects compressed with bzip2 is 30%
smaller than the pack with zlib-compressed objects.
3. Creating an incremental pack for the linux-2.6 repository (743
objects):
-rw-r--r-- 1 vsu 4270645 Aug 13 17:54 pack-0-8d2c7fe3c00288d4a46fe25a61db35ec965db8a1.pack
-rw-r--r-- 1 vsu 1068277 Aug 13 17:56 pack-0-8d2c7fe3c00288d4a46fe25a61db35ec965db8a1.pack.bz2
-rw-r--r-- 1 vsu 1221308 Aug 13 17:56 pack-0-8d2c7fe3c00288d4a46fe25a61db35ec965db8a1.pack.gz
-rw-r--r-- 1 vsu 1214597 Aug 13 17:56 pack-0-8d2c7fe3c00288d4a46fe25a61db35ec965db8a1.pack.gz-9
-rw-r--r-- 1 vsu 1314817 Aug 13 17:55 pack-9-8d2c7fe3c00288d4a46fe25a61db35ec965db8a1.pack
-rw-r--r-- 1 vsu 1319322 Aug 13 17:54 pack-default-8d2c7fe3c00288d4a46fe25a61db35ec965db8a1.pack
- Once again, --compression-level=9 is next to useless - 0.3%
improvement.
- The pack with uncompressed objects compressed with gzip is 7%
smaller than the pack with zlib-compressed objects.
- The pack with uncompressed objects compressed with bzip2 is 19%
smaller than the pack with zlib-compressed objects.
===========================================================================
As you see, compressing the pack as a whole can give noticeable
improvements (less on smaller files, more on bigger files). Now we
need to find a way to use this:
- For methods which use git tools on both ends (git-clone-pack,
git-ssh-pull, git-daemon) we could just create pipes to gzip/gunzip
in the appropriate places.
- For non-git-aware methods (rsync, http) we still can use these
improvements, but there are additional complications because of the
pack index file. We could have globally-compressed pack files in a
separate directory together with their index files, and write an
utility which will take a pack file with its index, recompress all
objects and produce a pack file with compressed objects and new
index. In theory, we could reconstruct the index from just the pack
file alone, but this procedure may be expensive (it will need to
reconstruct all objects represented by deltas to find their hash
values).
BTW, it could be possible to improve the global compression even more
by optimizing the order of objects in the pack file (currently trees
and blobs seems to be intermixed). I did not try this yet, however.
--
Sergey Vlasov
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCHSET] Cogito documentation updates
From: Jonas Fonseca @ 2005-08-13 16:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
The patchset contains the following 5 patches:
[PATCH 1/5] Also install cg-*.txt files
[PATCH 2/5] Add SEE ALSO section to cogito(7) which mentions git(7)
[PATCH 3/5] Generate Documentation/introduction.html from the README file
[PATCH 4/5] Add more AsciiDoc markup to the README file
[PATCH 5/5] Ignore patch backup files (*.{orig,rej}) when finding cg-* manpage scripts
--
Jonas Fonseca
^ permalink raw reply
* [RFC] [PATCH] Add "--compression-level=N" option to git-pack-objects
From: Sergey Vlasov @ 2005-08-13 16:23 UTC (permalink / raw)
To: git
In-Reply-To: <20050813162242.GA11609@procyon.home>
[PATCH] Add "--compression-level=N" option to git-pack-objects
Setting the compression level for objects in the pack is useful in some
cases; in particular, disabling compression of the individual objects and
then compressing the whole pack can improve the overall compression ratio.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
Documentation/git-pack-objects.txt | 14 +++++++++++++-
csum-file.c | 5 +++--
csum-file.h | 2 +-
pack-objects.c | 15 +++++++++++++--
4 files changed, 30 insertions(+), 6 deletions(-)
e54e13c2f057e71998ed39299545717311c7678d
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -9,7 +9,7 @@ git-pack-objects - Create a packed archi
SYNOPSIS
--------
-'git-pack-objects' [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
+'git-pack-objects' [--incremental] [--window=N] [--depth=N] [--compression-level=N] {--stdout | base-name} < object-list
DESCRIPTION
@@ -61,6 +61,18 @@ base-name::
side, because delta data needs to be applied that many
times to get to the necessary object.
+--compression-level::
+ Set zlib compression level for the object data. The
+ compression level is a number from 0 to 9, where 0 means
+ no compression, 1 indicates the fastest compression
+ method (less compression), and 9 indicates the slowest
+ compression method (best compression). The default
+ compression level is 6. Setting the compression level
+ to 0 may be useful when the pack will be compressed as a
+ whole at a later stage (in the pack format every object
+ is compressed separately to allow random access, which
+ is less efficient than compressing the whole file).
+
--incremental::
This flag causes an object already in a pack ignored
even if it appears in the standard input.
diff --git a/csum-file.c b/csum-file.c
--- a/csum-file.c
+++ b/csum-file.c
@@ -117,14 +117,15 @@ struct sha1file *sha1fd(int fd, const ch
return f;
}
-int sha1write_compressed(struct sha1file *f, void *in, unsigned int size)
+int sha1write_compressed(struct sha1file *f, void *in, unsigned int size,
+ int compression_level)
{
z_stream stream;
unsigned long maxsize;
void *out;
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_DEFAULT_COMPRESSION);
+ deflateInit(&stream, compression_level);
maxsize = deflateBound(&stream, size);
out = xmalloc(maxsize);
diff --git a/csum-file.h b/csum-file.h
--- a/csum-file.h
+++ b/csum-file.h
@@ -14,6 +14,6 @@ extern struct sha1file *sha1fd(int fd, c
extern struct sha1file *sha1create(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern int sha1close(struct sha1file *, unsigned char *, int);
extern int sha1write(struct sha1file *, void *, unsigned int);
-extern int sha1write_compressed(struct sha1file *, void *, unsigned int);
+extern int sha1write_compressed(struct sha1file *, void *, unsigned int, int);
#endif
diff --git a/pack-objects.c b/pack-objects.c
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -5,7 +5,7 @@
#include "pack.h"
#include "csum-file.h"
-static const char pack_usage[] = "git-pack-objects [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
+static const char pack_usage[] = "git-pack-objects [--incremental] [--window=N] [--depth=N] [--compression-level=N] {--stdout | base-name} < object-list";
struct object_entry {
unsigned char sha1[20];
@@ -21,6 +21,7 @@ struct object_entry {
static unsigned char object_list_sha1[20];
static int non_empty = 0;
static int incremental = 0;
+static int compression_level = Z_DEFAULT_COMPRESSION;
static struct object_entry **sorted_by_sha, **sorted_by_type;
static struct object_entry *objects = NULL;
static int nr_objects = 0, nr_alloc = 0;
@@ -103,7 +104,7 @@ static unsigned long write_object(struct
sha1write(f, entry->delta, 20);
hdrlen += 20;
}
- datalen = sha1write_compressed(f, buf, size);
+ datalen = sha1write_compressed(f, buf, size, compression_level);
free(buf);
return hdrlen + datalen;
}
@@ -421,6 +422,16 @@ int main(int argc, char **argv)
usage(pack_usage);
continue;
}
+ if (!strncmp("--compression-level=", arg, 20)) {
+ char *end;
+ compression_level = strtoul(arg+20, &end, 0);
+ if (!arg[20] || *end)
+ usage(pack_usage);
+ if (compression_level < Z_NO_COMPRESSION
+ || compression_level > Z_BEST_COMPRESSION)
+ die("invalid compression level");
+ continue;
+ }
if (!strcmp("--stdout", arg)) {
pack_to_stdout = 1;
continue;
^ permalink raw reply
* [PATCH 1/5] Also install cg-*.txt files
From: Jonas Fonseca @ 2005-08-13 16:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813162352.GA968@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
debian/rules | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -67,6 +67,7 @@ install: build
$(MAKE) install DESTDIR=$(CURDIR)/debian/cogito prefix=/usr
# $(RM) $(DESTDIR)/usr/bin/cg
install -m 0644 Documentation/*.html $(DESTDIR)/usr/share/doc/cogito/html
+ install -m 0644 Documentation/cg-*.txt $(DESTDIR)/usr/share/doc/cogito/txt
install -m 0644 Documentation/cogito.txt $(DESTDIR)/usr/share/doc/cogito/txt
install -m 0644 Documentation/*.1 $(DESTDIR)/usr/share/man/man1
install -m 0644 Documentation/*.7 $(DESTDIR)/usr/share/man/man7
--
Jonas Fonseca
^ permalink raw reply
* [PATCH 2/5] Add SEE ALSO section to cogito(7) which mentions git(7)
From: Jonas Fonseca @ 2005-08-13 16:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813162352.GA968@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/make-cogito-asciidoc | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/make-cogito-asciidoc b/Documentation/make-cogito-asciidoc
--- a/Documentation/make-cogito-asciidoc
+++ b/Documentation/make-cogito-asciidoc
@@ -157,4 +157,8 @@ FILES
COPYRIGHT
---------
Copyright (C) Petr Baudis, 2005.
+
+SEE ALSO
+--------
+Cogito is based on gitlink:git[7].
__END__
--
Jonas Fonseca
^ permalink raw reply
* [PATCH 3/5] Generate Documentation/introduction.html from the README file
From: Jonas Fonseca @ 2005-08-13 16:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813162352.GA968@diku.dk>
Convert section names to use AsciiDoc markup. Fix a typo and refer to the
cg-* manpages.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 5 ++++-
README | 36 ++++++++++++++++++++++++------------
2 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -4,7 +4,7 @@ CG_SRC=$(filter-out $(CG_IGNORE), $(wild
MAN1_TXT=$(patsubst ../cg-%,cg-%.txt,$(CG_SRC))
MAN7_TXT=cogito.txt
-DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) introduction.html
DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
@@ -54,6 +54,9 @@ clean:
.PRECIOUS: %.txt
+introduction.html: ../README
+ asciidoc -b xhtml11 -d article -f asciidoc.conf -o $@ $<
+
%.html : %.txt
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
diff --git a/README b/README
--- a/README
+++ b/README
@@ -1,5 +1,5 @@
- The Cogito Version Control System
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The Cogito Version Control System
+=================================
Cogito is a version control system layered on top of the git tree history
storage system. Note that you can MOSTLY use it in parallel of other GIT
@@ -13,7 +13,8 @@ We shall first describe some quick ways
over each available command one by one.
- Downloading Cogito From Scratch
+Downloading Cogito From Scratch
+-------------------------------
Cogito can be obtained as a tarball from
@@ -39,13 +40,15 @@ The following tools are optional but str
preferred over the BSD variants)
- Starting a Fresh GIT Repository
+Starting a Fresh GIT Repository
+-------------------------------
If you want to start your own project using Cogito, there are two basic ways
to do this. You may start a fresh repository with no files in it, or you may
take an existing directory tree and turn it into a GIT repository.
- Starting an Empty Repository
+Starting an Empty Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To create a new repository with no files in it, cd into an empty directory,
and give the following command:
@@ -59,7 +62,8 @@ That's it! You're now in your own GIT re
directory. Go into it and look around, but don't change anything in there.
That's what Cogito commands are for.
- Turning an Existing Directory Into a Repository
+Turning an Existing Directory Into a Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you have a directory full of files, you can easily turn this into a
GIT repository. In fact, it is virtually the same as starting an empty
@@ -73,9 +77,11 @@ editor, and you're good to go. All of th
directory are now part of a GIT archive.
- Accessing Someone Else's GIT Repository
+Accessing Someone Else's GIT Repository
+---------------------------------------
- Creating the Repository
+Creating the Repository
+~~~~~~~~~~~~~~~~~~~~~~~
If you want to get started tracking an outside GIT repository, you first
must have Cogito's executables on your $PATH. Next, you need the URL (or
@@ -114,7 +120,8 @@ When you get your prompt back, do an ls
directory.
- Tracking Others' Work
+Tracking Others' Work
+~~~~~~~~~~~~~~~~~~~~~
Of course, once you have cloned a repository, you don't just want to leave
it at that. The upstream sources are constantly being updated, and you want
@@ -170,7 +177,8 @@ since your cg-pull. The alternative and
the cg-merge command, which we shall describe later.
- Other Stuff
+Other Stuff
+~~~~~~~~~~~
If there are any changes, two IDs will be printed (I mean the line saying
"Tree change"). Pass those as parameters to cg-diff and you will get a diff
@@ -222,10 +230,11 @@ Note that we missed out a lot of stuff h
for merging (cg-merge), moving your tree to an older commit (cg-seek), etc.
- Getting Help
+Getting Help
+------------
Cogito commands come with their own helpful documentation. To get help on
-cg-update, for example, give this command:
+cg-pull, for example, give this command:
$ cg-pull --help
@@ -233,6 +242,9 @@ or, for the same information, try this:
$ cg-help cg-pull
+Additionally, the man pages for the individual commands can be used as a
+reference.
+
You can ask thoughtful questions and make suggestions on the GIT mailing list:
git@vger.kernel.org
--
Jonas Fonseca
^ permalink raw reply
* [PATCH 4/5] Add more AsciiDoc markup to the README file
From: Jonas Fonseca @ 2005-08-13 16:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813162352.GA968@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
I've separated these because they make the README file less readable.
Pick the ones you like, and I will make a new patch.
README | 76 ++++++++++++++++++++++++++++++++++++----------------------------
1 files changed, 43 insertions(+), 33 deletions(-)
diff --git a/README b/README
--- a/README
+++ b/README
@@ -2,10 +2,10 @@ The Cogito Version Control System
=================================
Cogito is a version control system layered on top of the git tree history
-storage system. Note that you can MOSTLY use it in parallel of other GIT
+storage system. Note that you can *MOSTLY* use it in parallel of other GIT
frontends (e.g. StGIT), as well as the Linus' GIT plumbing and core GIT
tools - they only need to keep HEAD in place and follow the standardized
-refs/ hierarchy. The exception is that you should stick with a single
+`refs/` hierarchy. The exception is that you should stick with a single
toolkit during a merge and mostly stick with Cogito while your tree is
in cg-seek'd state.
@@ -18,27 +18,36 @@ Downloading Cogito From Scratch
Cogito can be obtained as a tarball from
- http://www.kernel.org/pub/software/scm/cogito/
+ - http://www.kernel.org/pub/software/scm/cogito/[]
Download and unpack the latest version, build with make, put the executables
-somewhere in your $PATH (or add your Cogito directory itself to your $PATH),
+somewhere in your `$PATH` (or add your Cogito directory itself to your `$PATH`),
and you're ready to go!
The following tools are required by Cogito:
- git-core (Cogito is a frontend for git)
- bash, basic shell environment (sed, grep, textutils, mktemp, ...)
- diff, patch
- merge (e.g. from the RCS package)
- wget
+`-------------------------------`----------------------------------------------
+Tool Description
+-------------------------------------------------------------------------------
+git-core Cogito is a frontend for git.
+bash All Cogito executables are scripted in bash.
+sed, grep, textutils, etc. The basic shell environment.
+diff, patch The basic utilities for tracking file changes.
+merge E.g. from the RCS package.
+wget For pulling files with the HTTP backend.
+-------------------------------------------------------------------------------
The following tools are optional but strongly recommended:
- libcrypto (OpenSSL)
- rsync
- gnu coreutils (the gnu versions of stat, date and cp are
- preferred over the BSD variants)
-
+`-------------------------------`----------------------------------------------
+Tool Description
+-------------------------------------------------------------------------------
+rsync For pulling files with the rsync backend.
+gnu coreutils The gnu versions of stat, date and cp \
+ are preferred over the BSD variants.
+ssh For pulling files with the git+ssh backend.
+asciidoc (>= 7.0), xmlto For building documentation.
+-------------------------------------------------------------------------------
Starting a Fresh GIT Repository
-------------------------------
@@ -50,7 +60,7 @@ take an existing directory tree and turn
Starting an Empty Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To create a new repository with no files in it, cd into an empty directory,
+To create a new repository with no files in it, `cd` into an empty directory,
and give the following command:
$ cg-init
@@ -58,7 +68,7 @@ and give the following command:
Your editor will start up, and you will be asked to type in the initial
commit description. Type something cute, and exit your editor.
-That's it! You're now in your own GIT repository. Notice there is now a .git
+That's it! You're now in your own GIT repository. Notice there is now a `.git`
directory. Go into it and look around, but don't change anything in there.
That's what Cogito commands are for.
@@ -67,7 +77,7 @@ Turning an Existing Directory Into a Rep
If you have a directory full of files, you can easily turn this into a
GIT repository. In fact, it is virtually the same as starting an empty
-repository. Just cd into the directory you want converted into a GIT
+repository. Just `cd` into the directory you want converted into a GIT
repository, and give the following command:
$ cg-init
@@ -84,16 +94,16 @@ Creating the Repository
~~~~~~~~~~~~~~~~~~~~~~~
If you want to get started tracking an outside GIT repository, you first
-must have Cogito's executables on your $PATH. Next, you need the URL (or
+must have Cogito's executables on your `$PATH`. Next, you need the URL (or
local directory path) of the repository you want to track. You can't just
use the URL of a tarball, like the one given above for the Cogito source.
-The URL must point specifically to a .git directory somewhere. For instance,
+The URL must point specifically to a `.git` directory somewhere. For instance,
the URL for Cogito's self-hosting repository is
http://www.kernel.org/pub/scm/cogito/cogito.git
-Notice that the final directory, 'cogito.git', is not called '.git'. That is
-fine. It still has the same content as your .git directory.
+Notice that the final directory, `cogito.git`, is not called `.git`. That is
+fine. It still has the same content as your `.git` directory.
To clone the repository to your local filesystem, use the cg-clone command.
cg-clone can be told to create a new directory for your repository, or to
@@ -107,8 +117,8 @@ new directory be called, as follows:
You will see a whole bunch of output, and when it is over there will be a
new directory called 'cogitodir' (or whatever name you chose) in the current
-directory. cd into it. Because we used the Cogito URL, you will see the
-Cogito source tree, with its own .git directory keeping track of everything.
+directory. `cd` into it. Because we used the Cogito URL, you will see the
+Cogito source tree, with its own `.git` directory keeping track of everything.
If, instead, you want to clone the repository to the current directory,
first make sure you are in an empty directory. Then give the following
@@ -116,7 +126,7 @@ command:
$ cg-clone -s http://www.kernel.org/pub/scm/cogito/cogito.git
-When you get your prompt back, do an ls to see the source tree and .git
+When you get your prompt back, do an ls to see the source tree and `.git`
directory.
@@ -125,14 +135,14 @@ Tracking Others' Work
Of course, once you have cloned a repository, you don't just want to leave
it at that. The upstream sources are constantly being updated, and you want
-to follow these updates. To do this, cd into the working tree directory (not
-the .git directory, but the directory that contains the .git directory), and
+to follow these updates. To do this, `cd` into the working tree directory (not
+the `.git` directory, but the directory that contains the `.git` directory), and
give the following command:
$ cg-update
You don't use a URL anymore. Cogito knows which tree you're tracking, because
-this information is stored in the .git directory. The above command will track
+this information is stored in the `.git` directory. The above command will track
the 'origin' branch, which represents the repository you originally cloned.
But cg-update can also be used to track specific branches. See below for more
discussion of branches, and how to track them.
@@ -141,11 +151,11 @@ When you give the above cg-update comman
First, it pulled all new changes from the upstream repository into your
local repository. At that point, the changes exist in your local repository
as part of the project history. The changes themselves are not actually
-visible in the files you see, but reside in the .git directory's awareness,
+visible in the files you see, but reside in the `.git` directory's awareness,
just downloaded and ready to be merged somewhere. The second thing cg-update
does is to merge these changes into the files you see and work with. The end
result is that, when the cg-update has finished, you will see all the upstream
-changes reflected in your local files, and the .git directory will be aware
+changes reflected in your local files, and the `.git` directory will be aware
of the history of those changes as well.
It may be that you want to be aware of the history of the upstream work, but
@@ -155,14 +165,14 @@ this, give the following command:
$ cg-pull
This does the first part of cg-update's job, but skips the second part.
-Now your local files have not been changed, but your .git directory has been
+Now your local files have not been changed, but your `.git` directory has been
updated with the history of all the changes that have occurred in the
upstream sources.
Using cg-pull is useful for a variety of purposes, for instance if you want
to construct a diff against the latest version of the upstream sources, but
don't want those changes to disturb your ongoing work. cg-pull will update
-your .git directory with the history you need to construct your diff,
+your `.git` directory with the history you need to construct your diff,
without merging that history into your tree, potentially breaking your
changes.
@@ -196,7 +206,7 @@ the command
(the repourl can have a fragment part identifying a branch inside of the
repository). Then you can specify the name to cg-update and cg-pull, or use
-it anywhere where you could use the "origin" name.
+it anywhere where you could use the 'origin' name.
When you do some local changes, you can do
@@ -224,7 +234,7 @@ It is nice to be able to examine the com
$ cg-log -r origin
will get you the history of my branch. cg-log with no arguments will default
-to the history of the current branch. Try prepending the "-c" and "-f" options.
+to the history of the current branch. Try prepending the `-c` and `-f` options.
Note that we missed out a lot of stuff here. There is already support
for merging (cg-merge), moving your tree to an older commit (cg-seek), etc.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH 5/5] Ignore patch backup files when finding cg-* manpage scripts
From: Jonas Fonseca @ 2005-08-13 16:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813162352.GA968@diku.dk>
Adds ../cg-*.{orig,rej} to CG_IGNORE.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,4 +1,4 @@
-CG_IGNORE=$(wildcard ../cg-X*)
+CG_IGNORE=$(wildcard ../cg-X* ../cg-*.orig ../cg-*.rej)
CG_SRC=$(filter-out $(CG_IGNORE), $(wildcard ../cg-*))
MAN1_TXT=$(patsubst ../cg-%,cg-%.txt,$(CG_SRC))
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Linus Torvalds @ 2005-08-13 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, Johannes Schindelin, git
In-Reply-To: <7v64uaqknh.fsf@assigned-by-dhcp.cox.net>
On Sat, 13 Aug 2005, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
> > See, for example, the history on git-rename-script for why this is good.
>
> Why do you think it is a good example? What happens when next
> time somebody rewrites it in C?
We'll call the C version "rename.c", and the program gets to be called
"git-rename", and "git rename" continues to work perfectly fine, so users
won't be affected in the least.
And "grep ... *.c" and "grep ... *-script" also still work right.
That sounds like a good outcome to me.
Linus
^ permalink raw reply
* [HUP] Pulling broken by late Cogito commits
From: Petr Baudis @ 2005-08-13 17:13 UTC (permalink / raw)
To: git
Hi,
if you are following Cogito development closely, please note that
pulling over HTTP and SSH was broken by a late Cogito commit (74b4f7).
This also means that you won't be able to pull the fix (which I just
committed and might take a short while to mirror out) if you pull Cogito
over HTTP.
cg-pull and cg-update will print the new commit ID on stdout, like:
Tree change:
ce471851ee8b6147ac57b211d9d76c3e4d625598:75d9f4a22abefd561147f88be9b7eb81af420f1b
The second ID (75d9f4a22abefd561147f88be9b7eb81af420f1b) is the new
commit - but it won't get saved and therefore merged. You need to do
that manually; e.g. if the stock Cogito is the origin branch (the usual
setup), do this:
echo 75d9f4a22abefd561147f88be9b7eb81af420f1b >.git/refs/heads/origin
Then run cg-merge or rerun cg-update.
Sorry for any inconvenience,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Add an empty directory?
From: Carl Baldwin @ 2005-08-13 17:30 UTC (permalink / raw)
To: git
Greetings,
My appologies if this has already been discussed. I've been through the
archives but could easily have missed something.
I have found it useful in the past to have the ability to add an empty
directory to the repository. With what little I know about git it seems
that this is entirely possible. It would create an empty tree object
for the new directory and insert a reference to that in the parent tree
object.
If someone could get me started I think I could find the time to create
and submit a patch to allow this. Here is what I've tried (with
0.99.4).
% mkdir test
% cd test
% git-init-db
% mkdir dir
% git-add-script dir
error: open("dir"): No such file or directory
fatal: Unable to add dir to database
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Add an empty directory?
From: Petr Baudis @ 2005-08-13 18:00 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050813173043.GA25013@hpsvcnb.fc.hp.com>
Dear diary, on Sat, Aug 13, 2005 at 07:30:43PM CEST, I got a letter
where Carl Baldwin <cnb@fc.hp.com> told me that...
> Greetings,
Hi,
> My appologies if this has already been discussed. I've been through the
> archives but could easily have missed something.
>
> I have found it useful in the past to have the ability to add an empty
> directory to the repository. With what little I know about git it seems
> that this is entirely possible. It would create an empty tree object
> for the new directory and insert a reference to that in the parent tree
> object.
>
> If someone could get me started I think I could find the time to create
> and submit a patch to allow this. Here is what I've tried (with
> 0.99.4).
>
> % mkdir test
> % cd test
> % git-init-db
> % mkdir dir
> % git-add-script dir
> error: open("dir"): No such file or directory
> fatal: Unable to add dir to database
the object databases supports it, but the index file does not. But yes,
it should be supported, I think.
Some argue that this is useless, so some practical example of its
usefulness might be a good motivation to get us going. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: git/cogito workshop/bof at linuxconf au?
From: Linus Torvalds @ 2005-08-13 18:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f90508130034858ad34@mail.gmail.com>
On Sat, 13 Aug 2005, Martin Langhoff wrote:
>
> Anyone coming to Linuxconf.au 2006? It'll will be in Dunedin NZ and
> I'd be really keen on joining a git/cogito workshop or bof.
I was planning to be there. I like lca, but passed it over this year
because of it being in Canberra (I'm sure it's a nice city to live in, but
it's not a very exciting one, and I've been there several times before ;)
> I would gladly try and organize a workshop, but I am far from fluent
> with git, so I won't go at it alone. Any takers? Call for papers ends
> 5th September, not too far ahead. We have to register our interest
> _now_.
I'm no good with papers, though. One of the reasons I decided to leave the
university lifestyle was that I hate writing papers. That's
anti-conductive to being at a uni ;)
Linus
^ permalink raw reply
* Re: Add an empty directory?
From: Carl Baldwin @ 2005-08-13 18:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Baldwin, git
In-Reply-To: <20050813180008.GJ5608@pasky.ji.cz>
Hi,
On Sat, Aug 13, 2005 at 08:00:08PM +0200, Petr Baudis wrote:
> the object databases supports it, but the index file does not. But yes,
> it should be supported, I think.
>
> Some argue that this is useless, so some practical example of its
> usefulness might be a good motivation to get us going. :-)
That's fair. So, here goes. I don't particularly condone nor condemn
any of these.
- Just yesterday, I was starting a project at work. I wanted to add a
doc directory as a reminder to add documentation very soon. I could
not do this.
- I've worked with projects that use an obj, .obj, .obj-platform or
something resembling this and have checked in this directory to make
sure it exists for all. Of course, a build system could be made to
generate this directory when needed avoiding the need to check it in.
- A common practice I've seen with autotools is to use a config
subdirectory for many of the autogenerated scripts. If I'm not
mistaken older versions would not create this directory if it did not
already exist. Checking it in was a convenience.
The bottom line is that I don't really see many situations where it is
absolutely necessary but it is a convenience. Not supporting it may
seem like an artificial limit that really didn't need to be there.
I'll read up on the index file when I get the chance.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Junio C Hamano @ 2005-08-13 18:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813120815.GC5608@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> What about calling it rather info/alternates (or info/alternate)? It
> looks better, sounds better, is more namespace-ecological tab-completes
> fine and you don't type it that often anyway. :-)
Thanks for the suggestion. Will fix and keep it in the pu
branch for now just in case somebody else suggests a name even
better.
^ permalink raw reply
* Re: [PATCH] Added hook in git-receive-pack
From: Josef Weidendorfer @ 2005-08-13 18:31 UTC (permalink / raw)
To: git
In-Reply-To: <200507312117.43957.Josef.Weidendorfer@gmx.de>
On Sunday 31 July 2005 21:17, Josef Weidendorfer wrote:
> Added hook in git-receive-pack
Regarding the update hook:
In this script, it would be nice to be able to distinguish rebasing/forced
setting of a head from a regular fast forwarding. In the first case, I do not
want to potentially send a list of all commits starting from project root,
which currently can happen.
A solution would be to call the hook simply with
update refname new_sha1
if this is not a fast forward.
The question is if there is a use case for the script to get the old_sha1 even
in a rebase situation. So another option would be to call the script with
update action refname old_sha1 new_sha1
with action being "fastforward" or "forcedrebase" or similar.
Or is there already an easy way to detect the fast-forward situation in the
script?
Josef
^ permalink raw reply
* Re: [PATCH] Added hook in git-receive-pack
From: Junio C Hamano @ 2005-08-13 19:27 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508132031.27668.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Or is there already an easy way to detect the fast-forward situation in the
> script?
Since you are given old and new, presumably you can do
merge-base in the hook to see what it yields?
^ permalink raw reply
* Re: [patch] possible memory leak in diff.c::diff_free_filepair()
From: Junio C Hamano @ 2005-08-13 19:30 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87y876gl1r.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> When I run git-diff-tree on big change, it seems the command eats so
> much memory. so I just put git under valgrind to see what's going on.
>
> diff_free_filespec_data() doesn't free diff_filespec itself. is this
> because in merge_broken() filespec itself is used but fliespec data
> need to be freed?
Thanks for the patch. I am wondering if the same leak exists in
diff_free_filepair(), which frees the filespec data without
freeing filespec itself for both sides. If this is something
you can trap easily with valgrind I would really appreciate it.
^ permalink raw reply
* Re: Add an empty directory?
From: Junio C Hamano @ 2005-08-13 19:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813180008.GJ5608@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> the object databases supports it, but the index file does not. But yes,
> it should be supported, I think.
I think if this is done correctly "read-tree -m -u" two-tree
switch could even remove directories that existed in the old
tree but not in the new tree that has become empty.
On the other hand, although I haven't started looking, adding
this to index file might involve a major surgery. Practically
everybody expects it is does not have an directory entry. This
includes reading trees, merging two or more stages, finding
directory/file conflicts, etc. etc...
^ 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