* UI: git-tag should support -F as well
From: Han-Wen Nienhuys @ 2006-12-21 11:52 UTC (permalink / raw)
To: git
Working on a little darcs2git script, I found the following inconsistency
git-commit supports -m and -F
git-tag supports only -m
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2006-12-21 11:44 UTC (permalink / raw)
To: nigel; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <1166680407.3636.25.camel@nigel.suspend2.net>
Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2006-12-20 at 22:04 -0500, Jeff Garzik wrote:
>> I refreshed my git intro/cookbook for kernel hackers, at
>> http://linux.yyz.us/git-howto.html
>>
>> This describes most of the commands I use in day-to-day kernel hacking.
>> Let me know if there are glaring errors or missing key commands.
>
> Thanks for the work! I'd suggest also saying how to repack and cleanup.
Yes, I should mention repacking. When you say cleanup, what
specifically do you mean?
> Could also be a good idea to go through the steps for uploading to
> master.kernel.org or elsewhere?
Yes, push should be mentioned at the very least.
Jeff
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Johannes Schindelin @ 2006-12-21 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz5ib8eu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4909 bytes --]
Hi,
On Wed, 20 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre (4):
> make patch_delta() error cases a bit more verbose
> make git a bit less cryptic on fetch errors
> index-pack usage of mmap() is unacceptably slower on many OSes
> other than Linux
I assume that this line is indented manually, but ...
> clarify some error messages wrt unknown object types
>
> Robert Fitzsimons (1):
> gitweb: Show '...' links in "summary" view only if there are more items
this is not, in spite of being longer than 76 characters (Do I remember
correctly that this supposed to be the maximum length for lines in
emails?).
FWIW, I hacked a half-serious patch to wrap the lines automatically:
-- snipsnap --
[FWOT] shortlog: wrap long lines
If a oneline is longer than 76 characters, wrap it and indent with
9 instead of 6 spaces.
For the heck of it, assume UTF-8, and fall back to single-byte
encodings when finding that it cannot be UTF-8. (Not that it makes
a difference if you stick to ASCII.)
---
builtin-shortlog.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t4201-shortlog.sh | 44 ++++++++++++++++++++++++++++++++++++
2 files changed, 104 insertions(+), 1 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index edb4042..be5691e 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -276,6 +276,64 @@ static void get_from_rev(struct rev_info *rev, struct path_list *list)
}
+/* Wrap the text, if necessary. */
+static void print_oneline(const char *oneline, int indent, int indent2, int len)
+{
+ int i, count, count_utf8, last_space = -1, assume_utf8 = 1;
+
+ count = count_utf8 = 0;
+
+ for (;;) {
+ unsigned char c = (unsigned char)oneline[count++];
+ if (!c || isspace(c)) {
+ int cur = indent
+ + (assume_utf8 ? count_utf8 : count - 1);
+ if (cur < len || last_space < 0) {
+//printf("(%d)", cur);
+ if (last_space > 0)
+ putchar(' ');
+ else
+ for (i = 0; i < indent; i++)
+ putchar(' ');
+ for (i = last_space + 1; i < count - 1; i++)
+ putchar(oneline[i]);
+ if (!c) {
+ putchar('\n');
+ return;
+ }
+ last_space = count - 1;
+ count_utf8++;
+ } else {
+ putchar('\n');
+ for (oneline += last_space + 1;
+ isspace(*oneline); oneline++)
+ ; /* do nothing */
+ indent = indent2;
+ last_space = -1;
+ count = count_utf8 = 0;
+ }
+ continue;
+ }
+ if (assume_utf8 && c > 0x7f) {
+ int multi_byte_count = 1;
+ if ((c & 0xe0) == 0xc0)
+ multi_byte_count = 2;
+ else if ((c & 0xf0) == 0xe0)
+ multi_byte_count = 3;
+ else if ((c & 0xf8) == 0xf0)
+ multi_byte_count = 4;
+ else
+ assume_utf8 = 0;
+ for (i = 0; i < multi_byte_count - 1; i++)
+ if (!oneline[count + i])
+ assume_utf8 = 0;
+ if (assume_utf8)
+ count += multi_byte_count - 1;
+ }
+ count_utf8++;
+ }
+}
+
int cmd_shortlog(int argc, const char **argv, const char *prefix)
{
struct rev_info rev;
@@ -321,7 +379,8 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix)
} else {
printf("%s (%d):\n", list.items[i].path, onelines->nr);
for (j = onelines->nr - 1; j >= 0; j--)
- printf(" %s\n", onelines->items[j].path);
+ print_oneline(onelines->items[j].path,
+ 6, 9, 76);
printf("\n");
}
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
new file mode 100644
index 0000000..86a2295
--- /dev/null
+++ b/t/t4201-shortlog.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Johannes E. Schindelin
+#
+
+test_description='git-shortlog
+'
+
+. ./test-lib.sh
+
+echo 1 > a1
+git add a1
+tree=$(git write-tree)
+commit=$((echo "Test"; echo) | git commit-tree $tree)
+git update-ref HEAD $commit
+
+echo 2 > a1
+git commit -m "This is a very, very long first line for the commit message to see if it is wrapped correctly" a1
+
+# test if the wrapping is still valid when replacing all i's by treble clefs.
+echo 3 > a1
+git commit -m "$(echo "This is a very, very long first line for the commit message to see if it is wrapped correctly" | sed "s/i/1234/g" | tr 1234 '\360\235\204\236')" a1
+
+# now fsck up the utf8
+echo 4 > a1
+git commit -m "$(echo "This is a very, very long first line for the commit message to see if it is wrapped correctly" | sed "s/i/1234/g" | tr 1234 '\370\235\204\236')" a1
+
+git shortlog HEAD > out
+
+cat > expect << EOF
+A U Thor (4):
+ Test
+ This is a very, very long first line for the commit message to see if
+ it is wrapped correctly
+ Thð„žs ð„žs a very, very long fð„žrst lð„žne for the commð„žt message to see ð„žf
+ ð„žt ð„žs wrapped correctly
+ Thø„žs ø„žs a very, very long fø„žrst lø„žne for the commø„žt
+ message to see ø„žf ø„žt ø„žs wrapped correctly
+
+EOF
+
+test_expect_success 'shortlog wrapping' 'diff -u expect out'
+
+test_done
--
1.4.4.3.g610c-dirty
^ permalink raw reply related
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-21 11:39 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0612110459y4009ce7fl44ceaa4bad33edf3@mail.gmail.com>
[Cc: git@vger.kernel.org]
Catalin Marinas wrote:
> BTW, if it's not clear for me how to initially structure a patch
> series, I add everything to a patch and create underlying patches
> afterwards and pick hunks from the big one (usually manually, though
> native support in StGIT for this would be good, as someone pointed out
> on this list). If all the hunks in the big patch were added to other
> patches, pushing the big one should result in an empty patch
> automatically (because of the three-way merging) and can be safely
> removed.
Perhaps this calls for "stg duplicate" command, which would result
in duplicating patch (perhaps one would need to provide name for
the first patch, and optionally laso for second patch) in such way
that first copy would be on top of aplied stack, and second copy
(the duplicate, with an old name) would be at the bottom of the deck
of unapplied patches.
This way if you want to for example split patch into two, you would
do
$ stg duplicate new-name
$ edit files
$ stg refresh
$ stg push
And similarly (with more duplicates) if you want to split it more.
What do you think about this?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] fix vc git
From: Jakub Narebski @ 2006-12-21 11:32 UTC (permalink / raw)
To: git
In-Reply-To: <8e745ecf0612210325m72a569d7k370dd5953ccf6f27@mail.gmail.com>
Duncan Mak wrote:
> - (when dir (cd dir))
> + (if (file-exists-p dir) (cd dir))
Adding `file-exist-p' is good, but there is no need to change
`when' to `if'.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
From: Marco Roeland @ 2006-12-21 11:28 UTC (permalink / raw)
To: git
Cc: Terje Sten Bjerkseth, Randal L. Schwartz, Junio C Hamano,
Linus Torvalds, Rocco Rutte
In-Reply-To: <20061221103938.GA7055@fiberbit.xs4all.nl>
Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of
available functions and symbols. This can not be cured by adding extra
defines in any way. So there really is only the choice between _not_
defining this symbol on Mac OS X or restricting our usage of functions
and symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE.
The first seems better.
Note the last three lines from this following literal code snippet in
/usr/include/sys/cdefs.h from the Apple Darwin sources:
* By default newly complied code will actually get the same symbols
* that the old code did. Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,
* or _POSIX_C_SOURCE will give you the new symbols. Defining _XOPEN_SOURCE
* or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of
* Apple's APIs.
We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!
The preferred way of checking specific Apple specific issues is by using
the __APPLE__ predefined macro.
The extra define _XOPEN_SOURCE_EXTENDED does only affect some headers
(like the /usr/include/curses.h header) and can stay.
FreeBSD 6 requires the __BSD_VISIBLE flag for fchmod(), IPPROTO_IPV6 and
more which is only properly set by <sys/cdefs.h> if _POSIX_C_SOURCE
isn't present. However, _POSIX_C_SOURCE is defined if _XOPEN_SOURCE is
defined and >=500.
As a solution, simply don't define _XOPEN_SOURCE for FreeBSD and continue
with its defaults.
Author: Terje Sten Bjerkseth <terje@bjerkseth.org>
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
---
git-compat-util.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..6f46f36 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,7 +11,14 @@
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+#if !defined(__APPLE__) && !defined(__FreeBSD)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
+#else
+ /*
+ * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available
+ * functions and symbols.
+ */
+#endif
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#define _BSD_SOURCE
--
1.4.4.2.g81597-dirty
^ permalink raw reply related
* [PATCH] fix vc git
From: Duncan Mak @ 2006-12-21 11:25 UTC (permalink / raw)
To: git
Fix vc-git.el to not cd into a non-existent directory.
---
contrib/emacs/vc-git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
base 54851157acf707eb953eada2a84830897dde5c1d
last 9172c26ece749fc4289eeb89ef45c35936c5a869
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index 8b6361922fd6e6a2fcd9acb20fd54f5b645b36f0..d3ba93325255aea3dc52187dd703d7a8
63cd6e5d 100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -58,7 +58,7 @@
(with-temp-buffer
(let* ((dir (file-name-directory file))
(name (file-relative-name file dir)))
- (when dir (cd dir))
+ (if (file-exists-p dir) (cd dir))
(and (ignore-errors (eq 0 (call-process "git" nil '(t nil) nil "ls-files"
"-c" "-z" "--" name)))
(let ((str (buffer-string)))
(and (> (length str) (length name))
--
1.4.4.1
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Peter Baumann @ 2006-12-21 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <87tzzp3fgh.wl%cworth@cworth.org>
On 2006-12-21, Carl Worth <cworth@cworth.org> wrote:
> --pgp-sign-Multipart_Wed_Dec_20_22:55:50_2006-1
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 20 Dec 2006 15:36:51 -0800, Junio C Hamano wrote:
>> Do you have comments on recent changes (both on 'master' and
>> some parts of 'next') from teachability point of view? I think
>> you are "the guilty guy" who defined the theme for v1.5.0 to be
>> "usability and teachability" ;-).
>
> I'm flattered to be blamed for what I consider a very good theme for
> the release.
>
> I don't have a lot of detailed comments right now other than to repeat
> a "good job!" to everyone who has done a lot to improve things lately,
> (coming up with more use-oriented documentation, adding a reasonable
> shorthand "add"[*] for update-index, cleaning up a lot of bad error
> message and needless spew, making much more reasonable default clone
> behavior, etc. etc.). I think git's really come a long ways as far as
> usability and teachability, (while nothing fundamental has really
> changed and old-time users should hardly notice anything different).
>
> I think I'll have a few minor tweaks to suggest to the documentation
> if I get a chance to take a detailed pass over it, (which I hope to do
> before the new year).
>
> And I'd definitely like to enable "git checkout <revision>" with a new
> complaint on git-commit before the 1.5 release. I'll see if I can't
> find time to work on implementing that.
>
> -Carl
>
> [*] I'm still somewhat unsettled that the "new" add command conflates
> the notions of adding content into the index for paths that previously
> didn't exist in the index with the notion of updating the content in
> the index for paths that did exist already. I think those notions are
> generally distinct from the users point of view---the first changes a
> file's state in a fundamental way, (from "untracked" to "tracked"),
> while the second merely updates its content with no change to its
> state.
>
> One way to see the distinction is to imagine two different useful
> operations "add all untracked file paths to the index" and "update
> content for all tracked paths". If we had separate commands for 'add'
> and 'update' then it would be natural to express these two variants
> with "git add --all" and "git update --all".
>
I'm also not so confident about mixing "add NEW files" with "updating
the contents of already known files". I'd prefere to seperate those two
meanings. Having two similarly named files in my workdir, I could easly
misspell the filename and wouldn't even notice that I have added a NEW
file inspite of refreshing the contents of an already existing file.
> As things stand now, the first operation is available already with
> "git add .", (and oddly, with "git add", and I agree that should be
> removed). Meanwhile the second operation is not currently available in
> git, (but I recently proposed it as "git add -a|--all" in response to
> a request). As pointed out in that thread, there's a bit of a problem
> in that "git add --all" is really easy to mistake for a command that
> would add all untracked files to the index, (since it's when adding
> new paths that people will most often use "git add" so it will
> naturally be associated with adding new paths). It's less likely for
> users to establish the "update content" notion of "git add" since it
> often won't be needed at all, (tutorials and the git-commit
> documentation recommend "commit -a" to avoid the need to use "git add"
> in its updating sense).
>
> So, to summarize, I think it's good to have a much shorter command to
> type than "update-index" for the update-content-of-path-in-index
> operation. So using "add" for this is better than "update-index"
> already. And if that's how it stays, I can certainly live with it.
>
> But I think it might be even better if the updating notion were on a
> separate command name (update ? stage ?), and this in spite of the
> fact that fewer commands is generally better for learnability.
>
What about 'refresh'?
> It's not a major issue---and it's nothing that I would make a big fuss
> over, so feel free to ignore it if it appears a non-issue to you.
>
> --pgp-sign-Multipart_Wed_Dec_20_22:55:50_2006-1
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
>
>
> --pgp-sign-Multipart_Wed_Dec_20_22:55:50_2006-1--
^ permalink raw reply
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Jakub Narebski @ 2006-12-21 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <200612211623.14236.litvinov2004@gmail.com>
Alexander Litvinov wrote:
>>> What do you think about a patch that makes git-commit-tree call iconv on
>>> its input to get it to UTF-8 (or any other charset).
>>
>> We had this discussion over and over again. Last time (I think) was here:
>> http://article.gmane.org/gmane.comp.version-control.git/11710
>> Summary: we do not want to force the use of utf8.
>
> May we can add new header into commit with commit text encoding ?
I think it should be repository-wide decision. And we have
i18n.commitEncoding configuration variable (perhaps it should be propagated
on clone?).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Don't define _XOPEN_SOURCE to unbreak compilation on FreeBSD
From: Rocco Rutte @ 2006-12-21 10:47 UTC (permalink / raw)
To: git; +Cc: Rocco Rutte
FreeBSD 6 requires the __BSD_VISIBLE flag for fchmod(), IPPROTO_IPV6 and
more which is only properly set by <sys/cdefs.h> if _POSIX_C_SOURCE
isn't present. However, _POSIX_C_SOURCE is defined if _XOPEN_SOURCE is
defined and >=500.
As a solution, simply don't define _XOPEN_SOURCE for FreeBSD and continue
with its defaults.
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
---
git-compat-util.h | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..27d3b89 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,7 +11,12 @@
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
-#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
+#if !defined(__FreeBSD__)
+#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500,
+ * OpenBSD needs 600 for S_ISLNK(),
+ * FreeBSD 6 doesn't like it
+ */
+#endif
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#define _BSD_SOURCE
--
1.4.4.2.g9474f
^ permalink raw reply related
* [PATCH] Do not define _XOPEN_SOURCE on MacOSX as it is too restricting there
From: Marco Roeland @ 2006-12-21 10:39 UTC (permalink / raw)
To: Terje Sten Bjerkseth
Cc: Randal L. Schwartz, Junio C Hamano, Linus Torvalds, git
In-Reply-To: <caf068570612201735o776e01a8he2e9ab90fc2ee4f@mail.gmail.com>
Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of
available functions and symbols. This can not be cured by adding extra
defines in any way. So there really is only the choice between _not_
defining this symbol on Mac OS X or restricting our usage of functions
and symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE.
The first seems better.
Note the last three lines from this following literal code snippet in
/usr/include/sys/cdefs.h from the Apple Darwin sources:
* By default newly complied code will actually get the same symbols
* that the old code did. Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,
* or _POSIX_C_SOURCE will give you the new symbols. Defining _XOPEN_SOURCE
* or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of
* Apple's APIs.
We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!
The preferred way of checking specific Apple specific issues is by using
the __APPLE__ predefined macro.
The extra define _XOPEN_SOURCE_EXTENDED does only affect some headers
(like the /usr/include/curses.h header) and can stay.
Patch from Terje Sten Bjerkseth, only added a comment.
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..f056d20 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,7 +11,11 @@
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+#if !defined __APPLE__
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
+#else
+ /* On Darwin defining _XOPEN_SOURCE always restricts available functions */
+#endif
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#define _BSD_SOURCE
^ permalink raw reply related
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Alexander Litvinov @ 2006-12-21 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Uwe Kleine-König, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612211050450.19693@wbgn013.biozentrum.uni-wuerzburg.de>
> > What do you think about a patch that makes git-commit-tree call iconv on
> > its input to get it to UTF-8 (or any other charset).
>
> We had this discussion over and over again. Last time (I think) was here:
> http://article.gmane.org/gmane.comp.version-control.git/11710
> Summary: we do not want to force the use of utf8.
May we can add new header into commit with commit text encoding ?
^ permalink raw reply
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Santi Béjar @ 2006-12-21 10:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Uwe Kleine-König, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612211050450.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/21/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 21 Dec 2006, Uwe Kleine-König wrote:
>
> > Junio C Hamano wrote:
> > > Me, keyboard and Emacs screwed up and stored it in ISO-2022
> > > instead of UTF-8. Sorry.
> > It's a pity, but too late to change.[1]
> >
> > What do you think about a patch that makes git-commit-tree call iconv on
> > its input to get it to UTF-8 (or any other charset).
>
> We had this discussion over and over again. Last time (I think) was here:
>
> http://article.gmane.org/gmane.comp.version-control.git/11710
>
> Summary: we do not want to force the use of utf8.
>
Maybe git could have an example of the hook "commit-msg" that checks
that the commit message is in certain charset.
Santi
^ permalink raw reply
* Re: [PATCH] Define -D__BSD_VISIBLE for FreeBSD
From: Rocco Rutte @ 2006-12-21 10:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vk60lbnvj.fsf@assigned-by-dhcp.cox.net>
Hi,
* Junio C Hamano [06-12-21 01:26:56 -0800] wrote:
>We've changed this exact area quite heavily during the last
>24-hours (not in Makefile but in git-compat-util.h). Do you
>see the problem with the latest 'master'?
Now when looking at sys/cdefs.h, the
85023577a8f4b540aa64aa37f6f44578c0c305a3 commit seems to have broken
things. So the patch should be ignored and I'll try to come up with a
better one not using implementation-defined __-macros...
bye, Rocco
--
:wq!
^ permalink raw reply
* Re: specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Johannes Schindelin @ 2006-12-21 9:51 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Junio C Hamano, git
In-Reply-To: <20061221085907.GA2244@cepheus>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 544 bytes --]
Hi,
On Thu, 21 Dec 2006, Uwe Kleine-König wrote:
> Junio C Hamano wrote:
> > Me, keyboard and Emacs screwed up and stored it in ISO-2022
> > instead of UTF-8. Sorry.
> It's a pity, but too late to change.[1]
>
> What do you think about a patch that makes git-commit-tree call iconv on
> its input to get it to UTF-8 (or any other charset).
We had this discussion over and over again. Last time (I think) was here:
http://article.gmane.org/gmane.comp.version-control.git/11710
Summary: we do not want to force the use of utf8.
Hth,
Dscho
^ permalink raw reply
* Re: [RFH/RFT] git-rm: update to saner semantics
From: Jakub Narebski @ 2006-12-21 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vwt4lboa2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> -"git-rm [-n] [-v] [-f] <filepattern>...";
> +"git-rm [-n] [-f] [--cached] <filepattern>...";
Why do we lost -v (for verbose)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Attempt to make git-checkout man page a bit more clear.
From: Jakub Narebski @ 2006-12-21 9:34 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP071BBC53B5CE7917CE8DE1AECE0@CEZ.ICE>
Sean wrote:
> On Wed, 20 Dec 2006 23:47:42 -0800
> Junio C Hamano <junkio@cox.net> wrote:
>
>> The 'restore from arbitrary tree-ish' form does not take -m as
>> far as I know.
>>
>> Although it might be interesting to do a single-file three-way
>> merge, I do not think the command is _checkout_ anymore once it
>> starts doing that.
>
> Yeah, I should have caught that. As well, your explanation makes me
> wonder if it makes sense to change <branch> in the third form to
> <tree-ish> ? Would you like an updated patch or will you just make
> the touch up(s) yourself?
Better not, because if I remember correctly
$ git checkout [--] <paths>...
would replace the contents of the named paths in your
working tree from the index, while
$ git checkout <commit-ish> [--] <paths>...
would replace the contents of the named paths in your
working tree from the given commit (given branch, perhaps given
tree-ish).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Define -D__BSD_VISIBLE for FreeBSD
From: Junio C Hamano @ 2006-12-21 9:26 UTC (permalink / raw)
To: Rocco Rutte; +Cc: git
In-Reply-To: <11666916581935-git-send-email-pdmef@gmx.net>
Rocco Rutte <pdmef@gmx.net> writes:
> FreeBSD (6-STABLE) "hides" many declarations (like fchmod(), IPPROTO_IPV6,
> etc.) within '#ifdef __BSD_VISIBLE' blocks. Without this flag, compilation
> will produce lots of warnings and will even fail to compile daemon.c
> since IPPROTO_IPV6 isn't available without it.
I've looked at OpenBSD header files and my impression was that
the symbol __BSD_VISIBLE was pretty much internal to the
implementation, and the programs are not expected to set it
except by defining more public feature macros, such as
_BSD_SOURCE. So I feel a bit uneasy about your approach.
We've changed this exact area quite heavily during the last
24-hours (not in Makefile but in git-compat-util.h). Do you
see the problem with the latest 'master'?
^ permalink raw reply
* [PATCH] hooks/commit-msg: add example to add Signed-off-by line to message
From: Andy Parkins @ 2006-12-21 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vejqufonm.fsf@assigned-by-dhcp.cox.net>
After checking to see if the commit message already has the target
signed-off-by (for example in --amend commits), this patch generates a
signed off by line from the repository owner and adds it to the commit
message.
Based on Johannes Schindelin's earlier patch to perform the same
function.
Originally, this was done in the pre-commit hook but Junio pointed out
that the commit-msg hook allows the message to be edited. This has the
aditional advantage that the commit-msg hook gets passed the name of the
message file as a parameter, so it doesn't have to figure out GIT_DIR for
itself.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
templates/hooks--commit-msg | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/templates/hooks--commit-msg b/templates/hooks--commit-msg
index 0b906ca..ce76bdf 100644
--- a/templates/hooks--commit-msg
+++ b/templates/hooks--commit-msg
@@ -8,6 +8,11 @@
#
# To enable this hook, make this file executable.
+# Uncomment the below to add a Signed-off-by line to the message.
+#SOB=$(git var GIT_AUTHOR_IDENT | \
+# sed -n "s/^\(.*\) [0-9]\+ [-+][0-9]\+$/Signed-off-by: \1/p")
+#grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1"
+
# This example catches duplicate Signed-off-by lines.
test "" = "$(grep '^Signed-off-by: ' "$1" |
--
1.4.4.2.g120e3
^ permalink raw reply related
* Re: warning merge message
From: Johannes Schindelin @ 2006-12-21 9:23 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <867728.44872.qm@web31814.mail.mud.yahoo.com>
Hi,
On Wed, 20 Dec 2006, Luben Tuikov wrote:
> Can we please eliminate this f@#$ing message:
> Warning: No merge candidate found because value of config option
> "branch.master.merge" does not match any remote branch fetched.
Well, you can always tell git explicitely what you want. I.e. specify the
remote _and_ the branch you want to merge.
BTW I am still waiting for your test results regarding the segmentation
fault of merge-recursive.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add a test for git-rerere
From: Johannes Schindelin @ 2006-12-21 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvpej3i.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Thu, 21 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > +rm $rr/postimage
> >> > +echo -ne "$sha1\ta1\0" > .git/rr-cache/MERGE_RR
> >>
> >> Hmmmmmm. I've stayed away from "echo -e" so far...
> >
> > Rather do it with tr? Like this:
> >
> > echo -n "$sha1 a1X" | tr X '\0' > .git/rr-cache/MERGE_RR
>
> Bog-standard old timer's way is not to use -n nor X but just do:
>
> echo "stuff you want to NUL terminate" | tr '\012' '\0'
>
> > Is $((1+2)) portable enough? I always thought this is a bashism...
>
> That's also in ksh and dash (and in POSIX) and recent updates to
> out *.sh scripts make liberal use of them. As long as you do
> not overflow you are fine.
Done.
BTW I think this test should be 3/3 instead of 2/3, since it fails
with the Perl rerere if you do not have the required modules
installed.
t/t4200-rerere.sh | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 154 insertions(+), 0 deletions(-)
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
new file mode 100644
index 0000000..5ee5b23
--- /dev/null
+++ b/t/t4200-rerere.sh
@@ -0,0 +1,154 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Johannes E. Schindelin
+#
+
+test_description='git-rerere
+'
+
+. ./test-lib.sh
+
+cat > a1 << EOF
+Whether 'tis nobler in the mind to suffer
+The slings and arrows of outrageous fortune,
+Or to take arms against a sea of troubles,
+And by opposing end them? To die: to sleep;
+No more; and by a sleep to say we end
+The heart-ache and the thousand natural shocks
+That flesh is heir to, 'tis a consummation
+Devoutly to be wish'd.
+EOF
+
+git add a1
+git commit -q -a -m initial
+
+git checkout -b first
+cat >> a1 << EOF
+To die, to sleep;
+To sleep: perchance to dream: ay, there's the rub;
+For in that sleep of death what dreams may come
+When we have shuffled off this mortal coil,
+Must give us pause: there's the respect
+That makes calamity of so long life;
+EOF
+git commit -q -a -m first
+
+git checkout -b second master
+git show first:a1 | sed 's/To die, t/To die! T/' > a1
+git commit -q -a -m second
+
+# activate rerere
+mkdir .git/rr-cache
+
+test_expect_failure 'conflicting merge' 'git pull . first'
+
+sha1=4f58849a60b4f969a2848966b6d02893b783e8fb
+rr=.git/rr-cache/$sha1
+test_expect_success 'recorded preimage' "grep ======= $rr/preimage"
+
+test_expect_success 'no postimage or thisimage yet' \
+ "test ! -f $rr/postimage -a ! -f $rr/thisimage"
+
+git show first:a1 > a1
+
+cat > expect << EOF
+--- a/a1
++++ b/a1
+@@ -6,11 +6,7 @@
+ The heart-ache and the thousand natural shocks
+ That flesh is heir to, 'tis a consummation
+ Devoutly to be wish'd.
+-<<<<<<<
+-To die! To sleep;
+-=======
+ To die, to sleep;
+->>>>>>>
+ To sleep: perchance to dream: ay, there's the rub;
+ For in that sleep of death what dreams may come
+ When we have shuffled off this mortal coil,
+EOF
+
+git rerere diff > out
+
+test_expect_success 'rerere diff' 'diff -u expect out'
+
+cat > expect << EOF
+a1
+EOF
+
+git rerere status > out
+
+test_expect_success 'rerere status' 'diff -u expect out'
+
+test_expect_success 'commit succeeds' \
+ "git commit -q -a -m 'prefer first over second'"
+
+test_expect_success 'recorded postimage' "test -f $rr/postimage"
+
+git checkout -b third master
+git show second^:a1 | sed 's/To die: t/To die! T/' > a1
+git commit -q -a -m third
+
+test_expect_failure 'another conflicting merge' 'git pull . first'
+
+git show first:a1 | sed 's/To die: t/To die! T/' > expect
+test_expect_success 'rerere kicked in' "! grep ======= a1"
+
+test_expect_success 'rerere prefers first change' 'diff -u a1 expect'
+
+rm $rr/postimage
+echo "$sha1 a1" | tr '\012' '\0' > .git/rr-cache/MERGE_RR
+
+test_expect_success 'rerere clear' 'git rerere clear'
+
+test_expect_success 'clear removed the directory' "test ! -d $rr"
+
+mkdir $rr
+echo Hello > $rr/preimage
+echo World > $rr/postimage
+
+sha2=4000000000000000000000000000000000000000
+rr2=.git/rr-cache/$sha2
+mkdir $rr2
+echo Hello > $rr2/preimage
+
+case "$(date -d @11111111 +%s 2>/dev/null)" in
+[1-9]*)
+ # it is a recent GNU date. good.
+ now=$(date +%s)
+ almost_15_days_ago=$(($now+60-15*86400))
+ just_over_15_days_ago=$(($now-1-15*86400))
+ almost_60_days_ago=$(($now+60-60*86400))
+ just_over_60_days_ago=$(($now-1-60*86400))
+ predate1="$(date -d "@$almost_60_days_ago" +%c)"
+ predate2="$(date -d "@$almost_15_days_ago" +%c)"
+ postdate1="$(date -d "@$just_over_60_days_ago" +%c)"
+ postdate2="$(date -d "@$just_over_15_days_ago" +%c)"
+ ;;
+*)
+ # it is not GNU date. oh, well.
+ predate1="$(date)"
+ predate2="$(date)"
+ postdate1='1 Oct 2006 00:00:00'
+ postdate2='1 Dec 2006 00:00:00'
+esac
+
+touch -m -d "$predate1" $rr/preimage
+touch -m -d "$predate2" $rr2/preimage
+
+test_expect_success 'garbage collection (part1)' 'git rerere gc'
+
+test_expect_success 'young records still live' \
+ "test -f $rr/preimage -a -f $rr2/preimage"
+
+touch -m -d "$postdate1" $rr/preimage
+touch -m -d "$postdate2" $rr2/preimage
+
+test_expect_success 'garbage collection (part2)' 'git rerere gc'
+
+test_expect_success 'old records rest in peace' \
+ "test ! -f $rr/preimage -a ! -f $rr2/preimage"
+
+test_done
+
+
^ permalink raw reply related
* [RFH/RFT] git-rm: update to saner semantics
From: Junio C Hamano @ 2006-12-21 9:18 UTC (permalink / raw)
To: git
This updates the "git rm" command with saner semantics suggested
on the list earlier with:
Message-ID: <Pine.LNX.4.64.0612020919400.3476@woody.osdl.org>
Message-ID: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>
The command still validates that the given paths all talk about
sensible paths to avoid mistakes (e.g. "git rm fiel" when the
user meant to remove "file" would error out), and it has further
safety checks described next. The biggest difference is that
the paths are removed from both index and from the working tree
(if you have an exotic need to remove paths only from the index,
you can use the --cached option).
The command refuses to remove if the copy on the working tree
does not match the index, or if the index and the HEAD does not
match. You can defeat this check with -f option.
This safety check has two exceptions: if the working tree file
does not exist to begin with, that technically does not match
the index but it is allowed. This is to allow this CVS style
command sequence:
rm <path> && git rm <path>
Also if the index is unmerged at the <path>, you can use "git rm
<path>" to declare that the result of the merge loses that path,
and the above safety check does not trigger; requiring the file
to match the index in this case forces the user to do "git
update-index file && git rm file", which is just crazy.
---
* This has seen only very limited test, so testing, adjusting the
test case t/t3600-rm.sh (possibly others) to the updated
semantics and documentation updates are still needed.
Also it lacks the "require -r for recursive behaviour" safety
valve. I think that is a sane thing to add.
Volunteers?
builtin-rm.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 85 insertions(+), 18 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 33d04bd..3927d93 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -9,7 +9,7 @@
#include "cache-tree.h"
static const char builtin_rm_usage[] =
-"git-rm [-n] [-v] [-f] <filepattern>...";
+"git-rm [-n] [-f] [--cached] <filepattern>...";
static struct {
int nr, alloc;
@@ -41,12 +41,66 @@ static int remove_file(const char *name)
return ret;
}
+static int check_local_mod(unsigned char *head)
+{
+ /* items in list are already sorted in the cache order,
+ * so we could do this a lot more efficiently by using
+ * tree_desc based traversal if we wanted to, but I am
+ * lazy, and who cares if removal of files is a tad slower
+ * than theoretical maximum speed?
+ */
+ int i, no_head;
+ int errs = 0;
+
+ no_head = is_null_sha1(head);
+ for (i = 0; i < list.nr; i++) {
+ struct stat st;
+ int pos;
+ struct cache_entry *ce;
+ const char *name = list.name[i];
+ unsigned char sha1[20];
+ unsigned mode;
+
+ pos = cache_name_pos(name, strlen(name));
+ if (pos < 0)
+ continue; /* removing unmerged entry */
+ ce = active_cache[pos];
+
+ if (lstat(ce->name, &st) < 0) {
+ if (errno != ENOENT)
+ fprintf(stderr, "warning: '%s': %s",
+ ce->name, strerror(errno));
+ /* It already vanished from the working tree */
+ continue;
+ }
+ else if (S_ISDIR(st.st_mode)) {
+ /* if a file was removed and it is now a
+ * directory, that is the same as ENOENT as
+ * far as git is concerned; we do not track
+ * directories.
+ */
+ continue;
+ }
+ if (ce_match_stat(ce, &st, 0))
+ errs = error("'%s' has local modifications "
+ "(hint: try -f)", ce->name);
+ if (no_head)
+ continue;
+ get_tree_entry(head, name, sha1, &mode);
+ if (ce->ce_mode != create_ce_mode(mode) ||
+ hashcmp(ce->sha1, sha1))
+ errs = error("'%s' has changes staged in the index "
+ "(hint: try -f)", name);
+ }
+ return errs;
+}
+
static struct lock_file lock_file;
int cmd_rm(int argc, const char **argv, const char *prefix)
{
int i, newfd;
- int verbose = 0, show_only = 0, force = 0;
+ int show_only = 0, force = 0, index_only = 0;
const char **pathspec;
char *seen;
@@ -62,23 +116,18 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (*arg != '-')
break;
- if (!strcmp(arg, "--")) {
+ else if (!strcmp(arg, "--")) {
i++;
break;
}
- if (!strcmp(arg, "-n")) {
+ else if (!strcmp(arg, "-n"))
show_only = 1;
- continue;
- }
- if (!strcmp(arg, "-v")) {
- verbose = 1;
- continue;
- }
- if (!strcmp(arg, "-f")) {
+ else if (!strcmp(arg, "--cached"))
+ index_only = 1;
+ else if (!strcmp(arg, "-f"))
force = 1;
- continue;
- }
- usage(builtin_rm_usage);
+ else
+ usage(builtin_rm_usage);
}
if (argc <= i)
usage(builtin_rm_usage);
@@ -105,8 +154,26 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
}
/*
+ * If not forced, the file, the index and the HEAD (if exists)
+ * must match; but the file can already been removed, since
+ * this sequence is a natural "novice" way:
+ *
+ * rm F; git fm F
+ *
+ * Further, if HEAD commit exists, "diff-index --cached" must
+ * report no changes unless forced.
+ */
+ if (!force) {
+ unsigned char sha1[20];
+ if (get_sha1("HEAD", sha1))
+ hashclr(sha1);
+ if (check_local_mod(sha1))
+ exit(1);
+ }
+
+ /*
* First remove the names from the index: we won't commit
- * the index unless all of them succeed
+ * the index unless all of them succeed.
*/
for (i = 0; i < list.nr; i++) {
const char *path = list.name[i];
@@ -121,14 +188,14 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
return 0;
/*
- * Then, if we used "-f", remove the filenames from the
- * workspace. If we fail to remove the first one, we
+ * Then, unless we used "--cache", remove the filenames from
+ * the workspace. If we fail to remove the first one, we
* abort the "git rm" (but once we've successfully removed
* any file at all, we'll go ahead and commit to it all:
* by then we've already committed ourselves and can't fail
* in the middle)
*/
- if (force) {
+ if (!index_only) {
int removed = 0;
for (i = 0; i < list.nr; i++) {
const char *path = list.name[i];
^ permalink raw reply related
* Re: [RFC] gitweb wishlist and TODO list (part 1)
From: Jakub Narebski @ 2006-12-21 9:18 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: git, Kernel Org Admin, Petr Baudis
In-Reply-To: <20061221032216.GF17864@localhost>
Robert Fitzsimons wrote:
>> * Cache validation and infinite cache for unchanging pages
>>
>> By itself cache validation would not bring much performance boost (for
>> gitweb installations with large traffic), but with the reverse proxy,
>> aka. caching engine, aka. HTTP accelerator in front of server this could
>> help a lot.
BTW in mod_perl cache validation is as simple as using meets_condition()
method on request object after we send at least one of validator
headers (Last-Modified:, ETag:)... but this would mean that cache
validation would be available only when under mod_perl...
> There is no need for extra servers to provide server side caching.
> Apache2 includes suitable modules (mod_cache) which can be configured to
> cache in memory or disk the pages generated by gitweb.
[...]
> mod_cache will only cache pages with a query string in the url if they
> have an expires header. So we can put a temporary hack in using
> mod_expires until gitweb sets an appropriate value.
>From the discussion in the
"Re: kernel.org mirroring (Re: [GIT PULL] MMC update)"
http://thread.gmane.org/gmane.comp.version-control.git/33604
thread Apache mod_cache doesn't bring much. Perhaps because of the above...
although adding artificial expires header seems a bit like a hack.
> Also the content type would need to be change to just return text/html
> or MSIE will do the wrong think if it's given a application/xhtml+xml
> page.
>From gitweb.perl:
# require explicit support from the UA if we are to send the page as
# 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
# we have to do this because MSIE sometimes globs '*/*', pretending to
# support xhtml+xml but choking when it gets what it asked for.
This was added by Alp Toker <alp@atoker.com> in f6801d669ee11:
"gitweb: Send XHTML as 'application/xhtml+xml' where possible"
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Define -D__BSD_VISIBLE for FreeBSD
From: Rocco Rutte @ 2006-12-21 9:00 UTC (permalink / raw)
To: git; +Cc: Rocco Rutte
FreeBSD (6-STABLE) "hides" many declarations (like fchmod(), IPPROTO_IPV6,
etc.) within '#ifdef __BSD_VISIBLE' blocks. Without this flag, compilation
will produce lots of warnings and will even fail to compile daemon.c
since IPPROTO_IPV6 isn't available without it.
>From looking at some include files of OpenBSD and NetBSD (via cvsweb)
they don't seem to need this flag.
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 7651104..46c49e0 100644
--- a/Makefile
+++ b/Makefile
@@ -366,7 +366,7 @@ ifeq ($(uname_O),Cygwin)
endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV = YesPlease
- BASIC_CFLAGS += -I/usr/local/include
+ BASIC_CFLAGS += -I/usr/local/include -D__BSD_VISIBLE
BASIC_LDFLAGS += -L/usr/local/lib
endif
ifeq ($(uname_S),OpenBSD)
--
1.4.4.2.g9474f
^ permalink raw reply related
* specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Uwe Kleine-König @ 2006-12-21 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac1jre1u.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> Me, keyboard and Emacs screwed up and stored it in ISO-2022
> instead of UTF-8. Sorry.
It's a pity, but too late to change.[1]
What do you think about a patch that makes git-commit-tree call iconv on
its input to get it to UTF-8 (or any other charset). Maybe it
makes sense to add another header to commit objects (e.g.
"charset UTF-8") if something in the commit object is non-ASCII?
In my eyes it would make sense to even force UTF-8 for commit logs (and
author, committer). The downside is that it becomes impossible to store
arbitrary byte sequences in commit objects. (IMHO not a real
limitation.)
Best regards
Uwe
[1] actually I think it's worse, because my iconv (from Debian's libc6
version 2.3.6.ds1-8) was unable to convert it correctly to utf-8 for
any encoding that starts with ISO-2022.
--
Uwe Kleine-König
http://www.google.com/search?q=sin%28pi%2F2%29
^ 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