* Re: git apply --directory broken for new files
From: Jeff King @ 2008-10-12 4:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Johannes Schindelin, Shawn O. Pearce,
Git Mailing List
In-Reply-To: <7vk5ceijqo.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 11, 2008 at 08:18:39PM -0700, Junio C Hamano wrote:
> I suspect this is only half of the story, because the code to parse:
>
> diff --git "a/f\244o/bar.c" "b/f\244o/bar.c"
>
> in the same function before the part you patched needs similar
> treatment. There are two return of strbuf_detach(&first, NULL)
> in the if(){} block, and the return value needs to be prefixed with the
> value of --directory when given.
Ah, indeed. I remember looking for other returns, but somehow I managed
to miss these completely obvious ones. Here is an updated patch, with a
third test that fails on the old patch but works here.
> It would be easier to do this --directory prefixing in the sole caller of
> git_header_name(), though.
I went this route, and it is much more readable if slightly less
efficient (one extra malloc/free).
-- >8 --
git apply --directory broken for new files
We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.
We simply need to prepend the root directory, if any, when
pulling the name out of the git header.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-apply.c | 7 ++++++
t/t4128-apply-root.sh | 52 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index bf80610..be7e1bd 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -810,6 +810,13 @@ static int parse_git_header(char *line, int len, unsigned int size, struct patch
* the default name from the header.
*/
patch->def_name = git_header_name(line, len);
+ if (patch->def_name && root) {
+ char *s = xmalloc(root_len + strlen(patch->def_name) + 1);
+ strcpy(s, root);
+ strcpy(s + root_len, patch->def_name);
+ free(patch->def_name);
+ patch->def_name = s;
+ }
line += len;
size -= len;
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index 2dd0c75..bc7a8a8 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -40,4 +40,56 @@ test_expect_success 'apply --directory -p (2) ' '
'
+cat > patch << EOF
+diff --git a/newfile b/newfile
+new file mode 100644
+index 0000000..d95f3ad
+--- /dev/null
++++ b/newfile
+@@ -0,0 +1 @@
++content
+EOF
+
+test_expect_success 'apply --directory (new file)' '
+ git reset --hard initial &&
+ git apply --directory=some/sub/dir/ --index patch &&
+ test content = $(git show :some/sub/dir/newfile) &&
+ test content = $(cat some/sub/dir/newfile)
+'
+
+cat > patch << EOF
+diff --git a/delfile b/delfile
+deleted file mode 100644
+index d95f3ad..0000000
+--- a/delfile
++++ /dev/null
+@@ -1 +0,0 @@
+-content
+EOF
+
+test_expect_success 'apply --directory (delete file)' '
+ git reset --hard initial &&
+ echo content >some/sub/dir/delfile &&
+ git add some/sub/dir/delfile &&
+ git apply --directory=some/sub/dir/ --index patch &&
+ ! git ls-files | grep delfile
+'
+
+cat > patch << 'EOF'
+diff --git "a/qu\157tefile" "b/qu\157tefile"
+new file mode 100644
+index 0000000..d95f3ad
+--- /dev/null
++++ "b/qu\157tefile"
+@@ -0,0 +1 @@
++content
+EOF
+
+test_expect_success 'apply --directory (quoted filename)' '
+ git reset --hard initial &&
+ git apply --directory=some/sub/dir/ --index patch &&
+ test content = $(git show :some/sub/dir/quotefile) &&
+ test content = $(cat some/sub/dir/quotefile)
+'
+
test_done
--
1.6.0.2.519.g6cb82.dirty
^ permalink raw reply related
* Re: Fwd: git status options feature suggestion
From: Jeff King @ 2008-10-12 4:49 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Caleb Cushing, git, Junio C Hamano
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>
On Thu, Oct 09, 2008 at 05:12:24PM +0200, Michael J Gruber wrote:
> - people are used to "svn status [-v]" like output which can include
> untracked as well as tracked unmodified files; there are other valid
> reasons why you would want that info
>
> - porc can't do it: git status can't show ignored files, doesn't use
> status letters, can't show files with specific status; git diff
> --name-status can't show ignored nor untracked files
> [In fact, the description of "git diff" says "files which you could
> add", which should include untracked files, but doesn't.]
>
> - plumb uses conflicting letters: git ls-files output conflicts with git
> diff --name-status output
>
> So I guess it's time for a usability effort in this area. A few
> questions before going about that:
A week or two ago I came across yet another git-status annoyance: it
needs write access to the repository to run (I was helping somebody with
a task on a shared box, and I wanted to run status in their repository
using my account).
I considered submitting a patch to fix this, but I think it is really
more fundamental. I use status to get an overview of what's going on in
a repo, but it is intimately related to a potential commit.
And this bleeds into other areas, too. Why should the "what's going on
in this repo" command prefix all lines with "#"? We would have more
freedom to change the format if it weren't required to be a comment
line in a commit message.
So I think it is probably reasonable to think about a new command (which
would not be called status) that shows this information. What do people
want to see? And in what format? Some things I would want or have seen
requested are:
- staged and unstaged changes in --name-status format
- files without changes (with a -v flag).
- untracked files
- current branch / detached HEAD (with relationship to tracked branch,
if any)
And maybe after hashing it out, it turns out it's not that different
from "git status" and we should just stick with that. But I would be
curious to hear proposals.
> - I think change of existing behaviour is unavoidable (make ls-files and
> diff --name-status consistent). Is that something to do now or rather
> before 1.7? Is porc (diff) supposed to be changed or plumb (ls-files)?
I don't think you would want to just change the default; you would
probably add a new option to ls-files to use the --name-status letters,
and then use that in your new porcelain.
> - How strong should the tie between git status and git commit be?
> Current git status is basically git commit -n, with the usual meaning of
> "-n" (such as for prune etc."), not with the current meaning of git
> commit -n, sigh...
I think the theoretical tool I mentioned would benefit from breaking
this connection. But I don't know whether it is prudent to take the
"status" name in doing so. Even if we decided to do so, it would
probably happen something like:
1. Introduce git-wtf, a new status-like tool. Deprecate git-status in
its current form.
2. Wait a really long time.
3. Rename git-wtf to git-status.
So either way, the first step is an alternative replacement command.
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Junio C Hamano @ 2008-10-12 5:24 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081007153543.GA26531@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Let's say I have a subdirectory of files, some of which are binary. But
> for those that _aren't_ binary, I want to use a particular funcname
> pattern. So I do this:
>
> echo '* diff=foo' >subdir/.gitattributes
> git config diff.foo.funcname some-regex
> ...
> In practice, this doesn't happen much, because funcname tends to follow
> the file extension, as does binary-ness.
I find this a highly contrived example. Is this ever be useful in
practice?
>> The reason why I'd like to understand the issue is because I like the
>> diff.foo.textconv that you introduce in patch 4/4, but I dislike that I
>> have to set diff.foo.binary to false in order to use the textconv. So, why
>> is this .binary needed?
>
> I think this .binary is something we can and should get rid of; as it
> stands now, you always end up having to set it along with .textconv. I
> have considered two ways:
The logic behind the original behaviour was that the file ought to be
"diff-able" if you are setting up funcname pattern because the funcname
pattern only makes sense if you are doing the textual diff. In other
words, "should we do textual diff?" and "what funcname pattern should we
use?" are _not_ orthogonal, as wanting to configure the latter does imply
that you do want to see the change in the textual diff format.
For the same rationale, if you have .textconv, I think it is natural for
us to say that you do want to see the change in the textual diff format.
So I'd agree that you can get rid of this .binary business by saying that
having .textconv marks it diffable (IOW, I think your first alternative
makes more sense).
^ permalink raw reply
* Re: [PATCH] git-svn: call 'fatal' correctly in set-tree
From: Junio C Hamano @ 2008-10-12 5:34 UTC (permalink / raw)
To: Luc Heinrich; +Cc: git, spearce
In-Reply-To: <1222696698-97356-1-git-send-email-luc@honk-honk.com>
Luc Heinrich <luc@honk-honk.com> writes:
> When doing a set-tree and there is no revision to commit to, the
> following unrelated error message is displayed: "Undefined subroutine
> &Git::SVN::fatal called at /opt/local/libexec/git-core/git-svn line
> 2575." The following patch fixes the problem and allows the real error
> message to be shown.
>
> Signed-off-by: Luc Heinrich <luc@honk-honk.com>
> ---
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 80a5728..7609a83 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2591,7 +2591,7 @@ sub set_tree {
> my ($self, $tree) = (shift, shift);
> my $log_entry = ::get_commit_entry($tree);
> unless ($self->{last_rev}) {
> - fatal("Must have an existing revision to commit");
> + ::fatal("Must have an existing revision to commit");
> }
> my %ed_opts = ( r => $self->{last_rev},
> log => $log_entry->{log},
Shouldn't the same change be done for the fatal call from apply_diff in
SVN::Git::Editor package?
^ permalink raw reply
* Re: git apply --directory broken for new files
From: Junio C Hamano @ 2008-10-12 6:36 UTC (permalink / raw)
To: Jeff King
Cc: H. Peter Anvin, Johannes Schindelin, Shawn O. Pearce,
Git Mailing List
In-Reply-To: <20081012040611.GA11199@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> It would be easier to do this --directory prefixing in the sole caller of
>> git_header_name(), though.
>
> I went this route, and it is much more readable if slightly less
> efficient (one extra malloc/free).
I do not think efficiency is an issue in this codepath --- especially
because it is only triggered when --directory is in use.
Acked-by: Junio C Hamano <gitster@pobox.com>
>
> -- >8 --
> git apply --directory broken for new files
>
> We carefully verify that the input to git-apply is sane,
> including cross-checking that the filenames we see in "+++"
> headers match what was provided on the command line of "diff
> --git". When --directory is used, however, we ended up
> comparing the unadorned name to one with the prepended root,
> causing us to complain about a mismatch.
>
> We simply need to prepend the root directory, if any, when
> pulling the name out of the git header.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> builtin-apply.c | 7 ++++++
> t/t4128-apply-root.sh | 52 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index bf80610..be7e1bd 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -810,6 +810,13 @@ static int parse_git_header(char *line, int len, unsigned int size, struct patch
> * the default name from the header.
> */
> patch->def_name = git_header_name(line, len);
> + if (patch->def_name && root) {
> + char *s = xmalloc(root_len + strlen(patch->def_name) + 1);
> + strcpy(s, root);
> + strcpy(s + root_len, patch->def_name);
> + free(patch->def_name);
> + patch->def_name = s;
> + }
>
> line += len;
> size -= len;
> diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
> index 2dd0c75..bc7a8a8 100755
> --- a/t/t4128-apply-root.sh
> +++ b/t/t4128-apply-root.sh
> @@ -40,4 +40,56 @@ test_expect_success 'apply --directory -p (2) ' '
>
> '
>
> +cat > patch << EOF
> +diff --git a/newfile b/newfile
> +new file mode 100644
> +index 0000000..d95f3ad
> +--- /dev/null
> ++++ b/newfile
> +@@ -0,0 +1 @@
> ++content
> +EOF
> +
> +test_expect_success 'apply --directory (new file)' '
> + git reset --hard initial &&
> + git apply --directory=some/sub/dir/ --index patch &&
> + test content = $(git show :some/sub/dir/newfile) &&
> + test content = $(cat some/sub/dir/newfile)
> +'
> +
> +cat > patch << EOF
> +diff --git a/delfile b/delfile
> +deleted file mode 100644
> +index d95f3ad..0000000
> +--- a/delfile
> ++++ /dev/null
> +@@ -1 +0,0 @@
> +-content
> +EOF
> +
> +test_expect_success 'apply --directory (delete file)' '
> + git reset --hard initial &&
> + echo content >some/sub/dir/delfile &&
> + git add some/sub/dir/delfile &&
> + git apply --directory=some/sub/dir/ --index patch &&
> + ! git ls-files | grep delfile
> +'
> +
> +cat > patch << 'EOF'
> +diff --git "a/qu\157tefile" "b/qu\157tefile"
> +new file mode 100644
> +index 0000000..d95f3ad
> +--- /dev/null
> ++++ "b/qu\157tefile"
> +@@ -0,0 +1 @@
> ++content
> +EOF
> +
> +test_expect_success 'apply --directory (quoted filename)' '
> + git reset --hard initial &&
> + git apply --directory=some/sub/dir/ --index patch &&
> + test content = $(git show :some/sub/dir/quotefile) &&
> + test content = $(cat some/sub/dir/quotefile)
> +'
> +
> test_done
> --
> 1.6.0.2.519.g6cb82.dirty
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Junio C Hamano @ 2008-10-12 6:41 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <20081012044900.GA27845@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So I think it is probably reasonable to think about a new command (which
> would not be called status) that shows this information.
I was going to suggest the same. "git st" for people who come from "svn st"
so that "git status" can be kept as traditional "preview of 'git commit'".
And just make it mimic whatever folks accustomed to "svn st" would expect,
modulo we would need two status letters to signal difference between
(HEAD, index), and (index, worktree). Perhaps three if you want to show
difference between (HEAD, worktree) while at it.
And no, I have not seen any argument good enough to change ls-files nor
diff-$lowlevel output and break people's existing scripts.
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Jeff King @ 2008-10-12 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <7vwsgegvsh.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:
> And just make it mimic whatever folks accustomed to "svn st" would expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree). Perhaps three if you want to show
> difference between (HEAD, worktree) while at it.
I remember a long time ago you started on a parallel diff walker that
could diff the working tree, the index, and a tree at once. Do you
remember the issues with it?
I think that would be the right tool here to show each file only once,
but with multiple status flags. Something like:
A M foo
to show that "foo" has been added since the last commit, but there are
modifications in the working tree that have not yet been staged.
-Peff
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Junio C Hamano @ 2008-10-12 8:10 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <20081012064512.GA32597@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I remember a long time ago you started on a parallel diff walker that
> could diff the working tree, the index, and a tree at once. Do you
> remember the issues with it?
Sorry, I don't.
> I think that would be the right tool here to show each file only once,
> but with multiple status flags. Something like:
>
> A M foo
>
> to show that "foo" has been added since the last commit, but there are
> modifications in the working tree that have not yet been staged.
One thing to keep in mind is what to do when you would want to detect
renames. The parallel walk would be Ok but between HEAD and index there
could be renames involved, and at that point it would get quite tricky.
Once the index is in-core, I think it hurts us much to walk HEAD vs index
and index vs working tree in separate passes.
I think it is perfectly fine to run the diff-index first, and keep the
result from it in a string_list, and then run "diff-files" and annotate
the string_list with the output from it.
Something like...
struct git_st_data {
const char *head_path;
char head_to_index_status;
char index_to_worktree_status;
};
static int cmp_head_path(const void *a_, const void *b_)
{
struct git_st_data *a = (struct git_st_data *)a_;
struct git_st_data *b = (struct git_st_data *)b_;
return strcmp(a->head_path, b->head_path);
}
static void git_st_inspect_index_cb(struct diff_queue_struct *q,
struct diff_options *opts, void *data)
{
struct string_list *git_st_list = data;
int i;
for (i = 0; i < q->nr; i++) {
struct git_st_data *d;
struct string_list_item *e;
struct diff_filepair *fp = &q->queue[i];
d = xcalloc(1, sizeof(*d));
d->head_path = xstrdup(fp->one->path);
e = string_list_insert(fp->two->path, git_st_list);
e->util = d;
d->head_to_index_status = fp->status;
}
}
static void git_st_inspect_file_cb(struct diff_queue_struct *q,
struct diff_options *opts, void *data)
{
struct string_list *git_st_list = data;
int i;
for (i = 0; i < q->nr; i++) {
struct git_st_data *d;
struct string_list_item *e;
struct diff_filepair *fp = &q->queue[i];
e = string_list_lookup(fp->one->path, git_st_list);
if (!e)
die("Oops -- shouldn't happen");
d = e->util;
d->index_to_worktree_status = fp->status;
}
}
void git_st_inspect(struct string_list *git_st_list)
{
struct rev_info rev;
git_st_list->items = NULL;
git_st_list->nr = git_st_list->alloc = 0;
git_st_list->strdup_strings = 1;
/*
* run "diff-index -B -M HEAD" and keep the result in a
* string list, keyed by the path in the index.
*/
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, "HEAD");
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = git_st_inspect_index_cb;
rev.diffopt.format_callback_data = git_st_list;
rev.diffopt.detect_rename = 1;
rev.diffopt.rename_limit = 200;
rev.diffopt.break_opt = 0;
run_diff_index(&rev, 1);
/*
* run "diff-files" and update the previous with the result.
*/
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = git_st_inspect_file_cb;
rev.diffopt.format_callback_data = git_st_list;
run_diff_files(&rev, 0);
/*
* sort the string-list entries in HEAD path order
*/
qsort(git_st_list->items, git_st_list->nr,
sizeof(struct string_list_item),
cmp_head_path);
}
Then git_st_inspect() can also be called by wt_status_print(), making it
unnecessary to do the equivalent of the above in wt_status_print_updated()
and wt_status_print_changed().
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Jeff King @ 2008-10-12 8:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Caleb Cushing, git, Junio C Hamano
In-Reply-To: <20081012044900.GA27845@coredump.intra.peff.net>
On Sun, Oct 12, 2008 at 12:49:00AM -0400, Jeff King wrote:
> A week or two ago I came across yet another git-status annoyance: it
> needs write access to the repository to run (I was helping somebody with
> a task on a shared box, and I wanted to run status in their repository
> using my account).
>
> I considered submitting a patch to fix this, but I think it is really
> more fundamental. I use status to get an overview of what's going on in
> a repo, but it is intimately related to a potential commit.
BTW, in case anybody is interested, here is the patch. Like I said, I
think we are better off with an alternative to "status", but maybe this
is useful to somebody anyway.
---
diff --git a/builtin-commit.c b/builtin-commit.c
index b01ad9f..8951364 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -217,7 +217,8 @@ static void create_base_index(void)
exit(128); /* We've already reported the error, finish dying */
}
-static char *prepare_index(int argc, const char **argv, const char *prefix)
+static char *prepare_index(int argc, const char **argv, const char *prefix,
+ int status_only)
{
int fd;
struct string_list partial;
@@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
* We still need to refresh the index here.
*/
if (!pathspec || !*pathspec) {
- fd = hold_locked_index(&index_lock, 1);
+ fd = hold_locked_index(&index_lock, 0);
+ if (fd < 0) {
+ if (!status_only)
+ die("unable to lock index: %s",
+ strerror(errno));
+ return get_index_file();
+ }
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
@@ -869,7 +876,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
argc = parse_and_validate_options(argc, argv, builtin_status_usage, prefix);
- index_file = prepare_index(argc, argv, prefix);
+ index_file = prepare_index(argc, argv, prefix, 1);
commitable = run_status(stdout, index_file, prefix, 0);
@@ -953,7 +960,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
argc = parse_and_validate_options(argc, argv, builtin_commit_usage, prefix);
- index_file = prepare_index(argc, argv, prefix);
+ index_file = prepare_index(argc, argv, prefix, 0);
/* Set up everything for writing the commit object. This includes
running hooks, writing the trees, and interacting with the user. */
^ permalink raw reply related
* Re: Fwd: git status options feature suggestion
From: Jakub Narebski @ 2008-10-12 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsgegvsh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> So I think it is probably reasonable to think about a new command (which
>> would not be called status) that shows this information.
>
> I was going to suggest the same. "git st" for people who come from "svn st"
> so that "git status" can be kept as traditional "preview of 'git commit'".
Or "git inspect". Or "git info".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Junio C Hamano @ 2008-10-12 9:58 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <20081012082607.GA17852@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> BTW, in case anybody is interested, here is the patch. Like I said, I
> think we are better off with an alternative to "status", but maybe this
> is useful to somebody anyway.
>
> ---
> diff --git a/builtin-commit.c b/builtin-commit.c
> index b01ad9f..8951364 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -217,7 +217,8 @@ static void create_base_index(void)
> exit(128); /* We've already reported the error, finish dying */
> }
>
> -static char *prepare_index(int argc, const char **argv, const char *prefix)
> +static char *prepare_index(int argc, const char **argv, const char *prefix,
> + int status_only)
> {
> int fd;
> struct string_list partial;
> @@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
> * We still need to refresh the index here.
> */
> if (!pathspec || !*pathspec) {
> - fd = hold_locked_index(&index_lock, 1);
> + fd = hold_locked_index(&index_lock, 0);
> + if (fd < 0) {
> + if (!status_only)
> + die("unable to lock index: %s",
> + strerror(errno));
> + return get_index_file();
> + }
> refresh_cache(REFRESH_QUIET);
You would probably want to refresh_cache() here even if you are not going
to write the resulting index out, so that you won't show the stat-only
differences to the end user. Other than that, I think this is a good
change.
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Leo Razoumov @ 2008-10-12 10:09 UTC (permalink / raw)
To: git
On 10/12/08, Junio C Hamano <gitster@pobox.com> wrote:
> [..snip..]
> I was going to suggest the same. "git st" for people who come from "svn st"
> so that "git status" can be kept as traditional "preview of 'git commit'".
>
> And just make it mimic whatever folks accustomed to "svn st" would expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree). Perhaps three if you want to show
> difference between (HEAD, worktree) while at it.
>
> And no, I have not seen any argument good enough to change ls-files nor
> diff-$lowlevel output and break people's existing scripts.
>
Please, at least introduce a new option (--status-letters) that makes
git log --name-status
git diff --name-status
git ls-files -v
to use consistent letters to indicate the status. For details, see
recent discussion
http://www.spinics.net/lists/git/msg81141.html
Thanks,
--Leo--
^ permalink raw reply
* Re: git status options feature suggestion
From: Wincent Colaiuta @ 2008-10-12 10:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Michael J Gruber, Johannes Schindelin, Caleb Cushing,
git
In-Reply-To: <7vwsgegvsh.fsf@gitster.siamese.dyndns.org>
El 12/10/2008, a las 8:41, Junio C Hamano escribió:
> Jeff King <peff@peff.net> writes:
>
>> So I think it is probably reasonable to think about a new command
>> (which
>> would not be called status) that shows this information.
>
> I was going to suggest the same. "git st" for people who come from
> "svn st"
> so that "git status" can be kept as traditional "preview of 'git
> commit'".
>
> And just make it mimic whatever folks accustomed to "svn st" would
> expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree). Perhaps three if you want to
> show
> difference between (HEAD, worktree) while at it.
One of the first aliases I set up when I started using git was "st"
for status, and I'd imagine that's a pretty common thing for people
coming from other SCMs like svn and cvs. But I very quickly became
used to git's notion of what "status" means and I wouldn't want "git
st" to start giving me a different behaviour.
I think if you're introducing a different command then you should make
sure it doesn't happen to be an abbreviation of an existing one. It
would be better to give it some other name (info, foo, whatever). If
svn people then want to make an "st" alias pointing to it they're free
to do so.
Just my 2c.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Documentation: remove stale howto/rebase-and-edit.txt
From: Thomas Rast @ 2008-10-12 11:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
The "rebase and edit" howto predates the much easier solution 'git
rebase -i' by two years.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/howto/rebase-and-edit.txt | 79 -------------------------------
1 files changed, 0 insertions(+), 79 deletions(-)
diff --git a/Documentation/howto/rebase-and-edit.txt b/Documentation/howto/rebase-and-edit.txt
deleted file mode 100644
index 554909f..0000000
--- a/Documentation/howto/rebase-and-edit.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Date: Sat, 13 Aug 2005 22:16:02 -0700 (PDT)
-From: Linus Torvalds <torvalds@osdl.org>
-To: Steve French <smfrench@austin.rr.com>
-cc: git@vger.kernel.org
-Subject: Re: sending changesets from the middle of a git tree
-Abstract: In this article, Linus demonstrates how a broken commit
- in a sequence of commits can be removed by rewinding the head and
- reapplying selected changes.
-
-On Sat, 13 Aug 2005, Linus Torvalds wrote:
-
-> That's correct. Same things apply: you can move a patch over, and create a
-> new one with a modified comment, but basically the _old_ commit will be
-> immutable.
-
-Let me clarify.
-
-You can entirely _drop_ old branches, so commits may be immutable, but
-nothing forces you to keep them. Of course, when you drop a commit, you'll
-always end up dropping all the commits that depended on it, and if you
-actually got somebody else to pull that commit you can't drop it from
-_their_ repository, but undoing things is not impossible.
-
-For example, let's say that you've made a mess of things: you've committed
-three commits "old->a->b->c", and you notice that "a" was broken, but you
-want to save "b" and "c". What you can do is
-
- # Create a branch "broken" that is the current code
- # for reference
- git branch broken
-
- # Reset the main branch to three parents back: this
- # effectively undoes the three top commits
- git reset HEAD^^^
- git checkout -f
-
- # Check the result visually to make sure you know what's
- # going on
- gitk --all
-
- # Re-apply the two top ones from "broken"
- #
- # First "parent of broken" (aka b):
- git-diff-tree -p broken^ | git-apply --index
- git commit --reedit=broken^
-
- # Then "top of broken" (aka c):
- git-diff-tree -p broken | git-apply --index
- git commit --reedit=broken
-
-and you've now re-applied (and possibly edited the comments) the two
-commits b/c, and commit "a" is basically gone (it still exists in the
-"broken" branch, of course).
-
-Finally, check out the end result again:
-
- # Look at the new commit history
- gitk --all
-
-to see that everything looks sensible.
-
-And then, you can just remove the broken branch if you decide you really
-don't want it:
-
- # remove 'broken' branch
- git branch -d broken
-
- # Prune old objects if you're really really sure
- git prune
-
-And yeah, I'm sure there are other ways of doing this. And as usual, the
-above is totally untested, and I just wrote it down in this email, so if
-I've done something wrong, you'll have to figure it out on your own ;)
-
- Linus
--
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at http://vger.kernel.org/majordomo-info.html
--
tg: (e782e12..) t/doc-remove-old-howto (depends on: spearce/master)
^ permalink raw reply related
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-12 11:28 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48EF7BC1.4000401@zytor.com>
H. Peter Anvin said the following on 2008-10-10 23:58:
> Wang Chen wrote:
>>>
>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>> 1.5.3.x)
>>
>> My git version is 1.5.5.1, although it doesn't matter ;)
>>
>
> http transport requires that "git update-server-info" is done after each
> push. Otherwise, it ends up in a trainwreck.
>
> Shawn Pierce at Google is working on a long-term solution, but in the
> meantime, if you have to use http transport, murder your IT people.
>
So, the current solutions are:
1. Waiting for Shawn fixing it.
2. Asking Ingo to "git update-server-info" after each push.
3. Murdering our IT people.
I'd rather to do the second solution than the third one :)
Ingo, will you do "git update-server-info" after each push before
Shawn fix this problem?
^ permalink raw reply
* Re: git status options feature suggestion
From: Teemu Likonen @ 2008-10-12 11:40 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Junio C Hamano, Jeff King, Michael J Gruber, Johannes Schindelin,
Caleb Cushing, git
In-Reply-To: <971DCAD3-3274-4507-AE3D-5BDCEDB8513C@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I think if you're introducing a different command then you should make
> sure it doesn't happen to be an abbreviation of an existing one. It
> would be better to give it some other name (info, foo, whatever). If
> svn people then want to make an "st" alias pointing to it they're free
> to do so.
In Subversion and Bazaar "info" command gives mostly information about
the repository itself. They don't talk about individual files at all.
"status" is the command (also in Mercurial) for getting information
about the current state of files in the tree.
I think it would be really sad if "git status" can't be extended to
match people's needs. I don't like the idea of a new name for such
status command. It's a kind of "why git people always invent new names
for familiar commands?" thing.
^ permalink raw reply
* Re: tip tree clone fail
From: Lars Hjemli @ 2008-10-12 12:04 UTC (permalink / raw)
To: Wang Chen
Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F1DF6A.4000900@cn.fujitsu.com>
On Sun, Oct 12, 2008 at 13:28, Wang Chen <wangchen@cn.fujitsu.com> wrote:
>
> H. Peter Anvin said the following on 2008-10-10 23:58:
> > Wang Chen wrote:
> >>>
> >>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
> >>> 1.5.3.x)
> >>
> >> My git version is 1.5.5.1, although it doesn't matter ;)
> >>
> >
> > http transport requires that "git update-server-info" is done after each
> > push. Otherwise, it ends up in a trainwreck.
> >
> > Shawn Pierce at Google is working on a long-term solution, but in the
> > meantime, if you have to use http transport, murder your IT people.
> >
>
>
> So, the current solutions are:
> 1. Waiting for Shawn fixing it.
> 2. Asking Ingo to "git update-server-info" after each push.
> 3. Murdering our IT people.
4. Install cgit, which removes the need for `git update-server-info`
--
larsh
^ permalink raw reply
* Re: tip tree clone fail
From: Ingo Molnar @ 2008-10-12 12:41 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48EF7BC1.4000401@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> Wang Chen wrote:
>>>
>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>> 1.5.3.x)
>>
>> My git version is 1.5.5.1, although it doesn't matter ;)
>>
>
> http transport requires that "git update-server-info" is done after
> each push. Otherwise, it ends up in a trainwreck.
can i simply put "git update-server-info" into .git/hooks/post-receive
to solve this problem?
Ingo
^ permalink raw reply
* Re: tip tree clone fail
From: Miklos Vajna @ 2008-10-12 12:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012124105.GA26988@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 243 bytes --]
On Sun, Oct 12, 2008 at 02:41:05PM +0200, Ingo Molnar <mingo@elte.hu> wrote:
> can i simply put "git update-server-info" into .git/hooks/post-receive
> to solve this problem?
Yes. And don't forget the chmod +x it, if it's not done yet.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH/RFC] gitweb: Separate features with no project specific override
From: Jakub Narebski @ 2008-10-12 13:05 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis
Put features for which project specific override is not supported into
separate %global_feature hash, updating gitweb_check_feature()
subroutine to use it.
While at it remove stale comment for 'pathinfo' feature; requiring to
use workaround specified was fixed in b65910f (gitweb: remove
PATH_INFO from $my_url and $my_uri).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch has the advantage of clear separation of non-overridable
and overridable features; currently the only difference is lack of
subroutine and comment on feature. For non-overridable features the
complexisty of {'sub'=>..., 'override'=>..., 'default'=>...} is not
needed.
It has the disadvantage of invalidating old gitweb configuration, and
that now there are two sources of gitweb config.
FIX IT: some spurious "HASH.." is printed to STDERR (by my 'run gitweb
from command line' script), which I didn't found yet.
gitweb/gitweb.perl | 59 ++++++++++++++++++++++++----------------------------
1 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6edbe..82068f9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -215,13 +215,6 @@ our %feature = (
'override' => 0,
'default' => ['tgz']},
- # Enable text search, which will list the commits which match author,
- # committer or commit text to a given string. Enabled by default.
- # Project specific override is not supported.
- 'search' => {
- 'override' => 0,
- 'default' => [1]},
-
# Enable grep search, which will list the files in currently selected
# tree containing the given string. Enabled by default. This can be
# potentially CPU-intensive, of course.
@@ -248,6 +241,18 @@ our %feature = (
'sub' => \&feature_pickaxe,
'override' => 0,
'default' => [1]},
+);
+
+our %global_feature = (
+ # feature => [ default options...] (array reference)
+ #
+ # For those features project specific override is not supported.
+ #
+ # use gitweb_check_feature(<feature>) to check if <feature> is enabled
+
+ # Enable text search, which will list the commits which match author,
+ # committer or commit text to a given string. Enabled by default.
+ 'search' => [1],
# Make gitweb use an alternative format of the URLs which can be
# more readable and natural-looking: project name is embedded
@@ -257,16 +262,8 @@ our %feature = (
# generates links.
# To enable system wide have in $GITWEB_CONFIG
- # $feature{'pathinfo'}{'default'} = [1];
- # Project specific override is not supported.
-
- # Note that you will need to change the default location of CSS,
- # favicon, logo and possibly other files to an absolute URL. Also,
- # if gitweb.cgi serves as your indexfile, you will need to force
- # $my_uri to contain the script name in your $GITWEB_CONFIG.
- 'pathinfo' => {
- 'override' => 0,
- 'default' => [0]},
+ # $global_feature{'pathinfo'} = [1];
+ 'pathinfo' => [0],
# Make gitweb consider projects in project root subdirectories
# to be forks of existing projects. Given project $projname.git,
@@ -277,11 +274,8 @@ our %feature = (
# to be listed after the main project.
# To enable system wide have in $GITWEB_CONFIG
- # $feature{'forks'}{'default'} = [1];
- # Project specific override is not supported.
- 'forks' => {
- 'override' => 0,
- 'default' => [0]},
+ # $global_feature{'forks'} = [1];
+ 'forks' => [0],
# Insert custom links to the action bar of all project pages.
# This enables you mainly to link to third-party scripts integrating
@@ -296,12 +290,9 @@ our %feature = (
# hash base (hb gitweb parameter); %% expands to %.
# To enable system wide have in $GITWEB_CONFIG e.g.
- # $feature{'actions'}{'default'} = [('graphiclog',
+ # $global_feature{'actions'} = [('graphiclog',
# '/git-browser/by-commit.html?r=%n', 'summary')];
- # Project specific override is not supported.
- 'actions' => {
- 'override' => 0,
- 'default' => []},
+ 'actions' => [],
# Allow gitweb scan project content tags described in ctags/
# of project repository, and display the popular Web 2.0-ish
@@ -315,16 +306,20 @@ our %feature = (
# a pretty tag cloud instead of just a list of tags.
# To enable system wide have in $GITWEB_CONFIG
- # $feature{'ctags'}{'default'} = ['path_to_tag_script'];
+ # $global_feature{'ctags'} = ['path_to_tag_script'];
# Project specific override is not supported.
- 'ctags' => {
- 'override' => 0,
- 'default' => [0]},
+ 'ctags' => [0],
);
sub gitweb_check_feature {
- my ($name) = @_;
+ my $name = shift;
+
+ if (exists $global_feature{$name}) {
+ return @{$global_feature{$name}};
+ }
+
return unless exists $feature{$name};
+
my ($sub, $override, @defaults) = (
$feature{$name}{'sub'},
$feature{$name}{'override'},
--
Stacked GIT 0.14.3
git version 1.6.0.2
^ permalink raw reply related
* Re: [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Dmitry Potapov @ 2008-10-12 13:39 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, spearce, git
In-Reply-To: <1223765806-3332-1-git-send-email-mlevedahl@gmail.com>
On Sat, Oct 11, 2008 at 06:56:46PM -0400, Mark Levedahl wrote:
> diff --git a/compat/cygwin.c b/compat/cygwin.c
> index 423ff20..1fed265 100644
> --- a/compat/cygwin.c
> +++ b/compat/cygwin.c
> @@ -91,13 +91,20 @@ static int cygwin_stat(const char *path, struct stat *buf)
> * functions should be used. The choice is determined by core.ignorecygwinfstricks.
> * Reading this option is not always possible immediately as git_dir may be
> * not be set yet. So until it is set, use cygwin lstat/stat functions.
> + * However, if core.filemode is true, we *must* use the Cygwin posix stat as
> + * the Windows stat fuctions do not determine posix filemode.
> */
> static int native_stat = 1;
> +static int core_filemode = 0;
Is it a reason to add a new variable instead of using trust_executable_bit?
And if so, why its default value is different? I know that this default does
not matter usually, because core.filemode is always stored in .git/config,
but still I don't like this discrapency.
Otherwise, I don't have any objection to this patch.
Dmitry
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Dmitry Potapov @ 2008-10-12 13:50 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Sixt, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <81b0412b0810111558vb69be00if4842fa91d777c3b@mail.gmail.com>
On Sun, Oct 12, 2008 at 12:58:52AM +0200, Alex Riesen wrote:
> 2008/10/11 Dmitry Potapov <dpotapov@gmail.com>:
> >> > + /* On Windows, file names are case-insensitive */
> >> > + case 'G':
> >> > + if ((rest[1]|0x20) != 'i')
> >> > + break;
> >> > + if ((rest[2]|0x20) != 't')
> >> > + break;
> >>
> >> We have tolower().
> >
> > I am aware of that, but I am not sure what we gain by using it. It seems
> > it makes only code bigger and slow.
>
> It does? Care to look into git-compat-util.h?
As a matter of fact, I did, and I see the following:
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
static inline int sane_case(int x, int high)
{
if (sane_istest(x, GIT_ALPHA))
x = (x & ~0x20) | high;
return x;
}
So, it looks like an extra look up and an extra comparison here.
>
> > ... As to readability, I don't see much
> > improvement... Isn't obvious what this code does, especially with the
> > above comment?
>
> You want to seriously argue that "a | 0x20" is as readable as "tolower(a)"?
> For the years to come? With a person who does not even know what ASCII is?
> Ok, I'm exaggerating. But the point is: it is not us who will be
> reading the code.
Obviously, for a person who don't know what ASCII is, tolower() will be
much easier to understand, but the question is what I can reasonable to
expect for a person reading this code later. A similar argument can be
made about adding extra parenthesis, i.e. instead of writing
if (a == b || c == d)
you should always write
if ((a == b) || (c == d))
because some people do not remember the priority of each operator.
(And I have seen such programmers who claim to have many experience of
writing in C, yet, they do not remember operator priority.)
For me, using tolower() does not make it more readable, but maybe I am
too old-fashion assuming that people are supposed to know at least basic
things about ASCII.
> BTW, is it such a critical path?
I am not sure whether it is critical or not. It is called for each
name in path. So, if you have a long path, it may be called quite a
few times per a single path. Also, some operation such 'git add' can
call verify_path() more than once (IIRC, it was called thrice per each
added file). But I have no numbers to tell whether it is noticeable or
not.
> Can't the code be unified and do without #ifdef?
It will impose a extra restriction on what file names people can use,
and I don't like extra restrictions for those who use sane file systems.
Dmitry
^ permalink raw reply
* Re: git status options feature suggestion
From: Andreas Ericsson @ 2008-10-12 13:52 UTC (permalink / raw)
To: Teemu Likonen
Cc: Wincent Colaiuta, Junio C Hamano, Jeff King, Michael J Gruber,
Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <87od1qrqhi.fsf@iki.fi>
Teemu Likonen wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> I think if you're introducing a different command then you should make
>> sure it doesn't happen to be an abbreviation of an existing one. It
>> would be better to give it some other name (info, foo, whatever). If
>> svn people then want to make an "st" alias pointing to it they're free
>> to do so.
>
> In Subversion and Bazaar "info" command gives mostly information about
> the repository itself. They don't talk about individual files at all.
> "status" is the command (also in Mercurial) for getting information
> about the current state of files in the tree.
>
> I think it would be really sad if "git status" can't be extended to
> match people's needs. I don't like the idea of a new name for such
> status command. It's a kind of "why git people always invent new names
> for familiar commands?" thing.
Well, the solution is fairly simple then. Just make it configurable and
set it in your ~/.gitconfig. It's not my itch to scratch though. I
loathe the sparse output from cvs/svn/whatnot and would be just as happy
if I never had to look at it again. I can understand its usefulness for
scripting, but 'git status' is porcelain so for that purpose it really
belongs somewhere else.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-12 14:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012124105.GA26988@elte.hu>
Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>
>> Wang Chen wrote:
>>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>>> 1.5.3.x)
>>> My git version is 1.5.5.1, although it doesn't matter ;)
>>>
>> http transport requires that "git update-server-info" is done after
>> each push. Otherwise, it ends up in a trainwreck.
>
> can i simply put "git update-server-info" into .git/hooks/post-receive
> to solve this problem?
>
post-update, rather than post-receive.
The standard post-update.sample contains it, it just needs a rename.
-hpa
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-12 14:15 UTC (permalink / raw)
To: Wang Chen
Cc: Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F1DF6A.4000900@cn.fujitsu.com>
Wang Chen wrote:
>
> So, the current solutions are:
> 1. Waiting for Shawn fixing it.
> 2. Asking Ingo to "git update-server-info" after each push.
> 3. Murdering our IT people.
>
> I'd rather to do the second solution than the third one :)
>
Actually, the third solution is the proper one given the circumstances
you find yourself in. None of this would be a problem if there wasn't a
bunch of companies with incompetent network management.
-hpa
^ 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