* Re: [PATCH v2] Use correct grammar in diffstat summary line
From: Nguyen Thai Ngoc Duy @ 2012-02-02 14:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Ævar Arnfjörð,
Frederik Schwarzer, Brandon Casey
In-Reply-To: <7vhaza2qjw.fsf@alter.siamese.dyndns.org>
On Wed, Feb 01, 2012 at 01:26:43PM -0800, Junio C Hamano wrote:
> Nice. Will queue
Please also squash this in (resend looks ugly and it's hard to point
out changes). It makes the code look less ugly, use Q_() for gettext
poisoning and revert am input text back as Jonathan suggested.
I take it --summary is un-i18n-able, should we introduce.. umm..
--nice-summary or something that can support i18n?
-- 8< --
diff --git a/diff.c b/diff.c
index 5f3ce97..07c94f2 100644
--- a/diff.c
+++ b/diff.c
@@ -1325,6 +1325,7 @@ static void fill_print_name(struct diffstat_file *file)
int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
{
struct strbuf sb = STRBUF_INIT;
+ const char *fmt;
int ret;
if (!files) {
@@ -1332,10 +1333,8 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
return fputs(_(" 0 files changed\n"), fp);
}
- strbuf_addf(&sb,
- ngettext(" %d file changed", " %d files changed",
- files),
- files);
+ fmt = Q_(" %d file changed", " %d files changed", files);
+ strbuf_addf(&sb, fmt, files);
/*
* For binary diff, the caller may want to print "x files
@@ -1346,25 +1345,17 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
* but nothing about added/removed lines? Is this a bug in Git?").
*/
if (insertions || deletions == 0) {
- strbuf_addf(&sb,
- /*
- * TRANSLATORS: "+" in (+) is a line addition marker;
- * do not translate it.
- */
- ngettext(", %d insertion(+)", ", %d insertions(+)",
- insertions),
- insertions);
+ /* TRANSLATORS: "+" in (+) is a line addition marker,
+ do not translate it */
+ fmt = Q_(", %d insertion(+)", ", %d insertions(+)", insertions);
+ strbuf_addf(&sb, fmt, insertions);
}
if (deletions || insertions == 0) {
- strbuf_addf(&sb,
- /*
- * TRANSLATORS: "-" in (-) is a line removal marker;
- * do not translate it.
- */
- ngettext(", %d deletion(-)", ", %d deletions(-)",
- deletions),
- deletions);
+ /* TRANSLATORS: "-" in (-) is a line removal marker,
+ do not translate it */
+ fmt = Q_(", %d deletion(-)", ", %d deletions(-)", deletions);
+ strbuf_addf(&sb, fmt, deletions);
}
strbuf_addch(&sb, '\n');
ret = fputs(sb.buf, fp);
diff --git a/t/t0023-crlf-am.sh b/t/t0023-crlf-am.sh
index 18fe27b..12a3d78 100755
--- a/t/t0023-crlf-am.sh
+++ b/t/t0023-crlf-am.sh
@@ -12,7 +12,7 @@ Subject: test1
---
foo | 1 +
- 1 file changed, 1 insertion(+)
+ 1 files changed, 1 insertions(+)
create mode 100644 foo
diff --git a/foo b/foo
-- 8< --
--
Duy
^ permalink raw reply related
* [PATCH v4 2/2] find_pack_entry(): do not keep packed_git pointer locally
From: Nguyễn Thái Ngọc Duy @ 2012-02-02 13:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre,
Nguyễn Thái Ngọc Duy
In-Reply-To: <alpine.LFD.2.02.1202011100010.2759@xanadu.home>
Commit f7c22cc (always start looking up objects in the last used pack
first - 2007-05-30) introduce a static packed_git* pointer as an
optimization. The kept pointer however may become invalid if
free_pack_by_name() happens to free that particular pack.
Current code base does not access packs after calling
free_pack_by_name() so it should not be a problem. Anyway, move the
pointer out so that free_pack_by_name() can reset it to avoid running
into troubles in future.
Thanks to Junio for code layout suggestions.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Credit where credit is due. No code changes from pu.
sha1_file.c | 27 +++++++++++++--------------
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 61e51ed..6b1b512 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -54,6 +54,8 @@ static struct cached_object empty_tree = {
0
};
+static struct packed_git *last_found_pack;
+
static struct cached_object *find_cached_object(const unsigned char *sha1)
{
int i;
@@ -720,6 +722,8 @@ void free_pack_by_name(const char *pack_name)
close_pack_index(p);
free(p->bad_object_sha1);
*pp = p->next;
+ if (last_found_pack == p)
+ last_found_pack = NULL;
free(p);
return;
}
@@ -2046,27 +2050,22 @@ static int fill_pack_entry(const unsigned char *sha1,
static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
{
- static struct packed_git *last_found = (void *)1;
struct packed_git *p;
prepare_packed_git();
if (!packed_git)
return 0;
- p = (last_found == (void *)1) ? packed_git : last_found;
- do {
- if (fill_pack_entry(sha1, e, p)) {
- last_found = p;
- return 1;
- }
+ if (last_found_pack && fill_pack_entry(sha1, e, last_found_pack))
+ return 1;
- if (p == last_found)
- p = packed_git;
- else
- p = p->next;
- if (p == last_found)
- p = p->next;
- } while (p);
+ for (p = packed_git; p; p = p->next) {
+ if (p == last_found_pack || !fill_pack_entry(sha1, e, p))
+ continue;
+
+ last_found_pack = p;
+ return 1;
+ }
return 0;
}
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: How best to handle multiple-authorship commits in GIT?
From: Frans Klaver @ 2012-02-02 13:41 UTC (permalink / raw)
To: David Howells; +Cc: git, valerie.aurora
In-Reply-To: <21056.1328185509@redhat.com>
Hi,
On Thu, Feb 2, 2012 at 1:25 PM, David Howells <dhowells@redhat.com> wrote:
>
> Hi,
>
> I've been assigned a stack of patches to maintain and try and get upstream by
> my employer. Most of the patches currently have the authorship set to Val,
> but since I'll be maintaining them if they go in upstream and I've changed
> them a lot, I feel I should reassign the author field to myself so people
> pester me rather than Val with questions about them. However, I don't want to
> deny Val or any other contributor credit for their work on the patches.
>
> I can see a number of ways of doing this, and am wondering which will be best:
>
> (1) Ascribe multiple authorship directly in the commit. I suspect this would
> require a change to GIT and its associated tools. That way I could put my
> name in the priority pestering spot, but doing a search on authorship
> would still credit Val and others.
>
> (2) Add an extra tag 'Originally-authored-by' (or maybe 'Coauthored-by' as I
> saw someone recommend) in amongst the 'Signed-off-by' list. But that
> doesn't give them credit in a gitweb search without changing gitweb.
>
> (3) Don't actually modify Val's commits to bring them up to date, but rather
> create a historical GIT tree with Val's commits committed as-are and then
> add my changes to the top in a number of large merge commits (there have
> been multiple major breakages due to different merge windows).
>
> I dislike this approach because it doesn't produce a nice set of patches I
> can give to someone to review (which is a must). Plus, for the most part,
> it's actually easier to port Val's patches individually.
>
> Can GIT be modified to do (1)? Gitweb's display need only show one of the
> authors in the single-row-per-patch list mode, but should find a patch by any
> of the authors in an author search and should display all the authors in the
> commit display.
I always thought of the author field as being an indication of who is
ultimately responsible for its implementation (the one in the
pestering spot). (1) may seem desirous, but doesn't (2) seem like a
cleaner and more maintainable solution? Gitweb will show the entire
log message if people are interested in the exact change, right?
Cheers,
Frans
^ permalink raw reply
* Re: [PATCH] i18n: po for zh_cn
From: Nguyen Thai Ngoc Duy @ 2012-02-02 13:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jiang Xin, Git List, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vr4ye15kr.fsf@alter.siamese.dyndns.org>
On Thu, Feb 2, 2012 at 6:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jiang Xin <worldhello.net@gmail.com> writes:
>
>> Git can speak Chinese now.
>>
>> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
>> ---
>> po/zh_cn.po | 3568 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 个文件被修改, 3568 处添加(+), 0 处删除(-)
>> create mode 100644 po/zh_cn.po
>
> I do not mind Chinese in the patch text (i.e. below), but I would have
> preferred the above not to be in Chinese, which I do not read---I can
> guess what 文件, 添加 and 删除 are, and I can also guess that 个 and 处
> are units of counting, but nevertheless...
Such a stat line would be wonderful in an all-Chinese environment
though. I'm thinking perhaps it's a good idea to support
core.officialLocale (or workingLanguage). Commands that produce stuff
for outside like format-patch would prefer core.exchangeLanguage over
$LANG. Commands in blurred zone can learn --official option to ignore
$LANG.
We can then have a shared config with core.officialLocale =
en_US.UTF-8 somewhere in git.git. Developers of multi-nation companies
would be pleased, I think.
--
Duy
^ permalink raw reply
* I18N.pm is incompatible with perl < 5.8.3
From: Tom G. Christensen @ 2012-02-02 13:11 UTC (permalink / raw)
To: git
Hello,
While running the git 1.7.9 testsuite on RHEL 3 with perl 5.8.0 and
gettext 0.11.4 I got this error in t0202-gettext-perl.sh:
# test_external test Perl Git::I18N API failed: /usr/bin/perl
/builddir/build/BUILD/git-1.7.9/t/t0202/test.pl
# test_external_without_stderr test no stderr: Perl Git::I18N API
failed: /usr/bin/perl /builddir/build/BUILD/git-1.7.9/t/t0202/test.pl:
A verbose run gave me this:
# test_external test Perl Git::I18N API failed: /usr/bin/perl
/builddir/build/BUILD/git-1.7.9/t/t0202/test.pl
# expecting no stderr from previous command
# test_external_without_stderr test no stderr: Perl Git::I18N API
failed: /usr/bin/perl /builddir/build/BUILD/git-1.7.9/t/t0202/test.pl:
# Stderr is:
"import" is not exported by the Exporter module
Can't continue after import errors at
/builddir/build/BUILD/git-1.7.9/t/../perl/blib/lib/Git/I18N.pm line 5
BEGIN failed--compilation aborted at
/builddir/build/BUILD/git-1.7.9/t/../perl/blib/lib/Git/I18N.pm line 5.
Compilation failed in require at
/builddir/build/BUILD/git-1.7.9/t/t0202/test.pl line 8.
BEGIN failed--compilation aborted at
/builddir/build/BUILD/git-1.7.9/t/t0202/test.pl line 8.
# Looks like your test died before it could output anything.
I found the cause and the solution here:
http://www.nntp.perl.org/group/perl.module.build/2008/02/msg1214.html
I've changed
use Exporter 'import'
to
BEGIN {
require Exporter;
*{import} = \&Exporter::import;
}
in I18N.pm.
The test now passes (GETTEXT_LOCALE=1):
# lib-gettext: No is_IS UTF-8 locale available
# lib-gettext: No is_IS ISO-8859-1 locale available
# run 1: Perl Git::I18N API (/usr/bin/perl
/builddir/build/BUILD/git-1.7.9/t/t0202/test.pl)
1..8
ok 1 - Testing Git::I18N with NO Perl gettext library
ok 2 - Git::I18N is located at
/builddir/build/BUILD/git-1.7.9/t/../perl/blib/lib/Git/I18N.pm
ok 3 - sanity: Git::I18N has 1 export(s)
ok 4 - sanity: Git::I18N exports everything by default
ok 5 - sanity: __ has a $ prototype
ok 6 - Passing a string through __() in the C locale works
ok 7 - Without a gettext library + <C> locale <TEST: A Perl test string>
turns into <TEST: A Perl test string>
ok 8 - Without a gettext library + <is> locale <TEST: A Perl test
string> turns into <TEST: A Perl test string>
# test_external test Perl Git::I18N API was ok
# expecting no stderr from previous command
# test_external_without_stderr test no stderr: Perl Git::I18N API was ok
-tgc
^ permalink raw reply
* How best to handle multiple-authorship commits in GIT?
From: David Howells @ 2012-02-02 12:25 UTC (permalink / raw)
To: git; +Cc: dhowells, valerie.aurora
Hi,
I've been assigned a stack of patches to maintain and try and get upstream by
my employer. Most of the patches currently have the authorship set to Val,
but since I'll be maintaining them if they go in upstream and I've changed
them a lot, I feel I should reassign the author field to myself so people
pester me rather than Val with questions about them. However, I don't want to
deny Val or any other contributor credit for their work on the patches.
I can see a number of ways of doing this, and am wondering which will be best:
(1) Ascribe multiple authorship directly in the commit. I suspect this would
require a change to GIT and its associated tools. That way I could put my
name in the priority pestering spot, but doing a search on authorship
would still credit Val and others.
(2) Add an extra tag 'Originally-authored-by' (or maybe 'Coauthored-by' as I
saw someone recommend) in amongst the 'Signed-off-by' list. But that
doesn't give them credit in a gitweb search without changing gitweb.
(3) Don't actually modify Val's commits to bring them up to date, but rather
create a historical GIT tree with Val's commits committed as-are and then
add my changes to the top in a number of large merge commits (there have
been multiple major breakages due to different merge windows).
I dislike this approach because it doesn't produce a nice set of patches I
can give to someone to review (which is a must). Plus, for the most part,
it's actually easier to port Val's patches individually.
Can GIT be modified to do (1)? Gitweb's display need only show one of the
authors in the single-row-per-patch list mode, but should find a patch by any
of the authors in an author search and should display all the authors in the
commit display.
David
^ permalink raw reply
* Re: git-svn branches with revision id's in name
From: Carsten Fuchs @ 2012-02-02 12:24 UTC (permalink / raw)
To: Stephen Duncan Jr; +Cc: git
In-Reply-To: <CAGYrzvwzrsZdHHnSBaMv-sD9mDGVQ-qFuks+JM6d-NQ9Wz9KwQ@mail.gmail.com>
Hi all,
Am 2012-01-30 20:42, schrieb Stephen Duncan Jr:
> [...]
> $ git branch -a
> * master
> remotes/develop
> remotes/develop@29271
> remotes/develop@32463
> remotes/develop@34103
> remotes/feature/xyz
> remotes/feature/xyz@26438
> remotes/feature/xyz@27542
> remotes/feature/xyz@35233
>
> Why have these remote branches been created? What impact does this
> have on my checkout? Can I remove safely remove them? How? I was
> unable to figure out how to reference this behavior in order to search
> for information on it.
Same questions here.
(I know how to remove them, but I'd love to learn and understand why they have been
created.)
Any info would much be appreciated!
Many thanks and best regards,
Carsten
--
Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
Learn more at http://www.cafu.de
^ permalink raw reply
* Re: How to find and analyze bad merges?
From: norbert.nemec @ 2012-02-02 12:16 UTC (permalink / raw)
To: git
In-Reply-To: <20120202120340.GA25190@burratino>
Am 02.02.12 13:03, schrieb Jonathan Nieder:
> David Barr wrote:
>
>> Do the -c --cc or -m flags for git log help in this case?
>> They alter the way merge diffs are presented, as described under Diff Formatting
>> in the git-log(1) man page.
>
> I suspect Norbert was running into history simplification, so the --full-history
> flag would be the relevant one.
Not quite.
As far as I understand it, history simplification hides the whole branch
if its changes did not end up in the current branch.
When I tried it out, the --full-history prevented hiding the
bugfix-commit itself, but it did not show the critical merge commit in
the log.
> See the thread [1] for a few relevant side-notes.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/188904
As I understand this thread, the user only requested all commits that
"modify a file". Our merge-commit strictly speaking did not modify the
file but simply kept one of the versions, completely swamping all
modifications from one branch. Exactly the case that is still not
covered by --full-history.
^ permalink raw reply
* Breakage in master?
From: Erik Faye-Lund @ 2012-02-02 12:14 UTC (permalink / raw)
To: Git Mailing List, msysGit, Ævar Arnfjörð Bjarmason
Something strange is going on in Junio's current 'master' branch
(f3fb075). "git show" has started to error out on Windows with a
complaint about our vsnprintf:
---8<---
$ git show
commit f3fb07509c2e0b21b12a598fcd0a19a92fc38a9d
Author: Junio C Hamano <gitster@pobox.com>
Date: Tue Jan 31 22:31:35 2012 -0800
Update draft release notes to 1.7.10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fatal: BUG: your vsnprintf is broken (returned -1)
---8<---
"git status" is also behaving strange:
---8<---
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ←[31mcompat/vcbuild/include/sys/resource.h←[m
# ←[31mtemp.patch←[m
# ←[31mtest.c←[m
# ←[31mtest.patch←[m
nothing added to commit but untracked files present (use "git add" to track)
---8<---
Yeah, the ANSI color codes are being printed verbatim, even though
compat/winansi.c is supposed to convert these. "git -p status" works
fine, as it pipes the ANSI codes directly through less.
But here's the REALLY puzzling part: If I add a simple, unused
function to diff-lib.c, like this:
---8<---
diff --git a/diff-lib.c b/diff-lib.c
index fc0dff3..914a224 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -82,6 +82,11 @@ static int match_stat_with_submodule(struct
diff_options *diffopt,
return changed;
}
+static unsigned int foo(const char *a, unsigned int b)
+{
+ return b;
+}
+
int run_diff_files(struct rev_info *revs, unsigned int option)
{
int entries, i;
---8<---
"git status" starts to error out with that same vsnprintf complaint!
---8<---
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
fatal: BUG: your vsnprintf is broken (returned -1)
---8<---
Here's the stack-trace:
---8<---
Breakpoint 1, die (err=0x5268ec "BUG: your vsnprintf is broken (returned %d)")
at usage.c:81
81 void NORETURN die(const char *err, ...)
(gdb) bt
#0 die (err=0x5268ec "BUG: your vsnprintf is broken (returned %d)")
at usage.c:81
#1 0x00466314 in strbuf_vaddf (sb=0x28fb54,
fmt=0x533ef4 " (use \"git checkout -- <file>...\" to discard changes in wor
king directory)", ap=0x28fbac "+\025\026\002") at strbuf.c:221
#2 0x004cbb6f in status_vprintf (s=0x28fc38, at_bol=0,
color=0x46c4f2 "\205└t\n\203─\020[^╔├\215v",
fmt=0x533ef4 " (use \"git checkout -- <file>...\" to discard changes in wor
king directory)", ap=0x28fbac "+\025\026\002", trail=0x533a89 "\n")
at wt-status.c:44
#3 0x004cbe6b in status_printf_ln (s=0x28fc38, color=0x28fc70 "",
fmt=0x533ef4 " (use \"git checkout -- <file>...\" to discard changes in wor
king directory)") at wt-status.c:87
#4 0x004cced1 in wt_status_print (s=0x28fc38) at wt-status.c:176
#5 0x0041922e in cmd_status (argc=1, argv=0x319b4, prefix=0x0)
at builtin/commit.c:1254
#6 0x004019d6 in handle_internal_command (argc=<value optimized out>,
argv=<value optimized out>) at git.c:308
#7 0x00401c26 in main (argc=2, argv=0x319b0) at git.c:513
(gdb)
---8<---
This smells a bit like a smashed stack to me. Both issues happens in
roughly the same area of the call stack, and when adding an unused
function changes behavior, something really odd is going on ;)
I've bisected the issues down to 5e9637c (i18n: add infrastructure for
translating Git with gettext). Trying to apply my unused-function
patch on top of this commit starts giving the same "fatal: BUG: your
vsnprintf is broken (returned -1)" error. It's ancestor, bc1bbe0(Git
1.7.8-rc2), does not yield any of the issues.
I'm at a loss here. Does anyone have a hunch about what's going on?
^ permalink raw reply related
* Re: How to find and analyze bad merges?
From: norbert.nemec @ 2012-02-02 12:10 UTC (permalink / raw)
To: git
In-Reply-To: <CAFfmPPMc1V97OPHyrZp+p4YUek1c6fCncyj0s1YU9xjxQBCsDA@mail.gmail.com>
Am 02.02.12 12:41, schrieb David Barr:
> On Thu, Feb 2, 2012 at 10:17 PM, Norbert Nemec
> <norbert.nemec@native-instruments.de> wrote:
>> To be yet more precise:
>>
>> My complaint is that you need this kind of sledge-hammer solutions to
>> analyze the situation. I, as an semi-expert with git did manage to find the
>> problem without even having to resort to bisect or manually redoing the
>> merge. My complaint is about the perspective of the medium-experienced user
>> who is completely puzzled by the fact that a
>> "git log<filename>" silently skips the critical merge commit.
>
> Do the -c --cc or -m flags for git log help in this case?
> They alter the way merge diffs are presented, as described under Diff Formatting
> in the git-log(1) man page.
Indeed, these help somewhat. This way, the changes are not hidden, but
instead lost in the multitude of trivially-resolved conflicts...
^ permalink raw reply
* Re: How to find and analyze bad merges?
From: Jonathan Nieder @ 2012-02-02 12:03 UTC (permalink / raw)
To: David Barr; +Cc: Norbert Nemec, Thomas Rast, git
In-Reply-To: <CAFfmPPMc1V97OPHyrZp+p4YUek1c6fCncyj0s1YU9xjxQBCsDA@mail.gmail.com>
David Barr wrote:
> Do the -c --cc or -m flags for git log help in this case?
> They alter the way merge diffs are presented, as described under Diff Formatting
> in the git-log(1) man page.
I suspect Norbert was running into history simplification, so the --full-history
flag would be the relevant one.
See the thread [1] for a few relevant side-notes.
[1] http://thread.gmane.org/gmane.comp.version-control.git/188904
^ permalink raw reply
* Re: How to find and analyze bad merges?
From: David Barr @ 2012-02-02 11:41 UTC (permalink / raw)
To: Norbert Nemec; +Cc: Thomas Rast, git
In-Reply-To: <4F2A70DA.6020107@native-instruments.de>
On Thu, Feb 2, 2012 at 10:17 PM, Norbert Nemec
<norbert.nemec@native-instruments.de> wrote:
> To be yet more precise:
>
> My complaint is that you need this kind of sledge-hammer solutions to
> analyze the situation. I, as an semi-expert with git did manage to find the
> problem without even having to resort to bisect or manually redoing the
> merge. My complaint is about the perspective of the medium-experienced user
> who is completely puzzled by the fact that a
> "git log <filename>" silently skips the critical merge commit.
Do the -c --cc or -m flags for git log help in this case?
They alter the way merge diffs are presented, as described under Diff Formatting
in the git-log(1) man page.
--
David Barr
^ permalink raw reply
* Re: [PATCH 1/3] vcs-svn: rename check_overflow arguments for clarity
From: Jonathan Nieder @ 2012-02-02 11:27 UTC (permalink / raw)
To: David Barr; +Cc: Dmitry Ivankov, Junio C Hamano, Ramsay Jones, GIT Mailing-list
In-Reply-To: <CAFfmPPOeFk871m_N+nLXgQx3Uj4wVhgR9BNFzM2ggtseop0JaA@mail.gmail.com>
David Barr wrote:
> Maybe rename to check_offset_overflow to make it explicit?
Ok, here's the patch I'll squash in. ;-)
diff --git i/vcs-svn/sliding_window.c w/vcs-svn/sliding_window.c
index 2f4ae60f..ec2707c9 100644
--- i/vcs-svn/sliding_window.c
+++ w/vcs-svn/sliding_window.c
@@ -31,7 +31,7 @@ static int read_to_fill_or_whine(struct line_buffer *file,
return 0;
}
-static int check_overflow(off_t offset, uintmax_t len)
+static int check_offset_overflow(off_t offset, uintmax_t len)
{
if (len > maximum_signed_value_of_type(off_t))
return error("unrepresentable length in delta: "
@@ -48,9 +48,9 @@ int move_window(struct sliding_view *view, off_t off, size_t width)
off_t file_offset;
assert(view);
assert(view->width <= view->buf.len);
- assert(!check_overflow(view->off, view->buf.len));
+ assert(!check_offset_overflow(view->off, view->buf.len));
- if (check_overflow(off, width))
+ if (check_offset_overflow(off, width))
return -1;
if (off < view->off || off + width < view->off + view->width)
return error("invalid delta: window slides left");
^ permalink raw reply related
* Re: [PATCH 1/3] vcs-svn: rename check_overflow arguments for clarity
From: David Barr @ 2012-02-02 11:25 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Dmitry Ivankov, Junio C Hamano, Ramsay Jones, GIT Mailing-list
In-Reply-To: <20120202111628.GN3823@burratino>
On Thu, Feb 2, 2012 at 10:16 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Dmitry Ivankov wrote:
>> On Thu, Feb 2, 2012 at 4:59 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>>>
>>> Code using the argument names a and b just doesn't look right (not
>>> sure why!). Use more explicit names "offset" and "len" to make their
>>> type and function clearer.
>>
>> Well, it's still not clear. Given off_t a, size_t b, check that a+b
>> fits into type... which type?
>> "offset" and "length" don't imply that it's "type of offset" or maybe
>> "type of length".
>
> Hmm... in vector arithmetic, position (i.e., file offset) + displacement
> (i.e., size of chunk) = position (i.e., new file offset). Any ideas
> for making this clearer?
Maybe rename to check_offset_overflow to make it explicit?
--
David Barr
^ permalink raw reply
* Re: How to find and analyze bad merges?
From: Norbert Nemec @ 2012-02-02 11:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <87haz97c2k.fsf@thomas.inf.ethz.ch>
To be yet more precise:
My complaint is that you need this kind of sledge-hammer solutions to
analyze the situation. I, as an semi-expert with git did manage to find
the problem without even having to resort to bisect or manually redoing
the merge. My complaint is about the perspective of the
medium-experienced user who is completely puzzled by the fact that a
"git log <filename>" silently skips the critical merge commit.
Am 02.02.12 11:40, schrieb Thomas Rast:
> "norbert.nemec"<norbert.nemec@native-instruments.de> writes:
>
>> Thinking about a possible solution:
>>
>> Is there a way to re-do a merge-commit and diff the result against the
>> recorded merge without touching the working tree? This would be the
>> killer-feature to analyze a recorded merge-commit.
>
> git checkout M^
> git merge M^2
> git diff M HEAD
>
> You'd have to resolve conflicts though. If you want to skip that, I
> think you could still see some information if you said
>
> git reset
> git diff M
>
> to see the differences between the (unmerged, with conflict hunks) state
> in the worktree and M.
>
> (Remember to re-attach your HEAD after playing around like this.)
>
>> Am 02.02.12 09:16, schrieb Junio C Hamano:
>>>
>>> Bisect?
>>
>> This is not the point: My colleague knew exactly which commit
>> contained the bugfix. The trouble was finding out why this bugfix
>> disappeared even though everything indicated that it was cleanly
>> merged into the current branch.
>
> But that makes it a prime candidate for bisect: you know the good commit
> (the original bugfix), and you know that the newest version is bad.
> Bonus points if you have an automated test for it, in which case bisect
> can nail the offender while you get coffee.
>
> Or am I missing something?
>
--
Dr. Norbert Nemec
Teamleader Software Development
Tel +49-30-611035-1882
norbert.nemec@native-instruments.de
KOMPLETE 8 ULTIMATE - the premium NI producer collection
=> http://www.native-instruments.com/komplete8
TRAKTOR KONTROL S2 - the professional 2.1 DJ system
=> http://www.native-instruments.com/s2
->>>>>> NATIVE INSTRUMENTS - The Future of Sound <<<<<<-
Registergericht: Amtsgericht Charlottenburg
Registernummer: HRB 72458
UST.-ID.-Nr. DE 20 374 7747
Geschäftsführung: Daniel Haver (CEO), Mate Galic
^ permalink raw reply
* Re: [PATCH 1/3] vcs-svn: rename check_overflow arguments for clarity
From: Jonathan Nieder @ 2012-02-02 11:16 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: Junio C Hamano, Ramsay Jones, David Barr, GIT Mailing-list
In-Reply-To: <CA+gfSn9Exv3T0UCB-bFShmSvRCMgygVuWraiToR6ZjgOA_sZ8A@mail.gmail.com>
Dmitry Ivankov wrote:
> On Thu, Feb 2, 2012 at 4:59 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>>
>> Code using the argument names a and b just doesn't look right (not
>> sure why!). Use more explicit names "offset" and "len" to make their
>> type and function clearer.
>
> Well, it's still not clear. Given off_t a, size_t b, check that a+b
> fits into type... which type?
> "offset" and "length" don't imply that it's "type of offset" or maybe
> "type of length".
Hmm... in vector arithmetic, position (i.e., file offset) + displacement
(i.e., size of chunk) = position (i.e., new file offset). Any ideas
for making this clearer?
^ permalink raw reply
* Re: [PATCH 0/9] respect binary attribute in grep
From: Jeff King @ 2012-02-02 11:07 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Thomas Rast, Conrad Irwin, git,
Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <87vcnp5wkg.fsf@thomas.inf.ethz.ch>
On Thu, Feb 02, 2012 at 12:00:47PM +0100, Thomas Rast wrote:
> My original plan was to make use_threads git-global, instead of
> grep-global (and shift responsibility to the subsystems instead of their
> users), but that's just me and the patches aren't ready yet.
Yeah, having just dug into the threading code in grep a bit, I agree
that would be a saner approach. The locking is all bolted-on, so you end
up with these weird contracts between code, like the low-level grep code
asking anybody who might be multi-threading it to initialize the mutexes
to cover access to a totally different subsystem. I'd much rather each
subsystem just take care of itself.
-Peff
^ permalink raw reply
* [PATCH 3/3] vcs-svn: suppress a -Wtype-limits warning
From: Jonathan Nieder @ 2012-02-02 11:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, David Barr, GIT Mailing-list, Dmitry Ivankov
In-Reply-To: <20120202104128.GG3823@burratino>
On 32-bit architectures with 64-bit file offsets, gcc 4.3 and earlier
produce the following warning:
CC vcs-svn/sliding_window.o
vcs-svn/sliding_window.c: In function `check_overflow':
vcs-svn/sliding_window.c:36: warning: comparison is always false \
due to limited range of data type
The warning appears even when gcc is run without any warning flags
(this is gcc bug 12963). In later versions the same warning can be
reproduced with -Wtype-limits, which is implied by -Wextra.
On 64-bit architectures it really is possible for a size_t not to be
representable as an off_t so the check this is warning about is not
actually redundant. But even false positives are distracting. Avoid
the warning by making the "len" argument to check_overflow a
uintmax_t; no functional change intended.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
That's the end of the series. I hope it was entertaining.
Thoughts of all kinds welcome, as usual.
Jonathan
vcs-svn/sliding_window.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/vcs-svn/sliding_window.c b/vcs-svn/sliding_window.c
index fafa4a63..2f4ae60f 100644
--- a/vcs-svn/sliding_window.c
+++ b/vcs-svn/sliding_window.c
@@ -31,15 +31,15 @@ static int read_to_fill_or_whine(struct line_buffer *file,
return 0;
}
-static int check_overflow(off_t offset, size_t len)
+static int check_overflow(off_t offset, uintmax_t len)
{
if (len > maximum_signed_value_of_type(off_t))
return error("unrepresentable length in delta: "
- "%"PRIuMAX" > OFF_MAX", (uintmax_t) len);
+ "%"PRIuMAX" > OFF_MAX", len);
if (signed_add_overflows(offset, (off_t) len))
return error("unrepresentable offset in delta: "
"%"PRIuMAX" + %"PRIuMAX" > OFF_MAX",
- (uintmax_t) offset, (uintmax_t) len);
+ (uintmax_t) offset, len);
return 0;
}
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 1/3] vcs-svn: rename check_overflow arguments for clarity
From: Dmitry Ivankov @ 2012-02-02 11:05 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ramsay Jones, David Barr, GIT Mailing-list
In-Reply-To: <20120202105923.GJ3823@burratino>
Hi
On Thu, Feb 2, 2012 at 4:59 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>
> Code using the argument names a and b just doesn't look right (not
> sure why!). Use more explicit names "offset" and "len" to make their
> type and function clearer.
Well, it's still not clear. Given off_t a, size_t b, check that a+b
fits into type... which type?
"offset" and "length" don't imply that it's "type of offset" or maybe
"type of length".
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Split out from Ramsay's patch.
>
> vcs-svn/sliding_window.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/vcs-svn/sliding_window.c b/vcs-svn/sliding_window.c
> index 1bac7a4c..fafa4a63 100644
> --- a/vcs-svn/sliding_window.c
> +++ b/vcs-svn/sliding_window.c
> @@ -31,15 +31,15 @@ static int read_to_fill_or_whine(struct line_buffer *file,
> return 0;
> }
>
> -static int check_overflow(off_t a, size_t b)
> +static int check_overflow(off_t offset, size_t len)
> {
> - if (b > maximum_signed_value_of_type(off_t))
> + if (len > maximum_signed_value_of_type(off_t))
> return error("unrepresentable length in delta: "
> - "%"PRIuMAX" > OFF_MAX", (uintmax_t) b);
> + "%"PRIuMAX" > OFF_MAX", (uintmax_t) len);
> - if (signed_add_overflows(a, (off_t) b))
> + if (signed_add_overflows(offset, (off_t) len))
> return error("unrepresentable offset in delta: "
> "%"PRIuMAX" + %"PRIuMAX" > OFF_MAX",
> - (uintmax_t) a, (uintmax_t) b);
> + (uintmax_t) offset, (uintmax_t) len);
> return 0;
> }
>
> --
> 1.7.9
>
^ permalink raw reply
* [PATCH 2/3] vcs-svn: allow import of > 4GiB files
From: Jonathan Nieder @ 2012-02-02 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, David Barr, GIT Mailing-list, Dmitry Ivankov
In-Reply-To: <20120202104128.GG3823@burratino>
There is no reason in principle that an svn-format dump would not be
able to represent a file whose length does not fit in a 32-bit
integer. Use off_t consistently to represent file lengths (in place
of using uint32_t in some contexts) so we can handle that.
Most svn-fe code is already ready to do that without this patch and
passes values of type off_t around. The type mismatch from stragglers
was noticed with gcc -Wtype-limits.
While at it, tighten the parsing of the Text-content-length field to
make sure it is a number and does not overflow, and tighten other
overflow checks as that value is passed around and manipulated.
Inspired-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
vcs-svn/fast_export.c | 15 +++++++++------
vcs-svn/fast_export.h | 4 ++--
vcs-svn/svndump.c | 21 +++++++++++++++------
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 19d7c34c..b823b851 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -227,15 +227,18 @@ static long apply_delta(off_t len, struct line_buffer *input,
return ret;
}
-void fast_export_data(uint32_t mode, uint32_t len, struct line_buffer *input)
+void fast_export_data(uint32_t mode, off_t len, struct line_buffer *input)
{
+ assert(len >= 0);
if (mode == REPO_MODE_LNK) {
/* svn symlink blobs start with "link " */
+ if (len < 5)
+ die("invalid dump: symlink too short for \"link\" prefix");
len -= 5;
if (buffer_skip_bytes(input, 5) != 5)
die_short_read(input);
}
- printf("data %"PRIu32"\n", len);
+ printf("data %"PRIuMAX"\n", (uintmax_t) len);
if (buffer_copy_bytes(input, len) != len)
die_short_read(input);
fputc('\n', stdout);
@@ -297,12 +300,12 @@ int fast_export_ls(const char *path, uint32_t *mode, struct strbuf *dataref)
void fast_export_blob_delta(uint32_t mode,
uint32_t old_mode, const char *old_data,
- uint32_t len, struct line_buffer *input)
+ off_t len, struct line_buffer *input)
{
long postimage_len;
- if (len > maximum_signed_value_of_type(off_t))
- die("enormous delta");
- postimage_len = apply_delta((off_t) len, input, old_data, old_mode);
+
+ assert(len >= 0);
+ postimage_len = apply_delta(len, input, old_data, old_mode);
if (mode == REPO_MODE_LNK) {
buffer_skip_bytes(&postimage, strlen("link "));
postimage_len -= strlen("link ");
diff --git a/vcs-svn/fast_export.h b/vcs-svn/fast_export.h
index 43d05b65..aa629f54 100644
--- a/vcs-svn/fast_export.h
+++ b/vcs-svn/fast_export.h
@@ -14,10 +14,10 @@ void fast_export_begin_commit(uint32_t revision, const char *author,
const struct strbuf *log, const char *uuid,
const char *url, unsigned long timestamp);
void fast_export_end_commit(uint32_t revision);
-void fast_export_data(uint32_t mode, uint32_t len, struct line_buffer *input);
+void fast_export_data(uint32_t mode, off_t len, struct line_buffer *input);
void fast_export_blob_delta(uint32_t mode,
uint32_t old_mode, const char *old_data,
- uint32_t len, struct line_buffer *input);
+ off_t len, struct line_buffer *input);
/* If there is no such file at that rev, returns -1, errno == ENOENT. */
int fast_export_ls_rev(uint32_t rev, const char *path,
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index ca63760f..644fdc71 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -40,7 +40,8 @@
static struct line_buffer input = LINE_BUFFER_INIT;
static struct {
- uint32_t action, propLength, textLength, srcRev, type;
+ uint32_t action, propLength, srcRev, type;
+ off_t text_length;
struct strbuf src, dst;
uint32_t text_delta, prop_delta;
} node_ctx;
@@ -61,7 +62,7 @@ static void reset_node_ctx(char *fname)
node_ctx.type = 0;
node_ctx.action = NODEACT_UNKNOWN;
node_ctx.propLength = LENGTH_UNKNOWN;
- node_ctx.textLength = LENGTH_UNKNOWN;
+ node_ctx.text_length = -1;
strbuf_reset(&node_ctx.src);
node_ctx.srcRev = 0;
strbuf_reset(&node_ctx.dst);
@@ -209,7 +210,7 @@ static void handle_node(void)
{
const uint32_t type = node_ctx.type;
const int have_props = node_ctx.propLength != LENGTH_UNKNOWN;
- const int have_text = node_ctx.textLength != LENGTH_UNKNOWN;
+ const int have_text = node_ctx.text_length != -1;
/*
* Old text for this node:
* NULL - directory or bug
@@ -291,12 +292,12 @@ static void handle_node(void)
}
if (!node_ctx.text_delta) {
fast_export_modify(node_ctx.dst.buf, node_ctx.type, "inline");
- fast_export_data(node_ctx.type, node_ctx.textLength, &input);
+ fast_export_data(node_ctx.type, node_ctx.text_length, &input);
return;
}
fast_export_modify(node_ctx.dst.buf, node_ctx.type, "inline");
fast_export_blob_delta(node_ctx.type, old_mode, old_data,
- node_ctx.textLength, &input);
+ node_ctx.text_length, &input);
}
static void begin_revision(void)
@@ -409,7 +410,15 @@ void svndump_read(const char *url)
break;
case sizeof("Text-content-length"):
if (!constcmp(t, "Text-content-length")) {
- node_ctx.textLength = atoi(val);
+ char *end;
+ uintmax_t textlen;
+
+ textlen = strtoumax(val, &end, 10);
+ if (!isdigit(*val) || *end)
+ die("invalid dump: non-numeric length %s", val);
+ if (textlen > maximum_signed_value_of_type(off_t))
+ die("unrepresentable length in dump: %s", val);
+ node_ctx.text_length = (off_t) textlen;
break;
}
if (constcmp(t, "Prop-content-length"))
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 0/9] respect binary attribute in grep
From: Thomas Rast @ 2012-02-02 11:00 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, Conrad Irwin, git,
Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <20120202081747.GA10271@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [+cc Thomas, as I am mangling some of his recent work with my
> refactoring]
Mangling? I think it all looks very good.
My original plan was to make use_threads git-global, instead of
grep-global (and shift responsibility to the subsystems instead of their
users), but that's just me and the patches aren't ready yet.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v3 1/4] completion: be nicer with zsh
From: Felipe Contreras @ 2012-02-02 11:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jonathan Nieder, git, SZEDER Gábor, Junio C Hamano
In-Reply-To: <8739at8qw6.fsf@thomas.inf.ethz.ch>
On Thu, Feb 2, 2012 at 12:35 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, Feb 2, 2012 at 10:48 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>
>> Exactly, and "completion: avoid default value assignment on : true
>> command" tells *nothing* to most people. Why is this patch needed? Do
>> I care about it?
>>
>> OTOH "completion: be nicer with zsh" explains the purpose of the patch
>> and people that don't care about zsh can happily ignore it if they
>> want, and the ones that care about zsh might want to back port it, or
>> whatever.
>
> Perhaps you could compromise on
>
> completion: work around zsh word splitting bug in : ${foo:=$(bar)}
Yes, that sounds better, perhaps:
completion: work around zsh option propagation bug
>> | tl;dr: $__git_porcelain_commands = $__git_all_commands
>>
>> Wrapping it up, to make clear what happens.
>
> I think this is not good style for a commit message. Apart from the
> very trendy use of tl;dr, it doesn't even properly summarize the cause
> *or* the user-visible symptom. It just states how the confusion
> propagates somewhere in the middle of the code.
I don't think the cause or the user-visible symptom need any summary.
I was trying to summarize this:
---
This is because in zsh the following code:
for i in $__git_all_commands
would evaluate $__git_all_commands as a single word (with spaces),
${=__git_all_commands} should be used to do word splitting expansion
(unless SH_WORD_SPLIT is used).
sh emulation should take care of that, but the command expantion is
messing up with that.
---
--
Felipe Contreras
^ permalink raw reply
* [PATCH 1/3] vcs-svn: rename check_overflow arguments for clarity
From: Jonathan Nieder @ 2012-02-02 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, David Barr, GIT Mailing-list, Dmitry Ivankov
In-Reply-To: <20120202104128.GG3823@burratino>
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Code using the argument names a and b just doesn't look right (not
sure why!). Use more explicit names "offset" and "len" to make their
type and function clearer.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Split out from Ramsay's patch.
vcs-svn/sliding_window.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/vcs-svn/sliding_window.c b/vcs-svn/sliding_window.c
index 1bac7a4c..fafa4a63 100644
--- a/vcs-svn/sliding_window.c
+++ b/vcs-svn/sliding_window.c
@@ -31,15 +31,15 @@ static int read_to_fill_or_whine(struct line_buffer *file,
return 0;
}
-static int check_overflow(off_t a, size_t b)
+static int check_overflow(off_t offset, size_t len)
{
- if (b > maximum_signed_value_of_type(off_t))
+ if (len > maximum_signed_value_of_type(off_t))
return error("unrepresentable length in delta: "
- "%"PRIuMAX" > OFF_MAX", (uintmax_t) b);
+ "%"PRIuMAX" > OFF_MAX", (uintmax_t) len);
- if (signed_add_overflows(a, (off_t) b))
+ if (signed_add_overflows(offset, (off_t) len))
return error("unrepresentable offset in delta: "
"%"PRIuMAX" + %"PRIuMAX" > OFF_MAX",
- (uintmax_t) a, (uintmax_t) b);
+ (uintmax_t) offset, (uintmax_t) len);
return 0;
}
--
1.7.9
^ permalink raw reply related
* Re: [PATCH v3 1/4] completion: be nicer with zsh
From: Jonathan Nieder @ 2012-02-02 10:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: Felipe Contreras, git, SZEDER Gábor, Junio C Hamano
In-Reply-To: <20120202105006.GH3823@burratino>
Jonathan Nieder wrote:
> Thomas Rast wrote:
>> Perhaps you could compromise on
>>
>> completion: work around zsh word splitting bug in : ${foo:=$(bar)}
>
> Thanks, that looks like a good subject line to me.
Ah, except it's not a word splitting bug. It's an option propagation
bug.
^ permalink raw reply
* Re: [PATCH v3 1/4] completion: be nicer with zsh
From: Jonathan Nieder @ 2012-02-02 10:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: Felipe Contreras, git, SZEDER Gábor, Junio C Hamano
In-Reply-To: <8739at8qw6.fsf@thomas.inf.ethz.ch>
Thomas Rast wrote:
> Perhaps you could compromise on
>
> completion: work around zsh word splitting bug in : ${foo:=$(bar)}
Thanks, that looks like a good subject line to me. It gives a hint of
what the patch is trying to do, and it does not try to fool me into
thinking that if I use bash the patch does not affect me.
Felipe, I'm not going to respond to the rest of your message. Perhaps
someone more patient than I am will, or if someone has specific
questions for me, I'll be glad to help.
^ 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