* Bug in git svn fetch
From: Chris Cinelli @ 2012-01-16 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <CAM1GFk0bXTC2YUigJnB2wa4EKHOJ8oO8Sk=8+dApqkXH2_SP+Q@mail.gmail.com>
We are trying to move from SVN to GIT but we are having problems
git --version
git version 1.7.9.rc1
I updated because I had the same problem also with version 1.7.5 (just
different line number)
Running command: git svn fetch
Found possible branch point: http://our_server/svn/FUL/trunk =>
http://our_server/svn/FUL/tags/2011_11_26_1223AM, 822
Use of uninitialized value $u in substitution (s///) at
/usr/libexec/git-core/git-svn line 2097.
Use of uninitialized value $u in concatenation (.) or string at
/usr/libexec/git-core/git-svn line 2097.
refs/remotes/svn/trunk: 'http://our_server/svn/FUL' not found in ''
The folder tags/2011_11_26_1223AM was created with SVN copy. It may
also be deleted and recreated above with the same name.
I hope it is an easy fix.
Best,
Chris
--Everything should be made as simple as possible, but not simpler
(Albert Einstein)
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Erik Faye-Lund @ 2012-01-16 21:18 UTC (permalink / raw)
To: Yves Goergen; +Cc: Holger Hellmuth, git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F14718B.80209@unclassified.de>
On Mon, Jan 16, 2012 at 7:50 PM, Yves Goergen
<nospam.list@unclassified.de> wrote:
> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works.
Git for Windows know how the file-system works, and tries to prevent
you from shooting yourself in the leg by being case-insensitive when
matching the index and the working copy. But there is an opt-out for
this, which is controlled by the configuration option core.ignorecase,
which Peff already asked about. This option is supposed to be enabled
by default on Windows.
What you are describing sounds like that option might have gotten
disabled somehow. But it might be something else, see below.
> I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work?
Very speculative comment: This might be a bug in TortoiseGit. Looking
at the sources, it seems they are using libgit2 to mess around with
the index; perhaps it's case-sensitivity code isn't as well tested as
Git for Windows'?
For instance, they do their own index and tree sorting, in an attempt
to be case sensitive:
http://code.google.com/p/tortoisegit/source/diff?spec=svnf151c0ddf205fa1fc1ff886b8cfc4af87d373b26&r=f151c0ddf205fa1fc1ff886b8cfc4af87d373b26&format=side&path=/src/Git/GitIndex.cpp
^ permalink raw reply
* Re: Cannot push a commit
From: Jeff King @ 2012-01-16 21:20 UTC (permalink / raw)
To: Matthias Fechner; +Cc: git
In-Reply-To: <4F1297E0.1060703@fechner.net>
On Sun, Jan 15, 2012 at 10:09:52AM +0100, Matthias Fechner wrote:
> git.exe push --progress "origin" master:master
>
> Counting objects: 4, done.
> Compressing objects: 100% (3/3)
> Writing objects: 100% (3/3), 80.00 KiB | 137 KiB/s
> Writing objects: 100% (3/3), 91.63 KiB | 137 KiB/s, done.
> Total 3 (delta 0), reused 0 (delta 0)
> fatal: early EOF
> error: unpack failed: unpack-objects abnormal exit
> To idefix@fechner.net:git-test
> ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to 'idefix@fechner.net:git-test'
Odd. The unpacking process on the other end claims that it didn't get
the whole input (it knows how much to expect based on the earlier parts
of what is sent) . Yet the connection is still going (because we see the
error messages coming from the remote), so it wasn't simply that the
connection was dropped. So either:
1. Something in the connection cut out but only in a half-duplex way.
I guess I could see ssh doing that if its input pipe closed, but
that would mean the local pack-objects failed, and I believe git
already detects and reports that case.
2. The packfile sent indicated that it should have more bytes than it
does (i.e., either git indicated there were more objects than there
actually are, or zlib failed to give a stream-end marker in the
middle of an object). This is one of:
a. A bug in git or zlib.
b. Something in the connection corrupting the data (e.g., a
transport that is not 8-bit clean).
But in either 2a or 2b, I would expect us to have seen this before, and
I don't recall seeing anything like it.
You could try generating a bundle with this pack, like:
git bundle create foo.bundle master ^origin/master
and then shipping the resulting foo.bundle to the other side, and
pulling from it like:
git pull /path/to/foo.bundle master
That should use (roughly) the same pack generation code as the
push, but avoid the transport. If it works, then it's either a problem
with the transport, or there is something really subtle going on
inside git.
If it does fail, then that will be a much easier case to repeat and
diagnose from there.
-Peff
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-16 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: Holger Hellmuth, git, Carlos Martín Nieto
In-Reply-To: <20120116190956.GA13802@sigill.intra.peff.net>
On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
> What is the output of "git config core.ignorecase" in your repository?
None, i.e. an empty line.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Jeff King @ 2012-01-16 21:27 UTC (permalink / raw)
To: Yves Goergen; +Cc: Holger Hellmuth, git, Carlos Martín Nieto
In-Reply-To: <4F1494AA.1000004@unclassified.de>
On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:
> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
> > What is the output of "git config core.ignorecase" in your repository?
>
> None, i.e. an empty line.
That's odd. When the repository is first created, git will do a test to
see whether the filesystem supports case-sensitivity, and will set
core.ignorecase if it does not. Might this repository have been created
on a different filesystem, and then moved onto the case-insensitive
filesystem?
Or might it have been created by something other than core git? I don't
know whether one can create a repo in TortoiseGit, or if so how it does
so.
In any case, try doing:
git config core.ignorecase true
and see if that clears up your problems.
-Peff
^ permalink raw reply
* Re: Bug in git svn fetch
From: Chris Cinelli @ 2012-01-16 21:29 UTC (permalink / raw)
To: git
In-Reply-To: <CAM1GFk2zioi10M4HjyOF3a8_Ec23V9URPAAnRzp4xABSjKxZ+g@mail.gmail.com>
More details:
The previous commands were (I am using svn2git):
git svn init --prefix=svn/ --username=chris --no-metadata
--trunk=trunk --tags=tags --branches=branches
http://our_server/svn/FL/trunk/
git config --local svn.authorsfile authors_file
The process failed before using http://our_server/svn/FL (instead of
http://our_server/svn/FL/trunk)
We are not sure but it is very likely that on SVN we did a SVN copy,
then and SVN delete and again an SVN copy on the same folder.
I hope this help.
Best,
Chris
http://www.mail-archive.com/git@vger.kernel.org/
On Mon, Jan 16, 2012 at 1:04 PM, Chris Cinelli
<chris.cinelli@formativelearning.com> wrote:
> We are trying to move from SVN to GIT but we are having problems
>
> git --version
> git version 1.7.9.rc1
>
> I updated because I had the same problem also with version 1.7.5 (just
> different line number)
>
> Running command: git svn fetch
> Found possible branch point: http://our_server/svn/FUL/trunk =>
> http://our_server/svn/FUL/tags/2011_11_26_1223AM, 822
> Use of uninitialized value $u in substitution (s///) at
> /usr/libexec/git-core/git-svn line 2097.
> Use of uninitialized value $u in concatenation (.) or string at
> /usr/libexec/git-core/git-svn line 2097.
> refs/remotes/svn/trunk: 'http://our_server/svn/FUL' not found in ''
>
> The folder tags/2011_11_26_1223AM was created with SVN copy. It may
> also be deleted and recreated above with the same name.
>
> I hope it is an easy fix.
>
> Best,
> Chris
>
> --Everything should be made as simple as possible, but not simpler
> (Albert Einstein)
--
--Everything should be made as simple as possible, but not simpler
(Albert Einstein)
^ permalink raw reply
* Re: [PATCH] test_interactive: interactive debugging in test scripts
From: Pete Wyckoff @ 2012-01-16 22:07 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jeff King, Git Mailing List, Junio C Hamano
In-Reply-To: <4F148D3B.4070206@web.de>
Jens.Lehmann@web.de wrote on Mon, 16 Jan 2012 21:48 +0100:
> Am 16.01.2012 21:11, schrieb Jeff King:
> > On Mon, Jan 16, 2012 at 09:01:21PM +0100, Jens Lehmann wrote:
> >
> >> So I vote for your patch as it takes my initial idea even further. I
> >> really like that HOME, TERM and SHELL are honored in your version
> >> leaving the user with a fully functional shell of his choice.
> >
> > I'm actually mildly negative on this feature, as it interferes with the
> > tests themselves. Probably TERM and SHELL don't matter. But $HOME means
> > git will read your personal .gitconfig, not any config (or lack thereof)
> > in the trash directory.
>
> Good point, I haven't thought of that ... so yes, at least $HOME should
> go.
I, too, have stumbled over differences that are due to picking up
something in $HOME. It takes a minute to realize what's going
on.
TERM can interfere with at least one test: c2116a1 (test-lib: fix TERM
to dumb for test repeatability, 2008-03-06). SHELL can cause
issues when it is more feature-ful than SHELL_PATH.
On the other hand, it's frustrating to work in an environment
without my shell aliases, git aliases, readline customizations,
personal path, and assorted environment variables.
I'm comfortable with the (rare?) possibility of confusion. But
perhaps it is unwise to support a feature with so many caveats,
even if it is only for debugging.
-- Pete
^ permalink raw reply
* Re: [PATCH v2 2/2] tree_entry_interesting: make recursive mode default
From: Junio C Hamano @ 2012-01-16 22:15 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jonathan Nieder, Linus Torvalds
In-Reply-To: <20120115100327.GA10735@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sat, Jan 14, 2012 at 07:12:03PM -0800, Junio C Hamano wrote:
>> That makes my head hurt and makes me suspect there is something
>> fundamentally wrong in the patch. Sigh...
>
> I'll need to think about it. In the meantime perhaps the following
> bandage patch would suffice, rather than revert 2f88c19 (diff-index:
> pass pathspec down to unpack-trees machinery)
Yeah, the logic of this correction is very clear. Because diff_cache is
about walking a flat index, the "recursive pathspec" that allows us to
look into deeper levels in directory hierarchy should be set, and also we
should not be limiting the depth of the match in any way by setting the
max_depth to "unlimited".
Thanks.
> -- 8< --
> Subject: [PATCH] diff-index: enable recursive pathspec matching in unpack_trees
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff-lib.c | 2 ++
> t/t4010-diff-pathspec.sh | 8 ++++++++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/diff-lib.c b/diff-lib.c
> index 62f4cd9..fc0dff3 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -469,6 +469,8 @@ static int diff_cache(struct rev_info *revs,
> opts.src_index = &the_index;
> opts.dst_index = NULL;
> opts.pathspec = &revs->diffopt.pathspec;
> + opts.pathspec->recursive = 1;
> + opts.pathspec->max_depth = -1;
>
> init_tree_desc(&t, tree->buffer, tree->size);
> return unpack_trees(1, &t, &opts);
> diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh
> index fbc8cd8..af5134b 100755
> --- a/t/t4010-diff-pathspec.sh
> +++ b/t/t4010-diff-pathspec.sh
> @@ -48,6 +48,14 @@ test_expect_success \
> compare_diff_raw current expected'
>
> cat >expected <<\EOF
> +:100644 100644 766498d93a4b06057a8e49d23f4068f1170ff38f 0a41e115ab61be0328a19b29f18cdcb49338d516 M path1/file1
> +EOF
> +test_expect_success \
> + '"*file1" should show path1/file1' \
> + 'git diff-index --cached $tree -- "*file1" >current &&
> + compare_diff_raw current expected'
> +
> +cat >expected <<\EOF
> :100644 100644 766498d93a4b06057a8e49d23f4068f1170ff38f 0a41e115ab61be0328a19b29f18cdcb49338d516 M file0
> EOF
> test_expect_success \
> --
> 1.7.8.36.g69ee2
>
> -- 8< --
^ permalink raw reply
* Re: git grep doesn't follow symbolic link
From: Junio C Hamano @ 2012-01-16 22:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Pang Yan Han, Thomas Rast, Ramkumar Ramachandra, Bertrand BENOIT,
git
In-Reply-To: <CACsJy8CaBAEJo_LuvjYhb2kfofH83cbR5DFDffmmCU3uJFqk+g@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> It's not wrong per se. It's an implication that users have to take
> when they choose to use it. We may help make it clear that the
> symlinks point to untracked files by putting some indication in the
> diff.
>
> When I do "git log -Sfoo -- '*.cxx'" I don't really care if bar.cxx is
> a symlink. Neither does my compiler. It may be a symlink's target
> change that makes "foo" appear. Git could help me detect that quickly
> instead of sticking with tracked contents only.
As there is nothing in Git that tells that whatever is pointed at by
bar.cxx that happens to be in your filesystem today had "foo" in it when
that historical version of the commit whose bar.cxx symlink was updated to
point to that file. It is *WRONG* to show the commit as something that
changes bar.cxx to contain "foo" (or more precisely, changes the count of
"foo" in it).
Why is it so hard to understand?
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Junio C Hamano @ 2012-01-16 22:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhazv3m17.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> but is that the right thing to do if suffix came from "$4"?
>>
>> As far as I can see, "$4" is used to append "." in very limited cases, and
>> nobody explicitly passes SP as "$4" when calling this, so it may be easier
>> to read if you moved this before that "if we have 3 or more args, use the
>> fourth one as the suffix" block, i.e. something like this?
>
> Why not, but in case someone explicitely passes " " as $4 in the future,
> it's likely to be better to strip it for the same reason we strip it here.
I doubt that would be sufficent or appropriate. If some caller _WANTS_ to
add a SP, shouldn't we be devising a way to tell zsh to add it without
quoting, instead of silently stripping?
> I don't care much either way in this case.
>
>> + # Because we use '-o nospace' under bash, we need to compensate
>> + # for it by appending SP after completed word ourselves.
>> + local suffix="${BASH_VERSION+ }"
>
> Not sure why you reworded the comment, but I don't think it's a good
> idea to remove the "ZSH would quote the trailing space added with -S"
> that I had added, because this is really the reason we do a special case
> here. Your version is misleading, because we use -o nospace for ZSH too.
Ok, use of "-o nospace" in Zsh is what I missed. I thought the issue was
about the nospace emulation.
So does that mean we would be forcing zsh users to add SP themselves? I
wonder if we can do better than that.
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Junio C Hamano @ 2012-01-16 22:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <CA+55aFzRN2F5PZDZPRmbj9occZwA6E6Pi+S+M_Qq2EfS6sctyA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Just a heads-up and congrats: octopus merges of signed tags work well,
> and did exactly the RightThing(tm), both at merge time and with
> "--show-signature".
>
> I knew it was supposed to work, but I have to admit that I was a bit
> apprehensive about it when I tried.
>
> Current top-of-head (commit 81d48f0aee54) in the kernel, in case you care.
I looked at it again, and it makes me wonder if we should further reword
it to say "side branch #1, tagged 'devicetree-for-linus'" instead of the
current "parent #2, tagged 'devicetree-for-linus'". It looks very weird to
start counting from #2, when we know we will never show #1 there.
^ permalink raw reply
* Re: [PATCH] test-lib: add the test_bash convenience function
From: Junio C Hamano @ 2012-01-16 22:51 UTC (permalink / raw)
To: Jeff King; +Cc: Jens Lehmann, Git Mailing List
In-Reply-To: <20120115232413.GA14724@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Nice. Many times I have added such a "bash" or "gdb" invocation then
> forgotten "-v", only to scratch my head at why the test seemed to be
> hanging.
>
> Two minor nits on the patch itself:
> ...
> 1. It may be worth putting a warning in the comment that this is never
> to be used in a real test, but only temporarily inserted.
>
> 2. I do this not just with bash, but with "gdb". I wonder if it is worth
> making this "test_foo bash", for some value of "foo" (the ones that
> occur to me are "debug" and "run", but of course they are taken).
>
> Actually, I wonder if the existing test_debug could handle this
> already (though you do have to remember to add "--debug" to your
> command line, then).
I wondered the same thing from a different angle. My first reaction was
"Why is this called 'bash' not 'sh'?" which naturally led to the same
direction as yours "why not an arbitrary command 'test_debug xxx'?"
test_pause perhaps?
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Jacob Helwig @ 2012-01-16 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vobu3uusw.fsf@alter.siamese.dyndns.org>
On Mon, Jan 16, 2012 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> Just a heads-up and congrats: octopus merges of signed tags work well,
>> and did exactly the RightThing(tm), both at merge time and with
>> "--show-signature".
>>
>> I knew it was supposed to work, but I have to admit that I was a bit
>> apprehensive about it when I tried.
>>
>> Current top-of-head (commit 81d48f0aee54) in the kernel, in case you care.
>
> I looked at it again, and it makes me wonder if we should further reword
> it to say "side branch #1, tagged 'devicetree-for-linus'" instead of the
> current "parent #2, tagged 'devicetree-for-linus'". It looks very weird to
> start counting from #2, when we know we will never show #1 there.
>
My immediate thought regarding the "side branch #1" version is not
wanting to have to do the math (even though it's a simple n+1), if I
decide to convert that text into ^ parent selection notation.
--
Jacob Helwig
http://technosorcery.net/about/me
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Linus Torvalds @ 2012-01-16 23:06 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <CAJ8aY1Hi47uyYSjAmtXfDEqgyc8T21WqXdEA0kGS7SQKxQ5b5g@mail.gmail.com>
On Mon, Jan 16, 2012 at 2:58 PM, Jacob Helwig <jacob@technosorcery.net> wrote:
>
> My immediate thought regarding the "side branch #1" version is not
> wanting to have to do the math (even though it's a simple n+1)
"Math is hard, let's go shopping".
But I think even barbie could do the "add one" thing. That said, I
think the current thing is already more than good enough, and I don't
think it's at all confusing to talk about "parent #2". In fact, I
think it's more obvious than "side branch #1".
Linus
^ permalink raw reply
* Re: Simulating an empty git repository without having said repository on disk
From: Richard Hartmann @ 2012-01-16 23:09 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
In-Reply-To: <20120116204131.GC18699@sigill.intra.peff.net>
On Mon, Jan 16, 2012 at 21:41, Jeff King <peff@peff.net> wrote:
> I don't use vcsh, but I seem to recall that it works by overlaying the
> working trees of different repositories on each other, right?
In parallel, but yes.
> So you
> can't just say "oh, files in foo/ belong to repository 'bar'". You must
> take the union of the set of tracked files from all repos, then find the
> difference of that from the set of all files.
Correct.
> Can individual repos mark things as excluded, too? Or do you have a
> master exclusion list? I.e., if I decide that I don't want "foo" tracked
> at all, how do I tell vcsh?
That's something I am still contemplating as there are several ways:
* excludes
* pre-/appends to the gitignore of every repo
* runtime magic
Feedback welcome :)
> I'm not sure why you care about the empty tree if you are only looking
> at untracked files. Or perhaps the problem is that you are using "git
> status", which fundamentally cares about looking at differences between
> HEAD and the index, even though you don't care in this case. In that case,
> maybe "git ls-files -o" would be more appropriate?
--others does not work as I need to look at several repos. I tried to
get the union of --others, but that creates 'argument too large' very
quickly.
Initially, I tried with find, but as that is depth-first, it takes
ages when compared to git's early stopping at directories.
> The most straightforward way in git would be to generate a temporary
> index that mentions all of the tracked files, like this:
>
> tmp=/some/tmp/index
> rm -f $tmp
> for i in repo; do
> git --git-dir=$repo ls-files -z |
> GIT_INDEX_FILE=$tmp xargs -0 git update-index --add
> done
> GIT_INDEX_FILE=$tmp git ls-files -o
>
> but that is very close to your "create an empty git repo" (in fact, you
> might even need to in order for update-index to be happy). But it would
> give you a place to put a master exclusion list (you would use it as
> --exclude=... in the final ls-files).
>
> If you have per-repo exclusion lists, then you could take a different
> approach, and simply run "git ls-files -o" for each repository. Any
> files which appeared in _every_ output would be untracked (since tracked
> files or individually-excluded files would be omitted from at least one
> repo). Like:
See above, but I will try yours as well.
> perl -lne "/^\s*$count (.*)/ and print \$1"
I know I sound picky, but I would also like to avoid any third-party
dependencies if possible. Perl is common, but not installed
everywhere.
> The downside is that you are doing $count traversals of the untracked
> directories. On an OS with a reasonable lstat and a directory structure
> that fits into cache, that is probably not too big a deal, though.
With cold cache, it can take ages. Especially once you have a few
git-annex repos in $HOME.
> I took a lot of guesses at exactly what you want. It might be more clear
> if you gave us an example situation along with the output you expect.
repo foo tracks .foo and .foo.d, bar .bar, etc
% vcsh list #lists repos
foo
bar
baz
% ls -aR
.foo
.foo.d/
.bar
.baz.d/
.quux.d/
.quux.d/foo
.quux.d/quux.d/quux
.quux.d/quux.d/quuux
.quux.d/quux.d/quuuux
.quux.d/quuuux.d/quuuux
pants
shirts
% vcsh run foo git ls-files # run command in context of repo foo
.foo
.foo.d
.quux.d/foo
% vcsh list-untracked # with the code I want in it
.quux.d/quux.d/
.quux.d/quuuux.d/
pants
shirts
%
I hope that makes sense.
The only part that does not already work today is list-untracked.
For failed attempts look at
https://github.com/RichiH/vcsh/tree/list-untracked
https://github.com/RichiH/vcsh/tree/list-untracked-2
Thanks,
Richard
^ permalink raw reply
* [PATCHv3 0/4] git-p4: small fixes to branches and labels
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
This is the third version of some small fixes to git-p4 branch and
label handling.
It was suggested for the earlier version that the author handling
could be simplified to use the 'author' variable. The code can
be simplified, but the author is the wrong value to use - it is
just the author of the commit, not the tag. Use the creator of the
label, or, if that does not exist ("p4 tag ..."), the p4 user.
This change does not fix the other problems with git-p4 labels:
- two p4 labels on the same changelist will fall over
- labels must match exactly the list of files imported
- you can't import a label without a p4 commit
Luke Diamand (4):
git-p4: handle p4 branches and labels containing shell chars
git-p4: cope with labels with empty descriptions
git-p4: importing labels should cope with missing owner
git-p4: add test for p4 labels
contrib/fast-import/git-p4 | 79 ++++++++++++++++++++----------------
t/t9803-git-p4-shell-metachars.sh | 48 ++++++++++++++++++++++
t/t9804-git-p4-label.sh | 73 ++++++++++++++++++++++++++++++++++
3 files changed, 165 insertions(+), 35 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply
* [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-1-git-send-email-luke@diamand.org>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++---
t/t9803-git-p4-shell-metachars.sh | 48 +++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3e1aa27..822e6f1 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -799,7 +799,7 @@ class P4Submit(Command, P4UserMap):
def canChangeChangelists(self):
# check to see if we have p4 admin or super-user permissions, either of
# which are required to modify changelists.
- results = p4CmdList("protects %s" % self.depotPath)
+ results = p4CmdList(["protects", self.depotPath])
for r in results:
if r.has_key('perm'):
if r['perm'] == 'admin':
@@ -1758,7 +1758,7 @@ class P4Sync(Command, P4UserMap):
def getLabels(self):
self.labels = {}
- l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
+ l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
if len(l) > 0 and not self.silent:
print "Finding files belonging to labels in %s" % `self.depotPaths`
@@ -1800,7 +1800,7 @@ class P4Sync(Command, P4UserMap):
command = "branches"
for info in p4CmdList(command):
- details = p4Cmd("branch -o %s" % info["branch"])
+ details = p4Cmd(["branch", "-o", info["branch"]])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
paths = details["View%s" % viewIdx].split(" ")
@@ -1938,7 +1938,7 @@ class P4Sync(Command, P4UserMap):
sourceRef = self.gitRefForBranch(sourceBranch)
#print "source " + sourceBranch
- branchParentChange = int(p4Cmd("changes -m 1 %s...@1,%s" % (sourceDepotPath, firstChange))["change"])
+ branchParentChange = int(p4Cmd(["changes", "-m", "1", "%s...@1,%s" % (sourceDepotPath, firstChange)])["change"])
#print "branch parent: %s" % branchParentChange
gitParent = self.gitCommitByP4Change(sourceRef, branchParentChange)
if len(gitParent) > 0:
diff --git a/t/t9803-git-p4-shell-metachars.sh b/t/t9803-git-p4-shell-metachars.sh
index db04375..db67020 100755
--- a/t/t9803-git-p4-shell-metachars.sh
+++ b/t/t9803-git-p4-shell-metachars.sh
@@ -57,6 +57,54 @@ test_expect_success 'deleting with shell metachars' '
)
'
+# Create a branch with a shell metachar in its name
+#
+# 1. //depot/main
+# 2. //depot/branch$3
+
+test_expect_success 'branch with shell char' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ p4 integrate //depot/main/... //depot/branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ echo f1 >branch\$3/shell_char_branch_file &&
+ p4 add branch\$3/shell_char_branch_file &&
+ p4 submit -d "branch\$3/shell_char_branch_file" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch\$3
+ View: //depot/main/... //depot/branch\$3/...
+ EOF
+
+ p4 edit main/f1 &&
+ echo "a change" >> main/f1 &&
+ p4 submit -d "a change" main/f1 &&
+
+ p4 integrate -b branch\$3 &&
+ p4 resolve -am branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch\$3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch\$3 &&
+ test -f shell_char_branch_file &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCH 3/4] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-1-git-send-email-luke@diamand.org>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 63 ++++++++++++++++++++++++-------------------
1 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index f7707f2..efb2dad 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -563,6 +563,26 @@ class Command:
class P4UserMap:
def __init__(self):
self.userMapFromPerforceServer = False
+ self.myP4UserId = None
+
+ def p4UserId(self):
+ if self.myP4UserId:
+ return self.myP4UserId
+
+ results = p4CmdList("user -o")
+ for r in results:
+ if r.has_key('User'):
+ self.myP4UserId = r['User']
+ return r['User']
+ die("Could not find your p4 user id")
+
+ def p4UserIsMe(self, p4User):
+ # return True if the given p4 user is actually me
+ me = self.p4UserId()
+ if not p4User or p4User != me:
+ return False
+ else:
+ return True
def getUserCacheFilename(self):
home = os.environ.get("HOME", os.environ.get("USERPROFILE"))
@@ -700,7 +720,6 @@ class P4Submit(Command, P4UserMap):
self.verbose = False
self.preserveUser = gitConfig("git-p4.preserveUser").lower() == "true"
self.isWindows = (platform.system() == "Windows")
- self.myP4UserId = None
def check(self):
if len(p4CmdList("opened ...")) > 0:
@@ -808,25 +827,6 @@ class P4Submit(Command, P4UserMap):
return 1
return 0
- def p4UserId(self):
- if self.myP4UserId:
- return self.myP4UserId
-
- results = p4CmdList("user -o")
- for r in results:
- if r.has_key('User'):
- self.myP4UserId = r['User']
- return r['User']
- die("Could not find your p4 user id")
-
- def p4UserIsMe(self, p4User):
- # return True if the given p4 user is actually me
- me = self.p4UserId()
- if not p4User or p4User != me:
- return False
- else:
- return True
-
def prepareSubmitTemplate(self):
# remove lines in the Files section that show changes to files outside the depot path we're committing into
template = ""
@@ -1664,6 +1664,12 @@ class P4Sync(Command, P4UserMap):
if self.stream_file.has_key('depotFile'):
self.streamOneP4File(self.stream_file, self.stream_contents)
+ def make_email(self, userid):
+ if userid in self.users:
+ return self.users[userid]
+ else:
+ return "%s <a@b>" % userid
+
def commit(self, details, files, branch, branchPrefixes, parent = ""):
epoch = details["time"]
author = details["user"]
@@ -1687,10 +1693,7 @@ class P4Sync(Command, P4UserMap):
committer = ""
if author not in self.users:
self.getUserMapFromPerforceServer()
- if author in self.users:
- committer = "%s %s %s" % (self.users[author], epoch, self.tz)
- else:
- committer = "%s <a@b> %s %s" % (author, epoch, self.tz)
+ committer = "%s %s %s" % (self.make_email(author), epoch, self.tz)
self.gitStream.write("committer %s\n" % committer)
@@ -1735,11 +1738,15 @@ class P4Sync(Command, P4UserMap):
self.gitStream.write("from %s\n" % branch)
owner = labelDetails["Owner"]
- tagger = ""
- if author in self.users:
- tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
+
+ # Try to use the owner of the p4 label, or failing that,
+ # the current p4 user id.
+ if owner:
+ email = self.make_email(owner)
else:
- tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
+ email = self.make_email(self.p4UserId())
+ tagger = "%s %s %s" % (email, epoch, self.tz)
+
self.gitStream.write("tagger %s\n" % tagger)
description = labelDetails["Description"]
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCH 4/4] git-p4: add test for p4 labels
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-1-git-send-email-luke@diamand.org>
Add basic test of p4 label import. Checks label import and
import with shell metachars; labels with different length
descriptions.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 73 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 73 insertions(+), 0 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
new file mode 100755
index 0000000..eba3521
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,73 @@
+test_description='git-p4 p4 label tests'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+# Basic p4 label tests.
+#
+# Note: can't have more than one label per commit - others
+# are silently discarded.
+#
+test_expect_success 'basic p4 labels' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ echo f2 >main/f2 &&
+ p4 add main/f2 &&
+ p4 submit -d "main/f2" &&
+
+ echo f3 >main/file_with_\$metachar &&
+ p4 add main/file_with_\$metachar &&
+ p4 submit -d "file with metachar" &&
+
+ p4 tag -l tag_f1_only main/f1 &&
+ p4 tag -l tag_with\$_shell_char main/... &&
+
+ echo f4 >main/f4 &&
+ p4 add main/f4 &&
+ p4 submit -d "main/f4" &&
+
+ p4 label -i <<-EOF &&
+ Label: long_label
+ Description:
+ A Label first line
+ A Label second line
+ View: //depot/...
+ EOF
+
+ p4 tag -l long_label ... &&
+
+ p4 labels ... &&
+
+ cd "$git" &&
+ pwd &&
+ "$GITP4" clone --dest=. --detect-labels //depot@all &&
+
+ git tag &&
+ git tag >taglist &&
+ test_line_count = 3 taglist &&
+
+ cd main &&
+ git checkout tag_tag_f1_only &&
+ ! test -f f2 &&
+ git checkout tag_tag_with\$_shell_char &&
+ test -f f1 && test -f f2 && test -f file_with_\$metachar &&
+
+ git show tag_long_label | grep -q "A Label second line"
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCH 2/4] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-1-git-send-email-luke@diamand.org>
Use an explicit length for the data in a label, rather
than EOT, so that labels with empty descriptions are
passed through correctly.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 822e6f1..f7707f2 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1741,9 +1741,11 @@ class P4Sync(Command, P4UserMap):
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
self.gitStream.write("tagger %s\n" % tagger)
- self.gitStream.write("data <<EOT\n")
- self.gitStream.write(labelDetails["Description"])
- self.gitStream.write("EOT\n\n")
+
+ description = labelDetails["Description"]
+ self.gitStream.write("data %d\n" % len(description))
+ self.gitStream.write(description)
+ self.gitStream.write("\n")
else:
if not self.silent:
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
From: Junio C Hamano @ 2012-01-16 23:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1326681407-6344-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Normally cache-tree will not produce trees from an index that has
> CE_INTENT_TO_ADD entries. This is a safe measure to avoid
> mis-interpreting user's intention regarding this flag.
s/safe/safety/;
> There are situations however where users want to create trees/commits
> regardless i-t-a entries.
A new command line option "--no-check-intent-to-add" to "commit" without
any configuration bit may be a useful addition as a first cut, and in
order to help users to which "there are situations" is more than 50% of
the time, a configuration that can be overriden by "--check-intent-to-add"
may be a usability improvement over that first cut, but if this is really
about "there are situations", then a configuration that cannot be
overriden by command line option feels a wrong way to go about it.
Is this really about "there are situations" to begin with? I am suspecting
that this patch is either:
(1) making it easier to use a wrong workflow, by promoting a way to
bypass a useful safety measure;
(2) fixing an earlier UI mistake (iow, the interpretation #2 in the old
discussion is always the right one and the existing safety measure is
misguided) in such a way that allows you to work around an objection
from a bonehead maintainer who refuses to admit that earlier mistake;
and/or
(3) splitting the Git userbase into two and making the resulting system
harder to teach.
If it is (2), and I suspect it may be the case, we might want to rather
honestly describe that the future direction is to fix it, and describe the
configuration option as "an early opt-in" switch, together with the usual
three-step deprecation and migration schedule to make the new behaviour
the default in a future version. From the timeline point of view, it
probably can coincide with the change to always start an editor when
recording a merge commit.
In any case, for this change to help people who add more than one paths
with "add -N" and want to include only a subset of them in the commit, we
may want to explicitly teach them to add what they want to before
committing with the new command line option in the documentation.
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Junio C Hamano @ 2012-01-16 23:33 UTC (permalink / raw)
To: Pete Harlan
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, linux-kernel,
Git Mailing List
In-Reply-To: <4F136BE4.4040502@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> On 01/10/2012 10:59 PM, Junio C Hamano wrote:
>> There may be existing scripts that leave the standard input and the
>> standard output of the "git merge" connected to whatever environment the
>> scripts were started, and such invocation might trigger the above
>> "interactive session" heuristics. Such scripts can export GIT_MERGE_LEGACY
>> environment variable set to "yes" to force the traditional behaviour.
>
> The name GIT_MERGE_LEGACY gives no clue about what flavor of legacy
> merge behavior is being enabled. Something like GIT_MERGE_LEGACY_EDIT
> might be clearer, or perhaps just have GIT_MERGE_EDIT=0 to get the old
> behavior without reference to whether or not that behavior is
> considered legacy.
Hrm.
The only case your suggestion may make a difference would be when we find
another earlier UI mistake we would want to correct in a backward
incompatible way that affects _existing_ scripts.
With your suggestion, they need to export "GIT_MERGE_EDIT=0" today, and
they will need to update again to export "GIT_MERGE_SOMETHINGELSE=0" when
such an incompatible change comes.
With a single "GIT_MERGE_LEGACY=YesPlease", they can be future-proofed today
and will not be affected when we make another incompatible change.
So I am not sure why separating the big-red-switch into smaller pieces
would be an improvement, especially wnen the scripts that want to specify
finer-grained control of features can use "--[no-]edit" options to
explicitly ask for it.
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-16 23:41 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20120116185738.GA21996@padd.com>
On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
> This looks much better without the need for "--force". It'll be
> great to fix this major branch detection problem. Can you make a
> couple of further minor changes?
Of course I can :)
>> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
>> @@ -2012,7 +2014,28 @@ class P4Sync(Command, P4UserMap):
>> - self.commit(description, filesForCommit, branch, [branchPrefix], parent)
>> + parentFound = 0
>> + if len(parent) > 0:
>> + self.checkpoint()
>> + for blob in read_pipe_lines("git rev-list --reverse --no-merges %s" % parent):
>> + blob = blob.strip()
>> + tempBranch = self.tempBranchLocation + os.sep + "%d-%s" % (change, blob)
>> + if self.verbose:
>> + print "Creating temporary branch: " + tempBranch
>> + self.commit(description, filesForCommit, tempBranch, [branchPrefix], blob)
>> + self.tempBranches.append(tempBranch)
>> + self.checkpoint()
>> + if len( read_pipe("git diff-tree %s %s" % (blob, tempBranch)) ) == 0:
>> + parentFound = 1
>> + if self.verbose:
>> + print "Found parent of %s in commit %s" % (branch, blob)
>> + break
>> + if parentFound:
>> + self.commit(description, filesForCommit, branch, [branchPrefix], blob)
>> + else:
>> + if self.verbose:
>> + print "Parent of %s not found. Committing into head of %s" % (branch, parent)
>> + self.commit(description, filesForCommit, branch, [branchPrefix], parent)
>
> 1. Move the tempBranch commit outside of the "for blob" loop.
> It can have no parent, and the diff-tree will still tell you
> if you found the same contents. Instead of a ref for
> each blob inspected for each change, you'll just have one ref
> per change. Only one checkpoint() after the tempBranch
> commit should be needed.
You're right. Completely oversaw that. Will improve the code
accordingly.
> 2. Nit. parentFound is boolean, use True/False, not 1/0.
That was not a nice thing to do... thanks for noticing :)
>> @@ -2347,6 +2370,12 @@ class P4Sync(Command, P4UserMap):
>> + # Cleanup temporary branches created during import
>> + if self.tempBranches != []:
>> + for branch in self.tempBranches:
>> + os.remove(".git" + os.sep + branch)
>> + os.rmdir(".git" + os.sep + self.tempBranchLocation)
>> +
>
> 3. Deleting refs should probably use "git update-ref -d"
> just in case GIT_DIR is not ".git". I think you could just
> leave the "git-p4-tmp" directory around, but use
> os.environ["GIT_DIR"] instead of ".git" if you want to
> delete it.
Will use os.environ.get, which can be configured to return ".git" if
$GIT_DIR is not defined. Is this ok?
> 4. Paths are best manipulated with os.path.join(dir, file), to handle
> weirdnesses like drive letters.
Perfect. I was completely unaware of that method. Thanks for the tip.
> Eventually if the fast-import protocol learns to delete the refs
> it creates, we can clean up a bit more nicely. I think there was
> agreement this was a good idea, just needs someone to do it
> sometime.
One can always hope ;)
Thanks,
Vitor
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Martin Fick @ 2012-01-16 23:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pete Harlan, Linus Torvalds, Mark Brown, Liam Girdwood,
linux-kernel, Git Mailing List
In-Reply-To: <7v62gbussz.fsf@alter.siamese.dyndns.org>
On Monday, January 16, 2012 04:33:00 pm Junio C Hamano
wrote:
> With your suggestion, they need to export
> "GIT_MERGE_EDIT=0" today, and they will need to update
> again to export "GIT_MERGE_SOMETHINGELSE=0" when such an
> incompatible change comes.
>
> With a single "GIT_MERGE_LEGACY=YesPlease", they can be
> future-proofed today and will not be affected when we
> make another incompatible change.
>
> So I am not sure why separating the big-red-switch into
> smaller pieces would be an improvement, especially wnen
> the scripts that want to specify finer-grained control
> of features can use "--[no-]edit" options to explicitly
> ask for it.
Then, what would I do if I write a script which uses the new
edit functionality (without even being aware that there was
an old way) and you introduce a new incompatibility? I
can't turn on GIT_MERGE_LEGACY then since it would revert to
behavior which my script would not expect (since it was
written after the current incompatibility, but before the
new one)!
-Martin
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-17 0:10 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <CAOpHH-UkyK-c_AHUOPbQQmW9cQQypDvirMR0Jb7vTGSQF7RZpw@mail.gmail.com>
On Mon, Jan 16, 2012 at 11:41 PM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
>> 1. Move the tempBranch commit outside of the "for blob" loop.
>> It can have no parent, and the diff-tree will still tell you
>> if you found the same contents. Instead of a ref for
>> each blob inspected for each change, you'll just have one ref
>> per change. Only one checkpoint() after the tempBranch
>> commit should be needed.
>
> You're right. Completely oversaw that. Will improve the code
> accordingly.
Apparently I did not oversee it. Assume you have added a new file to
HEAD of parent branch, but you branched from a previous commit. When the
new branch is committed over HEAD the new file will, incorrectly, be
part of it and diff-tree will not work as expected.
I should avoid taking 6 months to submit a patch to avoid forgetting why
I did what I did :)
Vitor
^ 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