* Re: Cloning from sites with 404 overridden
From: linux @ 2006-03-22 2:59 UTC (permalink / raw)
To: git
If someone feels ambitious, you can detect this condition automatically
by searching for a file that you know won't be there and seeing if you
get a 404 response to that.
To avoid punishing good servers, it would be nice to defer the test
until reciving the first corrupted object.
I'm not sure what the best "object that's not supposed to be there" is.
It could just be a random hash, or would a malformed object file name
be better? Any fixed name has a finite chance of being created by
someone somewhere, but generating 160-bit random numbers is a PITA on
non-freenix platforms.
(As an aside, I suspect this is all caused by Microsoft's "friendly HTML
error messages" invention.)
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-03-22 2:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzzb5q3.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> - cvsimport post-import checkout fix.
Junio> Earlier we had a workaround to deal with people who import
Junio> into the current branch by not checking out. After
Junio> incrementally importing from the same CVS repository again,
Junio> however, the code did update the branch head. This made the
Junio> working tree and the index stale and was causing more
Junio> confusion than it avoided.
Junio> This fix is to make re-importing act more like git-pull, not
Junio> git-fetch. So if you run an incremental import into the
Junio> current branch, it tries to fast-forward the working tree and
Junio> index (your current branch head, index and working tree had
Junio> better be pristine with respect to the CVS repository for
Junio> this, but that is already an requirement for a tracking
Junio> branch anyway) when your current branch is the tracking
Junio> branch, or merge the imported result into your current branch
Junio> if you are using a separate tracking branch.
Junio> I've done some testing on this myself, but am waiting for
Junio> independent confirmations from cvsimport users. Merlyn?
I'm waiting for that CVS tree to change again. It changes every
4-5 days.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-03-22 1:58 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- git.el updates (Alexandre Julliard)
- git-svn updates (Eric Wong)
- git-blame updates (Fredrik Kuivinen)
- documentation updates (Francis Daly, Jon Loeliger)
- Makefile: Add TAGS and tags targets (Fredrik Kuivinen)
- http-push support for deleting remote branches (Nick Hengeveld)
- assorted minor fixes and tweaks (Alexandre Julliard, Mark
Hollomon, Shawn Pearce, Yasushi SHOJI, Nicolas Pitre, Randal
L. Schwartz and me)
* The 'next' branch, in addition, has two important fixes and
enhancements, and it probably is a good time to do a 1.3
release when they graduate to "master" and prove stable.
- quicker and dirtier rename detection by Linus and me.
I've been using this myself and haven't seen major
misdetection so far, but I do not use much renames. Maybe
it's time to push this out and see what happens. This is
_not_ the "important" part.
- cvsimport post-import checkout fix.
Earlier we had a workaround to deal with people who import
into the current branch by not checking out. After
incrementally importing from the same CVS repository again,
however, the code did update the branch head. This made the
working tree and the index stale and was causing more
confusion than it avoided.
This fix is to make re-importing act more like git-pull, not
git-fetch. So if you run an incremental import into the
current branch, it tries to fast-forward the working tree and
index (your current branch head, index and working tree had
better be pristine with respect to the CVS repository for
this, but that is already an requirement for a tracking
branch anyway) when your current branch is the tracking
branch, or merge the imported result into your current branch
if you are using a separate tracking branch.
I've done some testing on this myself, but am waiting for
independent confirmations from cvsimport users. Merlyn?
- refs/remotes support.
This has been the recent hot topic, on git-clone.
First, not so controversial one. A new option --reference
can be used to help cloning a project similar to what you
already have over thin wire:
$ git clone --reference /git/linux-2.6.git \
git://git.kernel.org/pub/.../jgarzik/libata-dev.git/ \
libata-dev
What happens here is that the new repository (libata-dev you
are creating by cloning from Jeff) is set up to borrow from
vanilla Linus repository you already keep track of, and the
initial clone downloads and expands objects that are only
present in Jeff's tree.
Another new option, --use-separate-remote, changes the way
$GIT_DIR/remotes/origin file and your tracking branches are
set up after the initial cloning. Without it, all the remote
heads are copied to your $GIT_DIR/refs/heads/ and a copy of
the remote HEAD is made as $GIT_DIR/refs/heads/origin, and
remotes/origin file is set up to keep this structure up to
date. This is the traditional behaviour.
When --use-separate-remote is in effect, the tracking
branches are created in $GIT_DIR/refs/remotes/origin/ and you
will not get the extra "origin" head. Your local branch
namespace under $GIT_DIR/refs/heads/ will only have "master".
In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD
points at the primary branch of the remote repository.
Similar to a filename in $GIT_DIR/refs/{heads,tags} that can
be used to name a ref (e.g. when you say "git diff frotz",
you are telling git to read from $GIT_DIR/refs/heads/frotz
and use that commit ID to diff your working tree against), a
directory that has such a symref under $GIT_DIR/refs/remotes
can be used to name the ref. IOW, "git diff origin" in a
repository a cloned this way means you want a diff against
$GIT_DIR/refs/remotes/origin/HEAD.
I've done reasonable amount of testing over git:// transport,
and some with http:// as well, but I do not know if rsync://
works at all (I never use rsync:// transport myself). If
anybody cares about rsync:// transport, please test it while
it still is in "next" to keep things working for you.
A new configuration option, 'core.warnambiguousrefs', can be
set to warn you if you use "frotz" to name a ref when you
have more than one "frotz" under $GIT_DIR/refs (e.g. you have
both branch "frotz" and tag "frotz", and/or you have
refs/remotes/frotz/HEAD).
It also has changes by Eric Wong to teach git-fetch about
$GIT_DIR/refs/remotes hierarchy.
^ permalink raw reply
* [PATCH] fix field width/precision warnings in blame.c
From: Luck, Tony @ 2006-03-21 23:28 UTC (permalink / raw)
To: git
Using "size_t" values for printf field width/precision upsets gcc, it
wants to see an "int".
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
gcc -o blame.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' blame.c
blame.c: In function `main':
blame.c:864: warning: field width is not type int (arg 2)
blame.c:864: warning: field precision is not type int (arg 3)
blame.c:868: warning: field width is not type int (arg 2)
blame.c:868: warning: field precision is not type int (arg 3)
diff --git a/blame.c b/blame.c
index 9c97aec..7e88833 100644
--- a/blame.c
+++ b/blame.c
@@ -748,7 +748,7 @@ int main(int argc, const char **argv)
struct commit_info ci;
const char *buf;
int max_digits;
- size_t longest_file, longest_author;
+ int longest_file, longest_author;
int found_rename;
const char* prefix = setup_git_directory();
^ permalink raw reply related
* Re: Bad merging with stgit or git
From: Junio C Hamano @ 2006-03-21 23:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: git
In-Reply-To: <1142972313.4749.123.camel@praia>
Mauro Carvalho Chehab <mchehab@infradead.org> writes:
>From what I'm understanding now, I should do, when a conflict is
> detected:
>
> nano <files>
> git-update-index <files>
> git commit
>
> Previously (at git 1.1.4), I was doing:
> nano <files>
> git commit <files>
>
> git 1.2.4 don't allow this bad commit syntax anymore.
It is not a bad syntax, and it instead would say "you might have
meant to say -i paths...", and if you follow that suggestion to
say:
$ git commit -i this-and-that-file-I-resolved-by-hand
you would commit the cleanly auto-resolved paths _and_ the
result of your hand merge result. That is the same traditional
behaviour you are used to and is very convenient if you only had
a few paths to be hand resolved.
So I suspect there might be something else going on.
^ permalink raw reply
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Petr Baudis @ 2006-03-21 21:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1142977465.8712.4.camel@dv>
Hi,
Dear diary, on Tue, Mar 21, 2006 at 10:44:25PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Tue, 2006-03-21 at 21:59 +0100, Petr Baudis wrote:
> > Dear diary, on Tue, Mar 21, 2006 at 09:54:14PM CET, I got a letter
> > where Pavel Roskin <proski@gnu.org> said that...
> > > From: Pavel Roskin <proski@gnu.org>
> > >
> > > Merge labels keep changing, and they are not required to identify
> > > specific lines uniquely for the test purposes.
> > >
> > > Signed-off-by: Pavel Roskin <proski@gnu.org>
> >
> > Well, I sincerely hope that they won't change again. ;-)
>
> Actually, it would be nice to never expose labels starting with
> ".merge_file_" - cogito should provide more meaningful labels instead.
we shouldn't ever expose them, though. If we do, that's a bug.
> If you prefer, I'll submit a minimal patch to 0017-alice-bob-fixup.ed
> instead. Once ".merge_file_" is gone, the "tutorial" testsuite would
> check that such labels never appear again.
Curious, it contains the old-style label yet does not fail here now.
Unfortunately I have no time to play with it now. :-( A patch will be
most welcome.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Pavel Roskin @ 2006-03-21 21:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060321205956.GX19263@pasky.or.cz>
Hi, Petr!
On Tue, 2006-03-21 at 21:59 +0100, Petr Baudis wrote:
> Dear diary, on Tue, Mar 21, 2006 at 09:54:14PM CET, I got a letter
> where Pavel Roskin <proski@gnu.org> said that...
> > From: Pavel Roskin <proski@gnu.org>
> >
> > Merge labels keep changing, and they are not required to identify
> > specific lines uniquely for the test purposes.
> >
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> Well, I sincerely hope that they won't change again. ;-)
Actually, it would be nice to never expose labels starting with
".merge_file_" - cogito should provide more meaningful labels instead.
If you prefer, I'll submit a minimal patch to 0017-alice-bob-fixup.ed
instead. Once ".merge_file_" is gone, the "tutorial" testsuite would
check that such labels never appear again.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Petr Baudis @ 2006-03-21 20:59 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060321205414.8301.97041.stgit@dv.roinet.com>
Dear diary, on Tue, Mar 21, 2006 at 09:54:14PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> From: Pavel Roskin <proski@gnu.org>
>
> Merge labels keep changing, and they are not required to identify
> specific lines uniquely for the test purposes.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Well, I sincerely hope that they won't change again. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Junio C Hamano @ 2006-03-21 20:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603211219230.3622@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And I _hope_ that no git that recent will commit a merge in progress.
Not even 1.1 series for that matter, no.
> However, it does look like the
>
> case "$all,$also" in
> ,t)
>
> case doesn't check for MERGE_HEAD. That could be the bug. Junio?
I do not think so.
"Also" (aka -i) means "run update-index for these paths for me
first, and commit them alongside with what I (or merge) have
already updated in the index".
^ permalink raw reply
* [PATCH] Don't use merge labels in the ed scripts
From: Pavel Roskin @ 2006-03-21 20:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Pavel Roskin <proski@gnu.org>
Merge labels keep changing, and they are not required to identify
specific lines uniquely for the test purposes.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.../tutorial-script/0010-alice-bob-fixup.ed | 2 +-
.../tutorial-script/0017-alice-bob-fixup.ed | 4 ++--
.../tutorial-script/0018-alice-charlie-fixup1.ed | 4 ++--
.../tutorial-script/0019-alice-charlie-fixup2.ed | 4 ++--
.../tutorial-script/0021-bob-alice-fixup1.ed | 4 ++--
.../tutorial-script/0022-bob-alice-fixup2.ed | 2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/tutorial-script/0010-alice-bob-fixup.ed b/Documentation/tutorial-script/0010-alice-bob-fixup.ed
index 81b1360..35ba0c3 100644
--- a/Documentation/tutorial-script/0010-alice-bob-fixup.ed
+++ b/Documentation/tutorial-script/0010-alice-bob-fixup.ed
@@ -1,3 +1,3 @@
-/^<<<<<<< bob/,/^>>>>>>> bobswork/d
+/^<<<<<<< /,/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0017-alice-bob-fixup.ed b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
index ad04eb7..00626e3 100644
--- a/Documentation/tutorial-script/0017-alice-bob-fixup.ed
+++ b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
@@ -1,5 +1,5 @@
-/^<<<<<<< Makefile/d
+/^<<<<<<< /d
/^=======/,/^=======/+1d
-/^>>>>>>> \.merge_file_/d
+/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed b/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed
index 9682b4a..f73223c 100644
--- a/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed
+++ b/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed
@@ -1,7 +1,7 @@
-/^<<<<<<< master/d
+/^<<<<<<< /d
/^rpn\.o:/s/\.h.*$/.h lexer.h/
/^lexer\.o:/s/:.*$/: lexer.h/
-/^=======/,/^>>>>>>> charlie/d
+/^=======/,/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed b/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed
index 5d531de..75832f1 100644
--- a/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed
+++ b/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed
@@ -1,5 +1,5 @@
-/^<<<<<<< master/,/^=======/d
-/^>>>>>>> charlie/d
+/^<<<<<<< /,/^=======/d
+/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed b/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
index df703d5..9950144 100644
--- a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
+++ b/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
@@ -1,4 +1,4 @@
-/^<<<<<<< master/,/^=======/d
-/^>>>>>>> origin/d
+/^<<<<<<< /,/^=======/d
+/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed b/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
index d8c5746..df1c077 100644
--- a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
+++ b/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
@@ -1,5 +1,5 @@
/^#include "stack\.h"/+1d
/^#include "lexer\.h"/+1,/^#include "stack\.h"/d
-/^<<<<<<< master/-1,/^>>>>>>> origin/d
+/^<<<<<<< /-1,/^>>>>>>> /d
w
q
^ permalink raw reply related
* Re: Bad merging with stgit or git
From: Linus Torvalds @ 2006-03-21 20:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Mauro Carvalho Chehab, Git List
In-Reply-To: <20060321200847.GS18185@pasky.or.cz>
On Tue, 21 Mar 2006, Petr Baudis wrote:
>
> With the old Git version (probably v1.1.4, but I'm not so sure when
> looking at 1.1.4's git-commit.sh), git-commit would happily do the
> commit, but wouldn't record the commit as a merge.
I considered that, but as far as I can tell, Mauro is actually using a
fairly recent version of "git". How do I know? The second merge (the
_real_ one) says
commit 86d720ef82ca09e75fac06be15da7cbe2721863a
Merge: e338b73... 8fce4d8...
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
Date: Fri Mar 10 01:32:32 2006 -0300
Merge branch 'origin'
Conflicts:
drivers/media/video/saa7134/saa7134-dvb.c
nothing to commit
and that "Conflicts:" thing from git is actually reasonably recent (it's
from end of January), and almost certainly doesn't exist in v1.1.4 (I
don't think it exists in any 1.1.x version).
So it's 1.2.0 or newer (or some random build, of course).
And I _hope_ that no git that recent will commit a merge in progress.
However, it does look like the
case "$all,$also" in
,t)
case doesn't check for MERGE_HEAD. That could be the bug. Junio?
Linus
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Mauro Carvalho Chehab @ 2006-03-21 20:18 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Git List, Linus Torvalds
In-Reply-To: <20060321193924.GD14579@fieldses.org>
Em Ter, 2006-03-21 às 14:39 -0500, J. Bruce Fields escreveu:
> On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:
> > It shouldn't have any conflicts here for Linus, since those patches came
> > from his tree.
>
> What do you mean by "those patches came from his tree"? If you're
> actually cherry-picking patches from his tree and applying them to
> yours, then you're not reproducing the same commits he has--you're just
> creating new commits that happen to have nearly identical content.
No, I'm not cherry-picking his patches.
>From the discussions on git IRC, I think it may be caused by a bad
procedure when solving a conflict, after merging from Linus tree.
>From what I'm understanding now, I should do, when a conflict is
detected:
nano <files>
git-update-index <files>
git commit
Previously (at git 1.1.4), I was doing:
nano <files>
git commit <files>
git 1.2.4 don't allow this bad commit syntax anymore.
>
> --b.
Cheers,
Mauro.
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Petr Baudis @ 2006-03-21 20:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Git List, Linus Torvalds
In-Reply-To: <1142969653.4749.109.camel@praia>
Dear diary, on Tue, Mar 21, 2006 at 08:34:13PM CET, I got a letter
where Mauro Carvalho Chehab <mchehab@infradead.org> said that...
> With git-cat-file, it shows:
>
> $ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6
> tree b233a18f740a2883e4863506175f671d821f1e5e
> parent cb31c70cdf1ac7034bed5f83d543f4888c39888a
> author Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
> committer Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
>
> Merging Linus tree
Our IRC hypothesis:
gitweb shows two commits in sequence there,
11 days ago Mauro Carvalho ... Merge branch 'origin'
11 days ago Mauro Carvalho ... Merging Linus tree
where the "Merge branch 'origin'" commit is a true merge commit, but a
rather boring one. There were conflicts during the merge, and according
to mchebab they were "resolved" by (incorrectly) doing:
...edit <files>...
git-commit <files>
With the old Git version (probably v1.1.4, but I'm not so sure when
looking at 1.1.4's git-commit.sh), git-commit would happily do the
commit, but wouldn't record the commit as a merge.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Linus Torvalds @ 2006-03-21 19:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Git List
In-Reply-To: <1142969653.4749.109.camel@praia>
On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:
>
> I have a -git tree that generated a really bad result when committed by
> Linus, generating a really bad history log. My tree is located at:
> kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.
Here's a mail that went to linux-kernel to explain some more..
Basically, the problem is that the DVB tree has a perfectly normal commit
(_not_ a merge commit), which has the commit message
"Merging Linus tree"
and is just a patch that apparently merged the changes in my tree at some
random state (don't know which, since the commit isn't a merge commit, and
doesn't point to the parent it merged from).
I thought it might be a cherry-pick of a merge, or something like that,
but the author/committer dates are the same, so that sounds unlikely.
However, I could imagine that "stgit" would do something like this if/when
it is used to cherry-pick a merge.
Apparently the DVB people also use Mercurial somewhere, so who knows..
Linus
---
Date: Tue, 21 Mar 2006 11:32:10 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 000/141] V4L/DVB updates part 1
On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:
>
> Weird, I can't see all those stuff here. It shows something like
> (running from master copy at kernel.org):
I just did the raw output, so my output was from
git show --pretty=fuller -r e338b7
which isn't the default, but it's useful if you want to see both committer
and author information (and the raw format is just because I wasn't
interested in the diff itself, just looking at how many files where
changed).
> So, after the merging message, I have a normal diff with:
>
> 179 files changed, 1274 insertions(+), 785 deletions(-)
Yeah, we're talking about the same commit.
> Seeming all perfect from my knowledge about git.
It's a perfectly good commit. BUT IT IS NOT A MERGE, AND IT IS NOT A DIFF
THAT I WANT TO SEE COMING IN FROM AN OUTSIDE TREE!
Basically, in the DVB tree you have absolutely _no_ business in "merging"
work from my tree as a patch, especially when the patch you merge has
absolutely zero to do with DVB. You just applied a 5000-line patch to the
tree, with no merge message other than "Merge from Linus tree", and no
attribution about what the f*ck was merged, and why.
THAT is the part I'm unhappy with. The git tree is not "corrupt" from a
technical standpoint (it passes fsck). It's "corrupt" because it contains
a patch that shouldn't be there, that is mis-attributed, and that
incorrectly claims to be a merge when it isn't - it's just a random patch
generated against my tree.
Linus
^ permalink raw reply
* Re: Bad merging with stgit or git
From: J. Bruce Fields @ 2006-03-21 19:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Git List, Linus Torvalds
In-Reply-To: <1142969653.4749.109.camel@praia>
On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:
> It shouldn't have any conflicts here for Linus, since those patches came
> from his tree.
What do you mean by "those patches came from his tree"? If you're
actually cherry-picking patches from his tree and applying them to
yours, then you're not reproducing the same commits he has--you're just
creating new commits that happen to have nearly identical content.
--b.
^ permalink raw reply
* Bad merging with stgit or git
From: Mauro Carvalho Chehab @ 2006-03-21 19:34 UTC (permalink / raw)
To: Git List; +Cc: Linus Torvalds
I have a -git tree that generated a really bad result when committed by
Linus, generating a really bad history log. My tree is located at:
kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.
I'll try to make a brief from what's happened:
According to him:
"
...
In particular, commit e338b736f1aee59b757130ffdc778538b7db18d6 is crap,
crap, CRAP.
It's "Merging Linus tree", but it's not a merge at all: you have just
applied the _patch_ to merge the changes in my tree, but you haven't
actually told git to do so.
I don't know how/why you did that, but it's totally bogus, and I refuse
to
pull from that tree. That's a 5000+ line diff, affecting about 180
files!
...
"
After a further analysis, it seemed that a merge conflict were badly
solved. It is showing this message to Linus:
diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
AuthorDate: Fri Mar 10 01:30:04 2006 -0300
Commit: Mauro Carvalho Chehab <mchehab@infradead.org>
CommitDate: Fri Mar 10 01:30:04 2006 -0300
Merging Linus tree
:100644 100644 be5ae600f5337dbb14daa8d4cace110486e14f79
81bc51369f59a413108fd8b150c3090541ba49f8 M
Documentation/feature-removal-schedule.txt
:100644 100644 75205391b335f85c9b8a599d0d3b4c0dd1a8b41b
fc99075e0af47f0b73a2ae2dfb7d19920c604dea M
Documentation/kernel-parameters.txt
:100644 100644 9006063e73691da7b68449955a135f7c9317e2cd
da677f829f7689966bf09aeda6d89fc4b6a876d1 M arch/alpha/kernel/irq.c
For me, those tree last lines, don't appear. Instead, it just shows,
with git-show:
diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
Date: Fri Mar 10 01:30:04 2006 -0300
Merging Linus tree
and a diff file, with:
179 files changed, 1274 insertions(+), 785 deletions(-)
With git-cat-file, it shows:
$ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6
tree b233a18f740a2883e4863506175f671d821f1e5e
parent cb31c70cdf1ac7034bed5f83d543f4888c39888a
author Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
committer Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
Merging Linus tree
It shouldn't have any conflicts here for Linus, since those patches came
from his tree.
My current procedure is:
branch origin - Linus tree replica
branch work - my stgit main tree
branch work-fixes - my stgit tree for bug fixes
branch master - patches to current kernel
branch devel - patches to next kernel
All patches are generated against work branch, with stgit.
Branch work-fixes receives patches by using:
stg pick <sha>@work
Before commiting to kernel.org, I do:
at origin:
git pull linus_tree
at master:
git pull . origin
git pull . work-fixes
at devel:
git pull . origin
git pull . work
My environment is:
Stacked GIT 0.8.1
git version 1.2.4.gfd662
Python version 2.4.2 (#2, Jan 30 2006, 18:33:58)
[GCC 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1)]
Any ideas?
^ permalink raw reply
* Re: efficient cloning
From: Petr Baudis @ 2006-03-21 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7z4f7x3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Mar 21, 2006 at 10:45:12AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jeff King <peff@peff.net> writes:
>
> > Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
> > (or later)? Then the core looks for:
> > (current order, .git/refs, etc)
> > .git/refs/remotes/foo
> > .git/refs/remotes/foo/HEAD
> > The porcelain can take care of managing the contents of HEAD. If there
> > is no HEAD in the directory, then it cannot be looked up by 'foo'
> > ('foo/remote-branch' must be used instead).
>
> Yup, earlier I mentioned that possibility, and it does not seem
> too painful. On top of the "next", here is what is needed.
>
> -- >8 --
> [PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
>
> This implements the suggestion by Jeff King to use
> refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
> the primary branch head of a tracked remote. clone needs to be
> told about this convention as well.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Excellent, yes, that's what I've meant. I'm happy now. :)
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 9:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060321091916.GA17125@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
> (or later)? Then the core looks for:
> (current order, .git/refs, etc)
> .git/refs/remotes/foo
> .git/refs/remotes/foo/HEAD
> The porcelain can take care of managing the contents of HEAD. If there
> is no HEAD in the directory, then it cannot be looked up by 'foo'
> ('foo/remote-branch' must be used instead).
Yup, earlier I mentioned that possibility, and it does not seem
too painful. On top of the "next", here is what is needed.
-- >8 --
[PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote. clone needs to be
told about this convention as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_name.c | 23 ++++++++++++-----------
1 files changed, 12 insertions(+), 11 deletions(-)
c51d13692d4e451c755dd7da3521c5db395df192
diff --git a/sha1_name.c b/sha1_name.c
index 74c479c..3adaec3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -235,18 +235,21 @@ static int ambiguous_path(const char *pa
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
- static const char *prefix[] = {
- "",
- "refs",
- "refs/tags",
- "refs/heads",
- "refs/remotes",
+ static const char *fmt[] = {
+ "/%.*s",
+ "refs/%.*s",
+ "refs/tags/%.*s",
+ "refs/heads/%.*s",
+ "refs/remotes/%.*s",
+ "refs/remotes/%.*s/HEAD",
NULL
};
const char **p;
const char *warning = "warning: refname '%.*s' is ambiguous.\n";
char *pathname;
int already_found = 0;
+ unsigned char *this_result;
+ unsigned char sha1_from_ref[20];
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
@@ -255,11 +258,9 @@ static int get_sha1_basic(const char *st
if (ambiguous_path(str, len))
return -1;
- for (p = prefix; *p; p++) {
- unsigned char sha1_from_ref[20];
- unsigned char *this_result =
- already_found ? sha1_from_ref : sha1;
- pathname = git_path("%s/%.*s", *p, len, str);
+ for (p = fmt; *p; p++) {
+ this_result = already_found ? sha1_from_ref : sha1;
+ pathname = git_path(*p, len, str);
if (!read_ref(pathname, this_result)) {
if (warn_ambiguous_refs) {
if (already_found &&
--
1.2.4.gf1250
^ permalink raw reply related
* Re: efficient cloning
From: Jeff King @ 2006-03-21 9:19 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q1sgpet.fsf@assigned-by-dhcp.cox.net>
On Tue, Mar 21, 2006 at 12:42:02AM -0800, Junio C Hamano wrote:
> The reason I would like to avoid .git/remotes/$origin is because
> it is designed to be Porcelainish thing. The underlying C-level
> git-fetch-pack never sees it; instead the information fed to
> C-level is prepared by the upper layer using that file. As far
> as I understand, Cogito does not understand it either, except
> that it ships with bash completion code that reads from
> filenames there.
Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
(or later)? Then the core looks for:
(current order, .git/refs, etc)
.git/refs/remotes/foo
.git/refs/remotes/foo/HEAD
The porcelain can take care of managing the contents of HEAD. If there
is no HEAD in the directory, then it cannot be looked up by 'foo'
('foo/remote-branch' must be used instead).
-Peff
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 8:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <441FB715.1000500@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> That way the only extra dwimery would be to add "remotes" after
> "heads" under .git/refs and accept directory in .git/remotes/ as ref
> and tack on '/master' at the end of it as the last option to
> search. For a specific branch on an imported remote, one would have to
> say "jc/next". This means we still only handle 'master' specially so
> we don't introduce any new protected or special names.
Two things that holding me back from doing what you suggested
are (1) "master" is just a convention and indeed non-negligible
number of kernel.org trees have "test" and "release" instead
without "master"; (2) I'd really really really want to avoid
teaching get_sha1_basic() C-level about .git/remotes/$origin
file, even though that function is more of a UI level than the
rest of the really core C-level routines.
But if I were forced to choose between the above 2, I would
probably pick defaulting to "master".
The reason I would like to avoid .git/remotes/$origin is because
it is designed to be Porcelainish thing. The underlying C-level
git-fetch-pack never sees it; instead the information fed to
C-level is prepared by the upper layer using that file. As far
as I understand, Cogito does not understand it either, except
that it ships with bash completion code that reads from
filenames there.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 8:28 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Petr Baudis
In-Reply-To: <200603201730.19373.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Shouldn't this be .git/refs/remotes/origin/?
> Ie. different namespaces for different remotes?
OK, here is a second try, that comes on top of the one from the
last night.
Together with another topic in the "next" branch, you can now do
this:
$ git clone --use-separate-remote --reference git.git \
git://git.kernel.org/pub/scm/git/git.git new.git
$ cd new.git
$ git branch
* master
$ git log --pretty=oneline master..origin/next | wc -l
72
What the last one shows is that sha1_basic() lets you omit
refs/remotes; it does not let you say "origin" to mean
"refs/remotes/origin/master", although I agree that abbreviation
would be useful. As I am still not yet convinced that using
what is in .git/remotes/origin is a good way to implement that
shorthand, and would rather avoid reading .git/remotes/origin
from the C level (even though sha1_basic() is not _that_ core
but a lot closer to the UI, compared to other C level routines),
I am leaving that part for later rounds.
-- >8 --
[PATCH] revamp git-clone (take #2).
This builds on top of the previous one.
* --use-separate-remote uses .git/refs/remotes/$origin/
directory to keep track of the upstream branches.
* The $origin above defaults to "origin" as usual, but the
existing "-o $origin" option can be used to override it.
I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-clone.sh | 50 +++++++++++++++++++++++++++++++-------------------
1 files changed, 31 insertions(+), 19 deletions(-)
47874d6d9a7f49ade6388df049597f03365961ca
diff --git a/git-clone.sh b/git-clone.sh
index 9db678b..3b54753 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -61,8 +61,9 @@ use File::Path qw(mkpath);
use File::Basename qw(dirname);
my $git_dir = $ARGV[0];
my $use_separate_remote = $ARGV[1];
+my $origin = $ARGV[2];
-my $branch_top = ($use_separate_remote ? "remotes" : "heads");
+my $branch_top = ($use_separate_remote ? "remotes/$origin" : "heads");
my $tag_top = "tags";
sub store {
@@ -127,7 +128,12 @@ while
*,--reference=*)
reference=`expr "$1" : '--reference=\(.*\)'` ;;
*,-o)
- git-check-ref-format "$2" || {
+ case "$2" in
+ */*)
+ echo >&2 "'$2' is not suitable for an origin name"
+ exit 1
+ esac
+ git-check-ref-format "heads/$2" || {
echo >&2 "'$2' is not suitable for a branch name"
exit 1
}
@@ -165,14 +171,9 @@ then
no_checkout=yes
fi
-if test -z "$origin_override$origin"
+if test -z "$origin"
then
- if test -n "$use_separate_remote"
- then
- origin=remotes/master
- else
- origin=heads/origin
- fi
+ origin=origin
fi
# Turn the source into an absolute path if
@@ -317,7 +318,7 @@ test -d "$GIT_DIR/refs/reference-tmp" &&
if test -f "$GIT_DIR/CLONE_HEAD"
then
# Figure out where the remote HEAD points at.
- perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote"
+ perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin"
fi
cd "$D" || exit
@@ -328,8 +329,18 @@ then
# Figure out which remote branch HEAD points at.
case "$use_separate_remote" in
'') remote_top=refs/heads ;;
- *) remote_top=refs/remotes ;;
+ *) remote_top="refs/remotes/$origin" ;;
esac
+
+ # What to use to track the remote primary branch
+ if test -n "$use_separate_remote"
+ then
+ origin_tracking="remotes/$origin/master"
+ else
+ origin_tracking="heads/$origin"
+ fi
+
+ # The name under $remote_top the remote HEAD seems to point at
head_points_at=$(
(
echo "master"
@@ -349,25 +360,26 @@ then
done
)
)
+
+ # Write out remotes/$origin file.
case "$head_points_at" in
?*)
mkdir -p "$GIT_DIR/remotes" &&
- echo >"$GIT_DIR/remotes/origin" \
+ echo >"$GIT_DIR/remotes/$origin" \
"URL: $repo
-Pull: refs/heads/$head_points_at:refs/$origin" &&
+Pull: refs/heads/$head_points_at:refs/$origin_tracking" &&
case "$use_separate_remote" in
t) git-update-ref HEAD "$head_sha1" ;;
*) git-update-ref "refs/$origin" $(git-rev-parse HEAD)
esac &&
- (cd "$GIT_DIR" && find "$remote_top" -type f -print) |
- while read ref
+ (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
+ while read dotslref
do
- head=`expr "$ref" : 'refs/\(.*\)'` &&
- name=`expr "$ref" : 'refs/[^\/]*/\(.*\)'` &&
+ name=`expr "$dotslref" : './\(.*\)'` &&
test "$head_points_at" = "$name" ||
test "$origin" = "$head" ||
echo "Pull: refs/heads/${name}:$remote_top/${name}"
- done >>"$GIT_DIR/remotes/origin"
+ done >>"$GIT_DIR/remotes/$origin"
esac
case "$no_checkout" in
--
1.2.4.ge2fc
^ permalink raw reply related
* Re: efficient cloning
From: Andreas Ericsson @ 2006-03-21 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <7vfylcismx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>
>>I still don't get what's wrong on what I'm proposing. I'm not seeing the
>>disadvantages, if there are any.
>
>
> The only thing I think there is is that I do not get what you
> are proposing ;-), since I am not paying full attention while at
> day-job.
>
> If you are proposing to root --use-separate-remote not at
> refs/remotes but refs/remotes/origin/, I think it makes kind of
> sense. It would make tons of sense _if_ dealing more than one
> remote repository is the norm, but otherwise you would have an
> extra level of directory refs/remotes which almost always have
> only one subdirectory 'origin' and nothing else, which is
> pointless.
>
afaiu, this is exactly what Pasky's proposing, and I agree. We could
then teach 'git diff origin master' to mean 'origin/master' *if* no
other tag/branch is found in the lookup order. I think it makes sense to
do searching like this, for a ref named foo
(current order, with .git/, .git/refs/, etc...)
.git/refs/remotes/foo
.git/refs/remotes/foo/master
That way the only extra dwimery would be to add "remotes" after "heads"
under .git/refs and accept directory in .git/remotes/ as ref and tack on
'/master' at the end of it as the last option to search. For a specific
branch on an imported remote, one would have to say "jc/next". This
means we still only handle 'master' specially so we don't introduce any
new protected or special names.
> I am not sure if you are also advocating to map (somehow) origin
> to remotes/origin/master (or whatever branch remote's HEAD
> points at), but if so I am not quite sure what its semantics
> would be. Which remote branch would you pick (that would not
> necessarily be "master") and where are you going to record that
> and when. It all sounds to me complicating things
> unnecessarily.
>
Not too much so, I think. I'll look into it tonight, although I'm not
very familiar with the core stuff so possibly (/ hopefully) someone else
will beat me to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] contrib/git-svn: allow rebuild to work on non-linear remote heads
From: Eric Wong @ 2006-03-21 4:51 UTC (permalink / raw)
To: Junio C Hamano, git
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
85bed4cd937921844574fe66da95977fdeece993
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index cf233ef..f3fc3ec 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -850,11 +850,23 @@ sub assert_revision_unknown {
}
}
+sub trees_eq {
+ my ($x, $y) = @_;
+ my @x = safe_qx('git-cat-file','commit',$x);
+ my @y = safe_qx('git-cat-file','commit',$y);
+ if (($y[0] ne $x[0]) || $x[0] !~ /^tree $sha1\n$/
+ || $y[0] !~ /^tree $sha1\n$/) {
+ print STDERR "Trees not equal: $y[0] != $x[0]\n";
+ return 0
+ }
+ return 1;
+}
+
sub assert_revision_eq_or_unknown {
my ($revno, $commit) = @_;
if (-f "$REV_DIR/$revno") {
my $current = file_to_s("$REV_DIR/$revno");
- if ($commit ne $current) {
+ if (($commit ne $current) && !trees_eq($commit, $current)) {
croak "$REV_DIR/$revno already exists!\n",
"current: $current\nexpected: $commit\n";
}
--
1.2.4.gb622a
^ permalink raw reply related
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 0:57 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200603210126.59870.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> I think what is reasonable is something like this:
>>
>> - If you start from a repository cloned in the traditional
>> way, the upstream "master" is kept track of with your
>> "origin", so "diff origin master" would be "my changes on top
>> of the upstream".
>
> Yes. And it would be nice if the same would work with the new layout,
> assuming that there is no local "origin" branch, but a .git/remotes/origin
> file and .git/refs/remotes/origin directory.
My primary aversion comes from that I'd rather avoid teaching
the really core stuff about .git/remotes file, and the part that
interprets refname is fairly a low-level part.
We _could_ record refs/remotes/origin/HEAD that points at
refs/remotes/origin/master (or some other branch) upon cloning,
and if Pasky wants to do something similar upon fetching, that
fetch command could do the same thing.
^ permalink raw reply
* Re: efficient cloning
From: Josef Weidendorfer @ 2006-03-21 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe00iupp.fsf@assigned-by-dhcp.cox.net>
On Tuesday 21 March 2006 00:04, you wrote:
> > Linus wanted to still be able to say "origin" which automatically
> > would map to "remotes/origin/master", where the name of the remote
>
> I do not remember that,
See
http://www.gelato.unsw.edu.au/archives/git/0603/17405.html
I found it strange at first. But I think it is the right thing.
> I think what is reasonable is something like this:
>
> - If you start from a repository cloned in the traditional
> way, the upstream "master" is kept track of with your
> "origin", so "diff origin master" would be "my changes on top
> of the upstream".
Yes. And it would be nice if the same would work with the new layout,
assuming that there is no local "origin" branch, but a .git/remotes/origin
file and .git/refs/remotes/origin directory.
> - Regardless of how you started your cloned repository, with an
> $GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in
> a separate message, you can rearrange things to organize the
> refs/ hierarchy any way you want.
Yes.
Still it would be nice to have a fixed convention here.
Eg. gitk could decorate the namespace in a special way.
Even if it is most of the time "origin" only.
> [Footnote]
>
> *1* ... which currently I do not plan to do myself unless I have
> absolutely nothing else to do and really bored. A sound of huge
> hint dropping ;-).
It should be as simple as (probably with quite some errors)
~/> cat git-rename-remote.sh
mv .git/refs/remotes/$1 .git/refs/remotes/$2
sed -e "s|remotes/$1|remotes/$2" .git/remotes/$1 > .git/remotes/$2
rm .git/remotes/$1
If you allow more freedom regarding the use of refs/remotes, it gets more
complicated both for the script and for the user to understand.
Josef
^ 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