* Re: Git 1.3.2 on Solaris
From: Jason Riedy @ 2006-05-23 18:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605230744350.5623@g5.osdl.org>
And Linus Torvalds writes:
-
- What kind of CRAP has Solaris become?
Become? heh. Check mount's output; it's "mountpoint
on device". Always has been. I think there might be
a reason why certain other OSes have eaten their lunch,
and it ain't the price.
- It wasn't about what was "allowed by the standards",
- that was the HP-SUX and AIX's excuses.
No, AIX's excuse is that it's "dictated by these three
standards over here and disallowed by those two, so
clearly we have to support both behaviors depending
on some footnote in our 1e9 page manual." wheee...
- Have Sun people forgotten the difference between "quality" and "crap that
- passes standards tests"?
As far as I've been told, Sun's more interested in
near-perfect backwards compatibility than external
standards tests. It worked for Intel, right? ;)
- Btw, even SuS says:
[...]
- New implementations are discouraged from returning X_OK unless at
- least one execution permission bit is set."
Now there is one possible, cross-OS problem that I
haven't tested. You can chmod a-x and then use
setfacl to grant one person execute access. I'm not
sure if access works in that case, but that might
possibly just say that current ACL systems are crap.
Hmm. Does access handle SELinux or the other systems?
That might be interesting for a public git server, but
I don't know enough about it.
- Somebody hit some Solaris engineers with a 2x4 clue-stick, please.
I think you're targetting the wrong department...
Their hands are tied.
Jason, wondering if you could resist the SUS bait...
^ permalink raw reply
* [PATCH 1/2] Again: remove the artificial restriction tagsize < 8kb
From: Björn Engelmann @ 2006-05-23 18:19 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-remove-the-artificial-restriction-tagsize-8kb.txt --]
[-- Type: text/plain, Size: 4182 bytes --]
Signed-off-by: Björn Engelmann <BjEngelmann@gmx.de>
---
430953ceafbc722226e2300b489e38938220d435
cache.h | 1 +
mktag.c | 19 +++++++++----------
sha1_file.c | 46 ++++++++++++++++++++++++++++++++++++----------
3 files changed, 46 insertions(+), 20 deletions(-)
430953ceafbc722226e2300b489e38938220d435
diff --git a/cache.h b/cache.h
index 4b7a439..19e90eb 100644
--- a/cache.h
+++ b/cache.h
@@ -154,6 +154,7 @@ extern int ce_match_stat(struct cache_en
extern int ce_modified(struct cache_entry *ce, struct stat *st, int);
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type);
+extern int read_pipe(int fd, char** return_buf, unsigned long* return_size);
extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
diff --git a/mktag.c b/mktag.c
index 2328878..f1598db 100644
--- a/mktag.c
+++ b/mktag.c
@@ -45,7 +45,7 @@ static int verify_tag(char *buffer, unsi
unsigned char sha1[20];
const char *object, *type_line, *tag_line, *tagger_line;
- if (size < 64 || size > MAXSIZE-1)
+ if (size < 64)
return -1;
buffer[size] = 0;
@@ -105,8 +105,8 @@ static int verify_tag(char *buffer, unsi
int main(int argc, char **argv)
{
- unsigned long size;
- char buffer[MAXSIZE];
+ unsigned long size = 4096;
+ char *buffer = malloc(size);
unsigned char result_sha1[20];
if (argc != 1)
@@ -114,13 +114,9 @@ int main(int argc, char **argv)
setup_git_directory();
- // Read the signature
- size = 0;
- for (;;) {
- int ret = xread(0, buffer + size, MAXSIZE - size);
- if (ret <= 0)
- break;
- size += ret;
+ if (read_pipe(0, &buffer, &size)) {
+ free(buffer);
+ die("could not read from stdin");
}
// Verify it for some basic sanity: it needs to start with "object <sha1>\ntype\ntagger "
@@ -129,6 +125,9 @@ int main(int argc, char **argv)
if (write_sha1_file(buffer, size, tag_type, result_sha1) < 0)
die("unable to write tag file");
+
+ free(buffer);
+
printf("%s\n", sha1_to_hex(result_sha1));
return 0;
}
diff --git a/sha1_file.c b/sha1_file.c
index 2230010..e444d9d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1645,16 +1645,24 @@ int has_sha1_file(const unsigned char *s
return find_sha1_file(sha1, &st) ? 1 : 0;
}
-int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
+/*
+ * reads from fd as long as possible into a supplied buffer of size bytes.
+ * If neccessary the buffer's size is increased using realloc()
+ *
+ * returns 0 if anything went fine and -1 otherwise
+ *
+ * NOTE: both buf and size may change, but even when -1 is returned
+ * you still have to free() it yourself.
+ */
+int read_pipe(int fd, char** return_buf, unsigned long* return_size)
{
- unsigned long size = 4096;
- char *buf = malloc(size);
- int iret, ret;
+ char* buf = *return_buf;
+ unsigned long size = *return_size;
+ int iret;
unsigned long off = 0;
- unsigned char hdr[50];
- int hdrlen;
+
do {
- iret = read(fd, buf + off, size - off);
+ iret = xread(fd, buf + off, size - off);
if (iret > 0) {
off += iret;
if (off == size) {
@@ -1663,16 +1671,34 @@ int index_pipe(unsigned char *sha1, int
}
}
} while (iret > 0);
- if (iret < 0) {
+
+ *return_buf = buf;
+ *return_size = off;
+
+ if (iret < 0)
+ return -1;
+ return 0;
+}
+
+int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
+{
+ unsigned long size = 4096;
+ char *buf = malloc(size);
+ int ret;
+ unsigned char hdr[50];
+ int hdrlen;
+
+ if (read_pipe(fd, &buf, &size)) {
free(buf);
return -1;
}
+
if (!type)
type = blob_type;
if (write_object)
- ret = write_sha1_file(buf, off, type, sha1);
+ ret = write_sha1_file(buf, size, type, sha1);
else {
- write_sha1_file_prepare(buf, off, type, sha1, hdr, &hdrlen);
+ write_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);
ret = 0;
}
free(buf);
--
1.3.3.g4309-dirty
^ permalink raw reply related
* [PATCH 2/2] Again: add more informative error messages to git-mktag
From: Björn Engelmann @ 2006-05-23 18:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0002-add-more-informative-error-messages-to-git-mktag.txt --]
[-- Type: text/plain, Size: 2838 bytes --]
Signed-off-by: Björn Engelmann <BjEngelmann@gmx.de>
---
51465a979a25c4363010cbab5798d95ac9f102e7
mktag.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
51465a979a25c4363010cbab5798d95ac9f102e7
diff --git a/mktag.c b/mktag.c
index f1598db..6bd45df 100644
--- a/mktag.c
+++ b/mktag.c
@@ -46,41 +46,45 @@ static int verify_tag(char *buffer, unsi
const char *object, *type_line, *tag_line, *tagger_line;
if (size < 64)
- return -1;
+ return error("wanna fool me ? you obviously got the size wrong !\n");
+
buffer[size] = 0;
/* Verify object line */
object = buffer;
if (memcmp(object, "object ", 7))
- return -1;
+ return error("char%d: does not start with \"object \"\n", 0);
+
if (get_sha1_hex(object + 7, sha1))
- return -1;
+ return error("char%d: could not get SHA1 hash\n", 7);
/* Verify type line */
type_line = object + 48;
if (memcmp(type_line - 1, "\ntype ", 6))
- return -1;
+ return error("char%d: could not find \"\\ntype \"\n", 47);
/* Verify tag-line */
tag_line = strchr(type_line, '\n');
if (!tag_line)
- return -1;
+ return error("char%td: could not find next \"\\n\"\n", type_line - buffer);
tag_line++;
if (memcmp(tag_line, "tag ", 4) || tag_line[4] == '\n')
- return -1;
+ return error("char%td: no \"tag \" found\n", tag_line - buffer);
/* Get the actual type */
typelen = tag_line - type_line - strlen("type \n");
if (typelen >= sizeof(type))
- return -1;
+ return error("char%d: type too long\n", (int)(type_line - buffer) + strlen("type \n"));
+
memcpy(type, type_line+5, typelen);
type[typelen] = 0;
/* Verify that the object matches */
if (get_sha1_hex(object + 7, sha1))
- return -1;
+ return error("char%d: could not get SHA1 hash but this is really odd since i got it before !\n", 7);
+
if (verify_object(sha1, type))
- return -1;
+ return error("char%d: could not verify object %s\n", 7, sha1);
/* Verify the tag-name: we don't allow control characters or spaces in it */
tag_line += 4;
@@ -90,14 +94,14 @@ static int verify_tag(char *buffer, unsi
break;
if (c > ' ')
continue;
- return -1;
+ return error("char%td: could not verify tag name\n", tag_line - buffer);
}
/* Verify the tagger line */
tagger_line = tag_line;
if (memcmp(tagger_line, "tagger", 6) || (tagger_line[6] == '\n'))
- return -1;
+ return error("char%td: could not find \"tagger\"\n", tagger_line - buffer);
/* The actual stuff afterwards we don't care about.. */
return 0;
@@ -118,7 +122,7 @@ int main(int argc, char **argv)
free(buffer);
die("could not read from stdin");
}
-
+
// Verify it for some basic sanity: it needs to start with "object <sha1>\ntype\ntagger "
if (verify_tag(buffer, size) < 0)
die("invalid tag signature file");
--
1.3.3.g4309-dirty
^ permalink raw reply related
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-23 18:24 UTC (permalink / raw)
To: Jason Riedy; +Cc: Git Mailing List
In-Reply-To: <19270.1148407414@lotus.CS.Berkeley.EDU>
On Tue, 23 May 2006, Jason Riedy wrote:
>
> - Btw, even SuS says:
> [...]
> - New implementations are discouraged from returning X_OK unless at
> - least one execution permission bit is set."
>
> Now there is one possible, cross-OS problem that I
> haven't tested. You can chmod a-x and then use
> setfacl to grant one person execute access. I'm not
> sure if access works in that case, but that might
> possibly just say that current ACL systems are crap.
I absolutely agree. That is why the OS has a "access()" system call. It's
there to ask the OS whether the file is executable (or readable/writable).
Otherwise, we'd just do
static inline int executable(const char *path)
{
struct stat st;
return !stat(pathname, &st) &&
S_ISREG(st.st_mode) &&
(st.st_mode & 0111) != 0;
}
and be done with it. But exactly because the OS knows what "executable"
means, we ask it. We don't know about all the ACL's etc, the OS does.
(Similar issues are true for writability too - the file may be "writable"
in the sense that the write permission bits are on, but if the filesystem
is mounted read-only, it sure as hell ain't W_OK _anyway_).
> Hmm. Does access handle SELinux or the other systems?
Yup.
Modulo bugs, of course, but yes, access() on linux should check both
POSIX ACL's and SELinux security extensions. It uses exactly the same
code-paths that open()/execve() does: it uses the "vfs_permission()"
function which is also what execve() uses.
Now, I think access() actually misses a no-exec mount (it doesn't seem to
check MNT_NOEXEC for X_OK), and that looks like it might actually be a
real bug.
Linus
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Edgar Toernig @ 2006-05-23 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jason Riedy, Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605230829020.5623@g5.osdl.org>
Linus Torvalds wrote:
>
> [ And how the heck does anybody still run 2.0, btw? ]
Why not? There was never the need for an upgrade.
All connected hardware is well supported. Sure,
there are no binary packages for it and you have to
compile from sources but most apps can be made to
run on it (on the way you learn to hate autoconf).
And I wish the 2.6 system were as reliable as the
2.0 one ...
Ciao, ET.
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-23 18:48 UTC (permalink / raw)
To: Jason Riedy; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605231110230.5623@g5.osdl.org>
On Tue, 23 May 2006, Linus Torvalds wrote:
>
> I absolutely agree. That is why the OS has a "access()" system call. It's
> there to ask the OS whether the file is executable (or readable/writable).
Side note: I'm not claiming that "access()" is a wonderful thing. I do
agree that we might want to replace it with something else inside of git,
if only because of portability concerns.
So I'm really just ranting my normal "standards lawyerese doesn't mean
much" rant..
(access() also has other isses: X_OK obviously means different things for
directories and for regular files, so quite often you need to do a stat()
on the thing _anyway_ just to determine whether it's "executable in the
'execve()' sense" or "executable in the 'path lookup' sense").
Linus
^ permalink raw reply
* Re: [PATCH] Avoid segfault in diff --stat rename output.
From: Torgil Svensson @ 2006-05-23 19:06 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP115C9137E5BDABD705881BAE9B0@CEZ.ICE>
This patch fixed the issue for me.
On 5/23/06, Sean <seanlkml@sympatico.ca> wrote:
>
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> ---
> diff.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> On Tue, 23 May 2006 01:09:43 +0200
> "Torgil Svensson" <torgil.svensson@gmail.com> wrote:
>
> > Hi
> >
> > It seems like git-diff-tree has some problems with moved files:
> >
> > $ git-diff-tree -p --stat --summary -M
> > 348f179e3195448cea49c98a79cce8c7f446ce26
> > 343ca16424ba031b37e4df49afddaee098a8f347 | wc -l
> > *** glibc detected *** free(): invalid pointer: 0x12ecbbf0 ***
> > 6101
>
>
> diff --git a/diff.c b/diff.c
> index 7f35e59..a7bb9b9 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -237,7 +237,7 @@ static char *pprint_rename(const char *a
> if (a_midlen < 0) a_midlen = 0;
> if (b_midlen < 0) b_midlen = 0;
>
> - name = xmalloc(len_a + len_b - pfx_length - sfx_length + 7);
> + name = xmalloc(pfx_length + a_midlen + b_midlen + sfx_length + 7);
> sprintf(name, "%.*s{%.*s => %.*s}%s",
> pfx_length, a,
> a_midlen, a + pfx_length,
> --
> 1.3.GIT
>
>
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Linus Torvalds @ 2006-05-23 19:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.64.0605230948280.5623@g5.osdl.org>
On Tue, 23 May 2006, Linus Torvalds wrote:
>
> Hmm. Is it just me, or does the current "git cvsimport" have new problems:
>
> [torvalds@merom git]$ git cvsimport -d ~/CVS gentoo-x86
>
> causes
>
> Committing initial tree 34bd3dcd4bfd79bad35ce3fb08b2e21108195db8
> Server has gone away while fetching BUGS-TODO 1.1, retrying...
> Retry failed at /home/torvalds/bin/git-cvsimport line 366, <GEN2656> line 9.
>
> and that's it for the import.
>
> I don't see what would have caused it in the changes, but it definitely
> worked earlier..
Martin, that problem seems to go away when I initialize $res to 0 in
_fetchfile.
I don't know perl, and maybe local variables are pre-initialized to empty.
It's entirely possible that the fact that it now seems to work for me is
purely timing-related, since I also ended up using "-P cvsps-output" to
avoid having a huge cvsps binary in memory at the same time.
Linus "perl illiterate" Torvalds
^ permalink raw reply
* [PATCH 0/6] Detect non email patches in git-mailinfo
From: Eric W. Biederman @ 2006-05-23 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
After looking at a number of additional quit patches I noticed
a small problem with using the current git-mailinfo. On patches
with out any leading headers git-mailinfo can get confused and
loose a bit of information.
So far I have only seen this in the quilt from Andi Kleen but
it is fairly straight forward to fix.
What follows is a small patch series that one small step at
a time refactors (and I think simplifies) git-mailinfo
so that it can detect and cope with a file without any
email headers.
Eric
^ permalink raw reply
* [PATCH 1/6] Make read_one_header_line return a flag not a length.
From: Eric W. Biederman @ 2006-05-23 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <m18xosjznu.fsf@ebiederm.dsl.xmission.com>
Currently we only use the return value from read_one_header line
to tell if the line we have read is a header or not. So make
it a flag. This paves the way for better email detection.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
mailinfo.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
40f4ca44ec851e435ce9453c682c71b9c67063b9
diff --git a/mailinfo.c b/mailinfo.c
index b276519..83a2986 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -331,7 +331,7 @@ struct header_def {
int namelen;
};
-static void check_header(char *line, int len, struct header_def *header)
+static void check_header(char *line, struct header_def *header)
{
int i;
@@ -349,7 +349,7 @@ static void check_header(char *line, int
}
}
-static void check_subheader_line(char *line, int len)
+static void check_subheader_line(char *line)
{
static struct header_def header[] = {
{ "Content-Type", handle_subcontent_type },
@@ -357,9 +357,9 @@ static void check_subheader_line(char *l
handle_content_transfer_encoding },
{ NULL },
};
- check_header(line, len, header);
+ check_header(line, header);
}
-static void check_header_line(char *line, int len)
+static void check_header_line(char *line)
{
static struct header_def header[] = {
{ "From", handle_from },
@@ -370,7 +370,7 @@ static void check_header_line(char *line
handle_content_transfer_encoding },
{ NULL },
};
- check_header(line, len, header);
+ check_header(line, header);
}
static int read_one_header_line(char *line, int sz, FILE *in)
@@ -709,8 +709,8 @@ static void handle_multipart_body(void)
return;
/* We are on boundary line. Start slurping the subhead. */
while (1) {
- int len = read_one_header_line(line, sizeof(line), stdin);
- if (!len) {
+ int hdr = read_one_header_line(line, sizeof(line), stdin);
+ if (!hdr) {
if (handle_multipart_one_part() < 0)
return;
/* Reset per part headers */
@@ -718,7 +718,7 @@ static void handle_multipart_body(void)
charset[0] = 0;
}
else
- check_subheader_line(line, len);
+ check_subheader_line(line);
}
fclose(patchfile);
if (!patch_lines) {
@@ -787,15 +787,15 @@ int main(int argc, char **argv)
exit(1);
}
while (1) {
- int len = read_one_header_line(line, sizeof(line), stdin);
- if (!len) {
+ int hdr = read_one_header_line(line, sizeof(line), stdin);
+ if (!hdr) {
if (multipart_boundary[0])
handle_multipart_body();
else
handle_body();
break;
}
- check_header_line(line, len);
+ check_header_line(line);
}
return 0;
}
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* [PATCH 2/6] Move B and Q decoding into check header.
From: Eric W. Biederman @ 2006-05-23 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <m14pzgjzlg.fsf@ebiederm.dsl.xmission.com>
B and Q decoding is not appropriate for in body headers, so move
it up to where we explicitly know we have a real email header.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
mailinfo.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
3cccc5a0728a981cc6f4ea72e81513fd902e29a2
diff --git a/mailinfo.c b/mailinfo.c
index 83a2986..bee7b20 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -324,6 +324,7 @@ static void cleanup_space(char *buf)
}
}
+static void decode_header_bq(char *it);
typedef int (*header_fn_t)(char *);
struct header_def {
const char *name;
@@ -343,6 +344,10 @@ static void check_header(char *line, str
int len = header[i].namelen;
if (!strncasecmp(line, header[i].name, len) &&
line[len] == ':' && isspace(line[len + 1])) {
+ /* Unwrap inline B and Q encoding, and optionally
+ * normalize the meta information to utf8.
+ */
+ decode_header_bq(line + len + 2);
header[i].func(line + len + 2);
break;
}
@@ -597,13 +602,6 @@ static void handle_info(void)
cleanup_space(email);
cleanup_space(sub);
- /* Unwrap inline B and Q encoding, and optionally
- * normalize the meta information to utf8.
- */
- decode_header_bq(name);
- decode_header_bq(date);
- decode_header_bq(email);
- decode_header_bq(sub);
printf("Author: %s\nEmail: %s\nSubject: %s\nDate: %s\n\n",
name, email, sub, date);
}
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* [PATCH 3/6] Refactor commit messge handling.
From: Eric W. Biederman @ 2006-05-23 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <m1zmh8ikym.fsf_-_@ebiederm.dsl.xmission.com>
- Move handle_info into main so it is called once
after everything has been parsed. This allows the removal
of a static variable and removes two duplicate calls.
- Move parsing of inbody headers into handle_commit.
This means we parse the in-body headers after we have decoded
the character set, and it removes code duplication between
handle_multipart_one_part and handle_body.
- Change the flag indicating that we have seen an in body
prefix header into another bit in seen.
This is a little more general and allows the possibility of parsing
in body headers after the body message has begun.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
mailinfo.c | 58 ++++++++++++++++++++++------------------------------------
1 files changed, 22 insertions(+), 36 deletions(-)
3f6fe4d5e86c3d8d1fad75bfeb71f398966813d4
diff --git a/mailinfo.c b/mailinfo.c
index bee7b20..3fa9505 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,38 +237,41 @@ static int eatspace(char *line)
#define SEEN_FROM 01
#define SEEN_DATE 02
#define SEEN_SUBJECT 04
+#define SEEN_PREFIX 0x08
/* First lines of body can have From:, Date:, and Subject: */
-static int handle_inbody_header(int *seen, char *line)
+static void handle_inbody_header(int *seen, char *line)
{
+ if (*seen & SEEN_PREFIX)
+ return;
if (!memcmp("From:", line, 5) && isspace(line[5])) {
if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
*seen |= SEEN_FROM;
- return 1;
+ return;
}
}
if (!memcmp("Date:", line, 5) && isspace(line[5])) {
if (!(*seen & SEEN_DATE)) {
handle_date(line+6);
*seen |= SEEN_DATE;
- return 1;
+ return;
}
}
if (!memcmp("Subject:", line, 8) && isspace(line[8])) {
if (!(*seen & SEEN_SUBJECT)) {
handle_subject(line+9);
*seen |= SEEN_SUBJECT;
- return 1;
+ return;
}
}
if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
if (!(*seen & SEEN_SUBJECT)) {
handle_subject(line);
*seen |= SEEN_SUBJECT;
- return 1;
+ return;
}
}
- return 0;
+ *seen |= SEEN_PREFIX;
}
static char *cleanup_subject(char *subject)
@@ -590,12 +593,7 @@ static void decode_transfer_encoding(cha
static void handle_info(void)
{
char *sub;
- static int done_info = 0;
-
- if (done_info)
- return;
- done_info = 1;
sub = cleanup_subject(subject);
cleanup_space(name);
cleanup_space(date);
@@ -609,7 +607,7 @@ static void handle_info(void)
/* We are inside message body and have read line[] already.
* Spit out the commit log.
*/
-static int handle_commit_msg(void)
+static int handle_commit_msg(int *seen)
{
if (!cmitmsg)
return 0;
@@ -633,6 +631,11 @@ static int handle_commit_msg(void)
decode_transfer_encoding(line);
if (metainfo_charset)
convert_to_utf8(line, charset);
+
+ handle_inbody_header(seen, line);
+ if (!(*seen & SEEN_PREFIX))
+ continue;
+
fputs(line, cmitmsg);
} while (fgets(line, sizeof(line), stdin) != NULL);
fclose(cmitmsg);
@@ -664,26 +667,16 @@ static void handle_patch(void)
* that the first part to contain commit message and a patch, and
* handle other parts as pure patches.
*/
-static int handle_multipart_one_part(void)
+static int handle_multipart_one_part(int *seen)
{
- int seen = 0;
int n = 0;
- int len;
while (fgets(line, sizeof(line), stdin) != NULL) {
again:
- len = eatspace(line);
n++;
- if (!len)
- continue;
if (is_multipart_boundary(line))
break;
- if (0 <= seen && handle_inbody_header(&seen, line))
- continue;
- seen = -1; /* no more inbody headers */
- line[len] = '\n';
- handle_info();
- if (handle_commit_msg())
+ if (handle_commit_msg(seen))
goto again;
handle_patch();
break;
@@ -695,6 +688,7 @@ static int handle_multipart_one_part(voi
static void handle_multipart_body(void)
{
+ int seen = 0;
int part_num = 0;
/* Skip up to the first boundary */
@@ -709,7 +703,7 @@ static void handle_multipart_body(void)
while (1) {
int hdr = read_one_header_line(line, sizeof(line), stdin);
if (!hdr) {
- if (handle_multipart_one_part() < 0)
+ if (handle_multipart_one_part(&seen) < 0)
return;
/* Reset per part headers */
transfer_encoding = TE_DONTCARE;
@@ -730,18 +724,9 @@ static void handle_body(void)
{
int seen = 0;
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = eatspace(line);
- if (!len)
- continue;
- if (0 <= seen && handle_inbody_header(&seen, line))
- continue;
- seen = -1; /* no more inbody headers */
- line[len] = '\n';
- handle_info();
- handle_commit_msg();
+ if (fgets(line, sizeof(line), stdin) != NULL) {
+ handle_commit_msg(&seen);
handle_patch();
- break;
}
fclose(patchfile);
if (!patch_lines) {
@@ -791,6 +776,7 @@ int main(int argc, char **argv)
handle_multipart_body();
else
handle_body();
+ handle_info();
break;
}
check_header_line(line);
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* [PATCH 4/6] In handle_body only read a line if we don't already have one.
From: Eric W. Biederman @ 2006-05-23 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <m1verwikvj.fsf_-_@ebiederm.dsl.xmission.com>
This prepares for detecting non-email patches that don't have
mail headers. In which case we have already read the first
line so handle_body should not ignore it.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
mailinfo.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3ad0c255a351d771c7f301d4a4e9bfb6fdcbde5f
diff --git a/mailinfo.c b/mailinfo.c
index 3fa9505..99989c2 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -724,7 +724,7 @@ static void handle_body(void)
{
int seen = 0;
- if (fgets(line, sizeof(line), stdin) != NULL) {
+ if (line[0] || fgets(line, sizeof(line), stdin) != NULL) {
handle_commit_msg(&seen);
handle_patch();
}
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* [PATCH 5/6] More accurately detect header lines in read_one_header_line
From: Eric W. Biederman @ 2006-05-23 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <m1r72kiksz.fsf_-_@ebiederm.dsl.xmission.com>
Only count lines of the form '^.*: ' and '^From ' as email
header lines.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
mailinfo.c | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
b955444f0bfb4ee9a5cd31686dd7eeec0750e235
diff --git a/mailinfo.c b/mailinfo.c
index 99989c2..c642ff4 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -385,20 +385,29 @@ static int read_one_header_line(char *li
{
int ofs = 0;
while (ofs < sz) {
+ const char *colon;
int peek, len;
if (fgets(line + ofs, sz - ofs, in) == NULL)
- return ofs;
+ break;
len = eatspace(line + ofs);
if (len == 0)
- return ofs;
- peek = fgetc(in); ungetc(peek, in);
- if (peek == ' ' || peek == '\t') {
- /* Yuck, 2822 header "folding" */
- ofs += len;
- continue;
+ break;
+ colon = strchr(line, ':');
+ if (!colon || !isspace(colon[1])) {
+ /* Readd the newline */
+ line[ofs + len] = '\n';
+ line[ofs + len + 1] = '\0';
+ break;
}
- return ofs + len;
+ ofs += len;
+ /* Yuck, 2822 header "folding" */
+ peek = fgetc(in); ungetc(peek, in);
+ if (peek != ' ' && peek != '\t')
+ break;
}
+ /* Count mbox From headers as headers */
+ if (!ofs && !memcmp(line, "From ", 5))
+ ofs = 1;
return ofs;
}
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* [PATCH 6/6] Allow in body headers beyond the in body header prefix.
From: Eric W. Biederman @ 2006-05-23 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <m1mzd8iklr.fsf_-_@ebiederm.dsl.xmission.com>
- handle_from is fixed to not mangle it's input line.
- Then handle_inbody_header is allowed to look in
the body of a commit message for additional headers
that we haven't already seen.
This allows patches with all of the right information in
unfortunate places to be imported.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
mailinfo.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
eca59d2fd60af47170cdbfdebf3384465f0e7635
diff --git a/mailinfo.c b/mailinfo.c
index c642ff4..99374b3 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -72,11 +72,14 @@ static int bogus_from(char *line)
return 1;
}
-static int handle_from(char *line)
+static int handle_from(char *in_line)
{
- char *at = strchr(line, '@');
+ char line[1000];
+ char *at;
char *dst;
+ strcpy(line, in_line);
+ at = strchr(line, '@');
if (!at)
return bogus_from(line);
@@ -242,8 +245,6 @@ #define SEEN_PREFIX 0x08
/* First lines of body can have From:, Date:, and Subject: */
static void handle_inbody_header(int *seen, char *line)
{
- if (*seen & SEEN_PREFIX)
- return;
if (!memcmp("From:", line, 5) && isspace(line[5])) {
if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
*seen |= SEEN_FROM;
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* Re: irc usage..
From: Jakub Narebski @ 2006-05-23 20:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605221055270.3697@g5.osdl.org>
Linus Torvalds wrote:
> [...] people _should_ realize that removing objects is very very special.
> Whether it's done by "git prune-packed" or "git prune", that's a very
> dangerous operations. "git prune" a lot more so than "git prune-packed",
> of course (in fact, you should _never_ run "git prune" on a repository
> that is active - you _will_ corrupt it)-
Would it be possible to make 'git prune' command repository corruption safe,
even if some information might be lost (like 'git add')? Or do _corruption_
mean some recoverable only information is lost? Not always one can use "one
repository per developer" workflow.
One of the solution would be to to use reader/writer lock (filesystem
semaphore), with each command modyfying repository performing locking, and
git-prune waiting on lock until noone is accessing repository. Of course
the problem is with OS and filesystems which does not support locking, and
with stale locks...
Second solution would be to [optionally] wait until no process is accessing
repository, copy repository in some safe place, [optionally] calculate
checksum, prune, [optionally] check if the repository was modified
meanwhile and either abort or repeat, and finally copy pruned repository
back.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Junio C Hamano @ 2006-05-23 20:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605231232360.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> Committing initial tree 34bd3dcd4bfd79bad35ce3fb08b2e21108195db8
>> Server has gone away while fetching BUGS-TODO 1.1, retrying...
>...
> Martin, that problem seems to go away when I initialize $res to 0 in
> _fetchfile.
>
> I don't know perl, and maybe local variables are pre-initialized to empty.
When a new file that is empty is created, sub _line would call
sub _fetchfile with $cnt == 0, and it can return $res which
is initialized to 'undef'. That explains why sub file says
$self->_line() returned an undef and I think what you did is the
right fix.
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Martin Langhoff @ 2006-05-23 20:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.64.0605231232360.5623@g5.osdl.org>
On 5/24/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Martin, that problem seems to go away when I initialize $res to 0 in
> _fetchfile.
>
> I don't know perl, and maybe local variables are pre-initialized to empty.
>
> It's entirely possible that the fact that it now seems to work for me is
> purely timing-related, since I also ended up using "-P cvsps-output" to
> avoid having a huge cvsps binary in memory at the same time.
Strange! Cannot repro here with v5.8.8 (debian/etch 5.8.8-4) but
initialising it doesn't hurt, so let's do it:
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ace7087..abbfd0b 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -371,7 +371,7 @@ sub file {
}
sub _fetchfile {
my ($self, $fh, $cnt) = @_;
- my $res;
+ my $res = 0;
my $bufsize = 1024 * 1024;
while($cnt) {
if ($bufsize > $cnt) {
cheers,
martin
^ permalink raw reply related
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Martin Langhoff @ 2006-05-23 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsi55et5.fsf@assigned-by-dhcp.cox.net>
On 5/23/06, Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > Jeff,
> >
> > good stuff -- aiming at exactly the things that had been nagging me.
> > Some minor notes on top of what junio's mentioned...
> >
> >> + die "unable to open $f: $!" unless $! == POSIX::ENOENT;
> >> + return undef;
> >
> > Heh. Is that the return of the living dead?
>
> Note the trailing "unless" there.
Of course. I had actually missed the closing quotes, and thought the
error msg wanted to talk about POSIX. 'twas late in the day, seems
like most of my comments in this email were rather stoopid.
> >> +sub update_index (\@\@) {
> >> + my $old = shift;
> >> + my $new = shift;
> >
> > Would it not make more sense to just pass them as plain parameters?
>
> Meaning...? Perl5 can pass only one flat array, so the above is
> a standard way to pass two arrays.
Meaning I am stupid :(
> >> + print "Committed patch $patchset ($branch $commit_date)\n" if
> >
> > Given that we have that -- should we remember it and avoid re-reading
> > the headref from disk? A %seenheads cache would save us 99.9% of the
> > hassle.
> >
> > In related news, I've dealt with file reads from the socket being
> > memorybound. Should merge ok.
>
> Merged OK, and I think your last suggestion makes sense. I'll
> go to bed after pushing out Jeff's two patches and yours.
I'll look into caching headrefs tonight if noone beats me to it.
martin
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Björn Engelmann @ 2006-05-23 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac99c1hv.fsf@assigned-by-dhcp.cox.net>
Hi,
I hope this time I got it right. Is there some kind of style-guide I can
refer to in future ?
> Another question is if the QA data expected to be amended or
> annotated later, after it is created.
>
> If the answer is yes, then you probably would not want tags --
> you can create a new tag that points at the same commit to
> update the data, but then you have no structural relationships
> given by git between such tags that point at the same commit.
> You could infer their order by timestamp but that is about it.
> I think you are better off creating a separate QA project that
> adds one new file per commit on the main project, and have the
> file identify the commit object on the main project (either
> start your text file format for QA data with the commit object
> name, or name each such QA data file after the commit object
> name). Then your automated procedure could scan and add a new
> file to the QA project every time a new commit is made to the
> main project, and the data in the QA project can be amended or
> annotated and the changes will be version controlled.
>
Great idea ! Thanks a lot. Originally it was not planned to alter the
results once committet, but this way it would even be possible to rescan
a commit with a different tool and merge the results. Git would also be
able to use delta-encoding when packing what can be considered extremly
efficient since most probably most scan-results won't differ much.
I am currently wondering where to store the reference to such a
sub-repository. It certainly is a head, but I would like to avoid anyone
commiting code into this "branch". Maybe I will create a new directory
.git/refs/annotations.
When thinking about this very elegant way to handle meta-data, I got
another idea:
The quality assurance system also works distributed. For scalability
reasons there are multiple scanners, each scanning one commit at a time.
Do you think git could also be used to handle "locking" ? The scanners
would then push a commit with an empty result-file into the
annotations-repository so all other scanners who are looking for
currently unscanned commits would ignore it in future. When finished the
result can be inserted by pushing a subsequent commit. This way one
avoids the need for a seperate job-server / protocol.
I am not sure how git would perform in such an environment. Do you think
the "git-push"-implementation is sufficiently "thread-save" for this ?
Or could simultaniously pushing into the same branch f.e. break the
repository ?
Hmm.. 2 more things on my mind:
1.) Do you intend to add some more advanced metadata-functionality to
git in the future or should I send a patch with my implementation once
it is finished ? Will be just some scripts using similar commands to
what Linus sent me (thanks for that, btw)
2.) Searching for a way to add objects to the database I spent quite a
while to find the right command. Don't you think it would be much more
intuitive having an
git-create-object [-t <type>] [-n] [-f] [-z] [--stdin] <file> [-r
<ref-name>]
command for creating any type of object (-t blob as default), optionally
omitting writing it to the database (-n = no-write) (like
git-hash-object), by default validating its input (overriding with -f)
(like git-mktag, git-mktree) and maybe even able to add a reference to
it with -r (like git-tag).
Bj
^ permalink raw reply
* Re: [osol-bugs] access() behaves strange when used as root
From: Stefan Pfetzing @ 2006-05-23 20:43 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <44735D61.nail4RQ116Y06@burner>
Hi Joerg,
2006/5/23, Joerg Schilling <schilling@fokus.fraunhofer.de>:
> Before claiming that Soplaris is not behaving correctly, you should have a look
> into the standard.......
I didn't say Solaris does not behave "correctly" - I just said it does
not behave as every
other POSIX/SUS Unix I know.
> The behavior of Solaris access() is OK.
I know that its completely ok with SUS - and I did say that before.
Primarily I was just wondering about this behaviour and IMHO the git
developers were too.
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: [osol-bugs] access() behaves strange when used as root
From: Linus Torvalds @ 2006-05-23 20:54 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: Git Mailing List
In-Reply-To: <f3d7535d0605231343h51bfb2c9w1d15536b92874a88@mail.gmail.com>
On Tue, 23 May 2006, Stefan Pfetzing wrote:
>
> Hi Joerg,
Don't bother talking to Joerg.
He's a certified loon, and thinks Solaris is correct by definition. He's
insane. He thinks that anybody who does anything different from Solaris is
by definition not just wrong, but actively evil, even when the "anything
different" is clearly superior (ie he thinks that Solaris device naming is
not only sane, but claims that everybody else should do it that way).
If you ever wondered why "cdrecord" takes a default device argument of the
forma "dev=0,1,0" or other random numbers, it's Joerg.
So just ignore him. I hope the OpenSolaris lists have saner people around.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-23 20:59 UTC (permalink / raw)
To: Morten Welinder; +Cc: Martin Langhoff, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <118833cc0605231047o2012deefh5e77b8496da1e673@mail.gmail.com>
On Tue, May 23, 2006 at 01:47:01PM -0400, Morten Welinder wrote:
> Why run "env" and not just muck with %ENV?
> >+ my $pid = open2(my $commit_read, my $commit_write,
> >+ 'env',
> >+ "GIT_AUTHOR_NAME=$author_name",
> >+ "GIT_AUTHOR_EMAIL=$author_email",
> >+ "GIT_AUTHOR_DATE=$commit_date",
> >+ "GIT_COMMITTER_NAME=$author_name",
> >+ "GIT_COMMITTER_EMAIL=$author_email",
> >+ "GIT_COMMITTER_DATE=$commit_date",
> >+ 'git-commit-tree', $tree, @commit_args);
Oops, that's an obvious fork optimization that I should have caught.
Patch is below. Note that this will now affect the environment of all
sub-processes, but it shouldn't matter since we reset it right before
commit. However, if anyone is worried, we can stash the old %ENV in
another hash temporarily.
-Peff
PS What is the preferred format for throwing patches into replies like
this? Putting the patch at the end (as here) or throwing the reply
comments in the ignored section near the diffstat?
---
cvsimport: set up commit environment in perl instead of using env
---
44c4a9f67322302ca49146a7c143c07ea67da366
git-cvsimport.perl | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
44c4a9f67322302ca49146a7c143c07ea67da366
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 41ee9a6..83d7d3c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -618,14 +618,13 @@ sub commit {
}
my $commit_date = strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date));
+ $ENV{GIT_AUTHOR_NAME} = $author_name;
+ $ENV{GIT_AUTHOR_EMAIL} = $author_email;
+ $ENV{GIT_AUTHOR_DATE} = $commit_date;
+ $ENV{GIT_COMMITTER_NAME} = $author_name;
+ $ENV{GIT_COMMITTER_EMAIL} = $author_email;
+ $ENV{GIT_COMMITTER_DATE} = $commit_date;
my $pid = open2(my $commit_read, my $commit_write,
- 'env',
- "GIT_AUTHOR_NAME=$author_name",
- "GIT_AUTHOR_EMAIL=$author_email",
- "GIT_AUTHOR_DATE=$commit_date",
- "GIT_COMMITTER_NAME=$author_name",
- "GIT_COMMITTER_EMAIL=$author_email",
- "GIT_COMMITTER_DATE=$commit_date",
'git-commit-tree', $tree, @commit_args);
# compatibility with git2cvs
--
1.3.3.g40505-dirty
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* file name case-sensitivity issues
From: Alex Riesen @ 2006-05-23 21:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Linus Torvalds
Very simple to reproduce on FAT and NTFS, and under Windows, as usual,
when a problem is especially annoying. I seem to have no chance to
get my hands on this myself, so I at least let everyone know about the
problem.
The case goes as follows:
$ mkdir case-sensitivity-test
$ cd case-sensitivity-test
$ git init-db
defaulting to local storage area
$ echo foo > foo
$ echo bar > bar
$ git add foo bar
$ git commit -m initial\ commit
Committing initial tree 89ff1a2aefcbff0f09197f0fd8beeb19a7b6e51c
$ git checkout -b side
$ echo bar-side >> bar
$ git commit -m side\ commit -o bar
$ git checkout master
$ rm foo
$ git update-index --remove foo
$ echo FOO > FOO # note case change
$ git add FOO
# this is on linux, vfat on an usbstick (mounted with default case
# conversion, which is "lower". That's why the file can't be found).
# Have no Windows at home. On Windows the FOO is created and "git add"
# just passes. We just assume it did add the file, as it would there.
git-ls-files: error: pathspec 'FOO' did not match any.
Maybe you misspelled it?
$ git commit -m case\ change
$ git pull . side
Trying really trivial in-index merge...
git-read-tree: fatal: Untracked working tree file 'foo' would be overwritten by merge.
Nope. Really trivial in-index merge is not possible.
Merging HEAD with 7b0cad3a104487fa92afa06736294338acb84281
Merging:
7f6a8ba3e41683ef5b55921d050092e766aad4a5 case change
7b0cad3a104487fa92afa06736294338acb84281 side commit
found 1 common ancestor(s):
f857aaf5f1d3716d25ca7751f12de30420d9b2aa initial commit
git-read-tree: git-read-tree: fatal: Untracked working tree file 'foo' would be overwritten by merge.
No merge strategy handled the merge.
Well, what now?
What I did was to replace that die() with error() in
read-tree.c:verify_absent, which if cause is not acceptable.
I'll try to find a solution sometime later, but I really hope
someone will find it sooner (because it'll take some time for me).
Hope it didn't bit anyone yet...
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-23 21:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <46a038f90605231329w35d10cfdg1ac413ebf8d32e11@mail.gmail.com>
On Wed, May 24, 2006 at 08:29:07AM +1200, Martin Langhoff wrote:
> Strange! Cannot repro here with v5.8.8 (debian/etch 5.8.8-4) but
> initialising it doesn't hurt, so let's do it:
I can reproduce with debian perl 5.8.8-4. The bug is only triggered by
0-length files, so presumably your test repo doesn't have any.
-Peff
^ 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