* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
From: Junio C Hamano @ 2006-05-24 4:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060524035234.GA13329@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Sure. I've been putting it off as I've been busy the past few days
> and have also been thinking about trying to rebuild reflog using a
> tag/annotation branch style, which might be more generally useful
> to others. So I've been debating about whether or not I should
> ask you to pop reflog out of pu indefinately.
Heh, too late for that -- it looked OK so now they are part of
"next" to get wider exposure.
^ permalink raw reply
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
From: Shawn Pearce @ 2006-05-24 3:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk68fyarn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I've swallowed all 10 and pushed them out in "pu", but could you
> add tests to check the Porcelainish commands you touched with
> this series to make sure they all log correctly?
Sure. I've been putting it off as I've been busy the past few days
and have also been thinking about trying to rebuild reflog using a
tag/annotation branch style, which might be more generally useful
to others. So I've been debating about whether or not I should
ask you to pop reflog out of pu indefinately.
> BTW, I noticed that a patch earlier in the series depended on
> something not in "master" (it's rfc2822_date from js/fmt-patch
> series). Generally I do not want to make a branch hostage of
> another branch by introducing a dependency, but for now I'll
> pull in early part of js/fmt-patch branch into sp/reflog branch
> and see what happens.
Doh. Sorry about that one. I saw it in date.c and used it, not
realizing it was only in pu.
--
Shawn.
^ permalink raw reply
* [PATCH] git-svn: ignore expansion of svn:keywords
From: Eric Wong @ 2006-05-24 2:23 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: Junio C Hamano, git, Eric Wong
In-Reply-To: <11484374222795-git-send-email-normalperson@yhbt.net>
Unlike my earlier test patch, this also checks svn:eol-style and
makes sure it's applied to working copy updates. This is
definitely more correct than my original attempt at killing
keyword expansions, but I still haven't tested it enough to
know. Feedback would be much appreciated.
Also changed assert_svn_wc_clean() to only work on the svn
working copy. This requires a separate call to assert_tree() to
check wc integrity against git in preparation for another change
I'm planning.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/Makefile | 1
contrib/git-svn/git-svn.perl | 106 +++++++++++++++----
contrib/git-svn/t/lib-git-svn.sh | 39 +++++++
contrib/git-svn/t/t0000-contrib-git-svn.sh | 43 --------
contrib/git-svn/t/t0001-contrib-git-svn-props.sh | 125 ++++++++++++++++++++++
5 files changed, 254 insertions(+), 60 deletions(-)
create mode 100644 contrib/git-svn/t/lib-git-svn.sh
create mode 100644 contrib/git-svn/t/t0001-contrib-git-svn-props.sh
b9ba79157fc4f92e14aac89d9a5f838539d6eede
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index acedf73..48f60b3 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -30,6 +30,7 @@ git-svn.html : git-svn.txt
-f ../../Documentation/asciidoc.conf $<
test: git-svn
cd t && $(SHELL) ./t0000-contrib-git-svn.sh
+ cd t && $(SHELL) ./t0001-contrib-git-svn-props.sh
clean:
rm -f git-svn *.xml *.html *.1
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 39471b5..fc9b7ef 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -39,6 +39,10 @@ my $_svn_co_url_revs;
my %fc_opts = ( 'no-ignore-externals' => \$_no_ignore_ext,
'branch|b=s' => \@_branch_from,
'authors-file|A=s' => \$_authors );
+
+# yes, 'native' sets "\n". Patches to fix this for non-*nix systems welcome:
+my %EOL = ( CR => "\015", LF => "\012", CRLF => "\015\012", native => "\012" );
+
my %cmd = (
fetch => [ \&fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision, %fc_opts } ],
@@ -207,7 +211,7 @@ sub rebuild {
push @svn_up, '--ignore-externals' unless $_no_ignore_ext;
sys(@svn_up,"-r$newest_rev");
$ENV{GIT_INDEX_FILE} = $GIT_SVN_INDEX;
- git_addremove();
+ index_changes();
exec('git-write-tree');
}
waitpid $pid, 0;
@@ -249,7 +253,7 @@ sub fetch {
chdir $SVN_WC or croak $!;
read_uuid();
$last_commit = git_commit($base, @parents);
- assert_svn_wc_clean($base->{revision}, $last_commit);
+ assert_tree($last_commit);
} else {
chdir $SVN_WC or croak $!;
read_uuid();
@@ -259,16 +263,20 @@ sub fetch {
push @svn_up, '--ignore-externals' unless $_no_ignore_ext;
my $last = $base;
while (my $log_msg = next_log_entry($svn_log)) {
- assert_svn_wc_clean($last->{revision}, $last_commit);
+ assert_tree($last_commit);
if ($last->{revision} >= $log_msg->{revision}) {
croak "Out of order: last >= current: ",
"$last->{revision} >= $log_msg->{revision}\n";
}
+ # Revert is needed for cases like:
+ # https://svn.musicpd.org/Jamming/trunk (r166:167), but
+ # I can't seem to reproduce something like that on a test...
+ sys(qw/svn revert -R ./);
+ assert_svn_wc_clean($last->{revision});
sys(@svn_up,"-r$log_msg->{revision}");
$last_commit = git_commit($log_msg, $last_commit, @parents);
$last = $log_msg;
}
- assert_svn_wc_clean($last->{revision}, $last_commit);
unless (-e "$GIT_DIR/refs/heads/master") {
sys(qw(git-update-ref refs/heads/master),$last_commit);
}
@@ -314,7 +322,6 @@ sub commit {
$svn_current_rev = svn_commit_tree($svn_current_rev, $c);
}
print "Done committing ",scalar @revs," revisions to SVN\n";
-
}
sub show_ignore {
@@ -367,13 +374,11 @@ sub setup_git_svn {
}
sub assert_svn_wc_clean {
- my ($svn_rev, $treeish) = @_;
+ my ($svn_rev) = @_;
croak "$svn_rev is not an integer!\n" unless ($svn_rev =~ /^\d+$/);
- croak "$treeish is not a sha1!\n" unless ($treeish =~ /^$sha1$/o);
my $lcr = svn_info('.')->{'Last Changed Rev'};
if ($svn_rev != $lcr) {
print STDERR "Checking for copy-tree ... ";
- # use
my @diff = grep(/^Index: /,(safe_qx(qw(svn diff),
"-r$lcr:$svn_rev")));
if (@diff) {
@@ -389,7 +394,6 @@ sub assert_svn_wc_clean {
print STDERR $_ foreach @status;
croak;
}
- assert_tree($treeish);
}
sub assert_tree {
@@ -416,7 +420,7 @@ sub assert_tree {
unlink $tmpindex or croak $!;
}
$ENV{GIT_INDEX_FILE} = $tmpindex;
- git_addremove();
+ index_changes(1);
chomp(my $tree = `git-write-tree`);
if ($old_index) {
$ENV{GIT_INDEX_FILE} = $old_index;
@@ -426,6 +430,7 @@ sub assert_tree {
if ($tree ne $expected) {
croak "Tree mismatch, Got: $tree, Expected: $expected\n";
}
+ unlink $tmpindex;
}
sub parse_diff_tree {
@@ -562,7 +567,8 @@ sub precommit_check {
sub svn_checkout_tree {
my ($svn_rev, $treeish) = @_;
my $from = file_to_s("$REV_DIR/$svn_rev");
- assert_svn_wc_clean($svn_rev,$from);
+ assert_svn_wc_clean($svn_rev);
+ assert_tree($from);
print "diff-tree $from $treeish\n";
my $pid = open my $diff_fh, '-|';
defined $pid or croak $!;
@@ -852,13 +858,75 @@ sub svn_info {
sub sys { system(@_) == 0 or croak $? }
-sub git_addremove {
- system( "git-diff-files --name-only -z ".
- " | git-update-index --remove -z --stdin && ".
- "git-ls-files -z --others ".
- "'--exclude-from=$GIT_DIR/$GIT_SVN/info/exclude'".
- " | git-update-index --add -z --stdin"
- ) == 0 or croak $?
+sub eol_cp {
+ my ($from, $to) = @_;
+ my $es = safe_qx(qw/svn propget svn:eol-style/, $to);
+ open my $rfd, '<', $from or croak $!;
+ binmode $rfd or croak $!;
+ open my $wfd, '>', $to or croak $!;
+ binmode $wfd or croak $!;
+
+ my $eol = $EOL{$es} or undef;
+ if ($eol) {
+ print "$eol: $from => $to\n";
+ }
+ my $buf;
+ while (1) {
+ my ($r, $w, $t);
+ defined($r = sysread($rfd, $buf, 4096)) or croak $!;
+ return unless $r;
+ $buf =~ s/(?:\015|\012|\015\012)/$eol/gs if $eol;
+ for ($w = 0; $w < $r; $w += $t) {
+ $t = syswrite($wfd, $buf, $r - $w, $w) or croak $!;
+ }
+ }
+}
+
+sub do_update_index {
+ my ($z_cmd, $cmd, $no_text_base) = @_;
+
+ my $z = open my $p, '-|';
+ defined $z or croak $!;
+ unless ($z) { exec @$z_cmd or croak $! }
+
+ my $pid = open my $ui, '|-';
+ defined $pid or croak $!;
+ unless ($pid) {
+ exec('git-update-index',"--$cmd",'-z','--stdin') or croak $!;
+ }
+ local $/ = "\0";
+ while (my $x = <$p>) {
+ chomp $x;
+ if (!$no_text_base && lstat $x && ! -l _ &&
+ safe_qx(qw/svn propget svn:keywords/,$x)) {
+ my $mode = -x _ ? 0755 : 0644;
+ my ($v,$d,$f) = File::Spec->splitpath($x);
+ my $tb = File::Spec->catfile($d, '.svn', 'tmp',
+ 'text-base',"$f.svn-base");
+ $tb =~ s#^/##;
+ unless (-f $tb) {
+ $tb = File::Spec->catfile($d, '.svn',
+ 'text-base',"$f.svn-base");
+ $tb =~ s#^/##;
+ }
+ unlink $x or croak $!;
+ eol_cp($tb, $x);
+ chmod(($mode &~ umask), $x) or croak $!;
+ }
+ print $ui $x,"\0";
+ }
+ close $ui or croak $!;
+}
+
+sub index_changes {
+ my $no_text_base = shift;
+ do_update_index([qw/git-diff-files --name-only -z/],
+ 'remove',
+ $no_text_base);
+ do_update_index([qw/git-ls-files -z --others/,
+ "--exclude-from=$GIT_DIR/$GIT_SVN/info/exclude"],
+ 'add',
+ $no_text_base);
}
sub s_to_file {
@@ -936,7 +1004,7 @@ sub git_commit {
defined $pid or croak $!;
if ($pid == 0) {
$ENV{GIT_INDEX_FILE} = $GIT_SVN_INDEX;
- git_addremove();
+ index_changes();
chomp(my $tree = `git-write-tree`);
croak if $?;
if (exists $tree_map{$tree}) {
diff --git a/contrib/git-svn/t/lib-git-svn.sh b/contrib/git-svn/t/lib-git-svn.sh
new file mode 100644
index 0000000..a98e9d1
--- /dev/null
+++ b/contrib/git-svn/t/lib-git-svn.sh
@@ -0,0 +1,39 @@
+PATH=$PWD/../:$PATH
+if test -d ../../../t
+then
+ cd ../../../t
+else
+ echo "Must be run in contrib/git-svn/t" >&2
+ exit 1
+fi
+
+. ./test-lib.sh
+
+GIT_DIR=$PWD/.git
+GIT_SVN_DIR=$GIT_DIR/git-svn
+SVN_TREE=$GIT_SVN_DIR/tree
+
+svnadmin >/dev/null 2>&1
+if test $? != 1
+then
+ test_expect_success 'skipping contrib/git-svn test' :
+ test_done
+ exit
+fi
+
+svn >/dev/null 2>&1
+if test $? != 1
+then
+ test_expect_success 'skipping contrib/git-svn test' :
+ test_done
+ exit
+fi
+
+svnrepo=$PWD/svnrepo
+
+set -e
+
+svnadmin create $svnrepo
+svnrepo="file://$svnrepo/test-git-svn"
+
+
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/contrib/git-svn/t/t0000-contrib-git-svn.sh
index f400202..a07fbad 100644
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/contrib/git-svn/t/t0000-contrib-git-svn.sh
@@ -3,48 +3,10 @@ #
# Copyright (c) 2006 Eric Wong
#
-
-PATH=$PWD/../:$PATH
test_description='git-svn tests'
-if test -d ../../../t
-then
- cd ../../../t
-else
- echo "Must be run in contrib/git-svn/t" >&2
- exit 1
-fi
-
-. ./test-lib.sh
-
-GIT_DIR=$PWD/.git
-GIT_SVN_DIR=$GIT_DIR/git-svn
-SVN_TREE=$GIT_SVN_DIR/tree
-
-svnadmin >/dev/null 2>&1
-if test $? != 1
-then
- test_expect_success 'skipping contrib/git-svn test' :
- test_done
- exit
-fi
-
-svn >/dev/null 2>&1
-if test $? != 1
-then
- test_expect_success 'skipping contrib/git-svn test' :
- test_done
- exit
-fi
-
-svnrepo=$PWD/svnrepo
-
-set -e
-
-svnadmin create $svnrepo
-svnrepo="file://$svnrepo/test-git-svn"
+. ./lib-git-svn.sh
mkdir import
-
cd import
echo foo > foo
@@ -55,10 +17,9 @@ mkdir -p bar
echo 'zzz' > bar/zzz
echo '#!/bin/sh' > exec.sh
chmod +x exec.sh
-svn import -m 'import for git-svn' . $svnrepo >/dev/null
+svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
cd ..
-
rm -rf import
test_expect_success \
diff --git a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
new file mode 100644
index 0000000..6fa7889
--- /dev/null
+++ b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
@@ -0,0 +1,125 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+
+test_description='git-svn property tests'
+. ./lib-git-svn.sh
+
+mkdir import
+
+a_crlf=
+a_lf=
+a_cr=
+a_ne_crlf=
+a_ne_lf=
+a_ne_cr=
+a_empty=
+a_empty_lf=
+a_empty_cr=
+a_empty_crlf=
+
+cd import
+ cat >> kw.c <<''
+/* Make it look like somebody copied a file from CVS into SVN: */
+/* $Id: kw.c,v 1.1.1.1 1994/03/06 00:00:00 eric Exp $ */
+
+ printf "Hello\r\nWorld\r\n" > crlf
+ a_crlf=`git-hash-object -w crlf`
+ printf "Hello\rWorld\r" > cr
+ a_cr=`git-hash-object -w cr`
+ printf "Hello\nWorld\n" > lf
+ a_lf=`git-hash-object -w lf`
+
+ printf "Hello\r\nWorld" > ne_crlf
+ a_ne_crlf=`git-hash-object -w ne_crlf`
+ printf "Hello\nWorld" > ne_lf
+ a_ne_lf=`git-hash-object -w ne_lf`
+ printf "Hello\rWorld" > ne_cr
+ a_ne_cr=`git-hash-object -w ne_cr`
+
+ touch empty
+ a_empty=`git-hash-object -w empty`
+ printf "\n" > empty_lf
+ a_empty_lf=`git-hash-object -w empty_lf`
+ printf "\r" > empty_cr
+ a_empty_cr=`git-hash-object -w empty_cr`
+ printf "\r\n" > empty_crlf
+ a_empty_crlf=`git-hash-object -w empty_crlf`
+
+ svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
+cd ..
+
+rm -rf import
+svn co "$svnrepo" test_wc
+
+cd test_wc
+ echo 'Greetings' >> kw.c
+ svn commit -m 'Not yet an $Id$'
+ svn up
+
+ echo 'Hello world' >> kw.c
+ svn commit -m 'Modified file, but still not yet an $Id$'
+ svn up
+
+ svn propset svn:keywords Id kw.c
+ svn commit -m 'Propset $Id$'
+ svn up
+cd ..
+
+git-svn init "$svnrepo"
+git-svn fetch
+
+git checkout -b mybranch remotes/git-svn
+echo 'Hi again' >> kw.c
+name='test svn:keywords ignoring'
+
+git commit -a -m "$name"
+git-svn commit remotes/git-svn..mybranch
+git pull . remotes/git-svn
+
+expect='/* $Id$ */'
+got="`sed -ne 2p kw.c`"
+test_expect_success 'raw $Id$ found in kw.c' "test '$expect' = '$got'"
+
+cd test_wc
+ svn propset svn:eol-style CR empty
+ svn propset svn:eol-style CR crlf
+ svn propset svn:eol-style CR ne_crlf
+ svn commit -m 'propset CR on crlf files'
+ svn up
+cd ..
+
+git-svn fetch
+git pull . remotes/git-svn
+
+svn co "$svnrepo" new_wc
+for i in crlf ne_crlf lf ne_lf cr ne_cr empty_cr empty_lf empty empty_crlf
+do
+ test_expect_success "Comparing $i" "cmp $i new_wc/$i"
+done
+
+
+cd test_wc
+ printf '$Id$\rHello\rWorld\r' > cr
+ printf '$Id$\rHello\rWorld' > ne_cr
+ a_cr=`printf '$Id$\r\nHello\r\nWorld\r\n' | git-hash-object --stdin`
+ a_ne_cr=`printf '$Id$\r\nHello\r\nWorld' | git-hash-object --stdin`
+ svn propset svn:eol-style CRLF cr
+ svn propset svn:eol-style CRLF ne_cr
+ svn propset svn:keywords Id cr
+ svn propset svn:keywords Id ne_cr
+ svn commit -m 'propset CRLF on cr files'
+ svn up
+cd ..
+
+git-svn fetch
+git pull . remotes/git-svn
+
+b_cr="`git-hash-object cr`"
+b_ne_cr="`git-hash-object ne_cr`"
+
+test_expect_success 'CRLF + $Id$' "test '$a_cr' = '$b_cr'"
+test_expect_success 'CRLF + $Id$ (no newline)' "test '$a_ne_cr' = '$b_ne_cr'"
+
+test_done
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH] git-svn: starting a 1.1.0-pre development version
From: Eric Wong @ 2006-05-24 2:23 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: Junio C Hamano, git, Eric Wong
In-Reply-To: <11484374214073-git-send-email-normalperson@yhbt.net>
Some not-very-well-tested changes coming...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
49967a4b7bc2c9938b0ebf0670cd47d4ccfe85a3
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index de13a96..39471b5 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $REV_DIR/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
-$VERSION = '1.0.0';
+$VERSION = '1.1.0-pre';
use Cwd qw/abs_path/;
$GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
--
1.3.2.g7d11
^ permalink raw reply related
* Re: git-svn vs. $Id$
From: Eric Wong @ 2006-05-24 2:23 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: Junio C Hamano, git
In-Reply-To: <20060521030330.GA15812@soma>
Tommi: I'm reasonably confident about this patch, but I won't be
getting much real-world usage since I rarely see repos that use
svn:keywords, and I'm afflicted with RSI which prevents me from
doing very much in front of a computer these days. So
feedback/testing from you or any other git-svn guine^Wusers
would be greatly appreciated.
Junio: This is probably safe enough for next or even master, the
one in pu is completely broken wrt svn:eol-style.
^ permalink raw reply
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Linus Torvalds @ 2006-05-24 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.64.0605231905470.5623@g5.osdl.org>
On Tue, 23 May 2006, Linus Torvalds wrote:
>
> + /*
> + * If we don't have any trailing data in the patch,
> + * we want to match the final ending '\0' byte in
> + * the file too..
> + */
Btw, ignore the comment. I was thinking of doing the matching differently
(just make the source buffer include a '\0' at the end, and forcing that
to match), but once I actually wrote it, it ended up being much easier to
just check the offset/size difference.
So that "final ending '\0' byte in the file" part of the comment is just
nonsense.
Linus
^ permalink raw reply
* [PATCH] git-svn: t0000: add -f flag to checkout
From: Eric Wong @ 2006-05-24 2:13 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
Some changes to the latest git.git made this test croak. So
we'll always just force everything when using a new branch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/t/t0000-contrib-git-svn.sh | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
9439cefac1aa09cdc8553f452d84ddf71be2f909
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/contrib/git-svn/t/t0000-contrib-git-svn.sh
index 80ad357..f400202 100644
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/contrib/git-svn/t/t0000-contrib-git-svn.sh
@@ -71,7 +71,7 @@ test_expect_success \
name='try a deep --rmdir with a commit'
-git checkout -b mybranch remotes/git-svn
+git checkout -f -b mybranch remotes/git-svn
mv dir/a/b/c/d/e/file dir/file
cp dir/file file
git update-index --add --remove dir/a/b/c/d/e/file dir/file file
@@ -97,7 +97,7 @@ test_expect_code 1 "$name" \
name='detect node change from directory to file #1'
rm -rf dir $GIT_DIR/index
-git checkout -b mybranch2 remotes/git-svn
+git checkout -f -b mybranch2 remotes/git-svn
mv bar/zzz zzz
rm -rf bar
mv zzz bar
@@ -112,7 +112,7 @@ test_expect_code 1 "$name" \
name='detect node change from file to directory #2'
rm -f $GIT_DIR/index
-git checkout -b mybranch3 remotes/git-svn
+git checkout -f -b mybranch3 remotes/git-svn
rm bar/zzz
git-update-index --remove bar/zzz
mkdir bar/zzz
@@ -127,7 +127,7 @@ test_expect_code 1 "$name" \
name='detect node change from directory to file #2'
rm -f $GIT_DIR/index
-git checkout -b mybranch4 remotes/git-svn
+git checkout -f -b mybranch4 remotes/git-svn
rm -rf dir
git update-index --remove -- dir/file
touch dir
@@ -142,7 +142,7 @@ test_expect_code 1 "$name" \
name='remove executable bit from a file'
rm -f $GIT_DIR/index
-git checkout -b mybranch5 remotes/git-svn
+git checkout -f -b mybranch5 remotes/git-svn
chmod -x exec.sh
git update-index exec.sh
git commit -m "$name"
--
1.3.2.g7d11
^ permalink raw reply related
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Linus Torvalds @ 2006-05-24 2:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, git
In-Reply-To: <7vhd3gxm73.fsf@assigned-by-dhcp.cox.net>
On Tue, 23 May 2006, Junio C Hamano wrote:
>
> Come to think of it, the above argument is bogus. We _would_
> want to make EOF just like any other context lines.
>
> The issue is if we can reliably tell if there is such an EOF
> context by looking at the diff. Not having the same number of
> lines that starts with ' ' in the hunk is not really a nice way
> of doing so (you could make a unified diff that does not have
> trailing context at all), and I do not offhand think of a good
> way to do so.
We can. Something like this should do it.
(The same thing could be done for "match_beginning", perhaps).
Totally untested, of course.
(It might be better to pass in "match_end" to find_offset(), so that it
could do the "look forwards" pass to see if it finds a better line offset
that is at the end - as it is, this will _fail_ the patch if it could
apply better at a non-end thing, even if it would _also_ have applied at
the end of the file).
Linus
---
diff --git a/apply.c b/apply.c
index 0ed9d13..905bf34 100644
--- a/apply.c
+++ b/apply.c
@@ -1333,6 +1333,7 @@ static int apply_line(char *output, cons
static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag)
{
+ int match_end;
char *buf = desc->buffer;
const char *patch = frag->patch;
int offset, size = frag->size;
@@ -1395,10 +1396,20 @@ #endif
newlines = new;
leading = frag->leading;
trailing = frag->trailing;
+
+ /*
+ * If we don't have any trailing data in the patch,
+ * we want to match the final ending '\0' byte in
+ * the file too..
+ */
+ match_end = !trailing;
+
lines = 0;
pos = frag->newpos;
for (;;) {
offset = find_offset(buf, desc->size, oldlines, oldsize, pos, &lines);
+ if (match_end && offset + oldsize != desc->size)
+ offset = -1;
if (offset >= 0) {
int diff = newsize - oldsize;
unsigned long size = desc->size + diff;
@@ -1428,6 +1439,10 @@ #endif
/* Am I at my context limits? */
if ((leading <= p_context) && (trailing <= p_context))
break;
+ if (match_end) {
+ match_end = 0;
+ continue;
+ }
/* Reduce the number of context lines
* Reduce both leading and trailing if they are equal
* otherwise just reduce the larger context.
^ permalink raw reply related
* Re: file name case-sensitivity issues
From: Junio C Hamano @ 2006-05-24 1:40 UTC (permalink / raw)
To: Ben Clifford; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605232239070.15915@dildano.hawaga.org.uk>
Ben Clifford <benc@hawaga.org.uk> writes:
> $ ls
> bar
> $ git ls-files -d
> FOO
> $ git ls-tree HEAD
> 100644 blob b7d6715e2df11b9c32b2341423273c6b3ad9ae8a FOO
> 100644 blob 5f8b81e197a2cb27816112fb5a6b86b7031ffde8 bar
>
> The checkout is losing the FOO file but the merged tree object has the
> merged FOO in it.
That's interesting. I wonder how... Does this sequence remove FOO
on that filesystem?
$ date >FOO
$ rm -f foo
$ ls
Also if you do the final "git pull" using resolve strategy, does
it change the result (say "git pull -s resolve . side" instead)?
^ permalink raw reply
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Junio C Hamano @ 2006-05-24 1:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <7vd5e4z2je.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> To git-apply, this patch:
>
> diff --git a/file b/file
> --- a/file
> +++ b/file
> @@ -1,2 +1,3 @@
> a
> b
> +c
>
> currently means "I want to append a line c immediately after the
> lines that have a and then b".
>...
> I do not think this is necessarily a bug. You _could_ make the
> EOF a special case (i.e. you _could_ interpret the patch that it
> also says, with "@@ -1,2", that "the result of this patch _must_
> end with this line I just added"), and if you are going to do
> that, you would also need a symmetric special case for the
> beginning of the file, but I do not think it is the right thing
> to do in general.
Come to think of it, the above argument is bogus. We _would_
want to make EOF just like any other context lines.
The issue is if we can reliably tell if there is such an EOF
context by looking at the diff. Not having the same number of
lines that starts with ' ' in the hunk is not really a nice way
of doing so (you could make a unified diff that does not have
trailing context at all), and I do not offhand think of a good
way to do so.
^ permalink raw reply
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Junio C Hamano @ 2006-05-24 1:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <7vd5e4z2je.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> To git-apply, this patch:
>
> diff --git a/file b/file
> --- a/file
> +++ b/file
> @@ -1,2 +1,3 @@
> a
> b
> +c
>
> currently means "I want to append a line c immediately after the
> lines that have a and then b".
>...
> I do not think this is necessarily a bug. You _could_ make the
> EOF a special case (i.e. you _could_ interpret the patch that it
> also says, with "@@ -1,2", that "the result of this patch _must_
> end with this line I just added"), and if you are going to do
> that, you would also need a symmetric special case for the
> beginning of the file, but I do not think it is the right thing
> to do in general.
Come to think of it, the above argument is bogus. We _would_
want to make EOF just like any other context lines.
The issue is if we can reliably tell if there is such an EOF
context by looking at the diff. Not having the same number of
lines that starts with ' ' in the hunk is not really a nice way
of doing so (you could make a unified diff that does not have
trailing context at all), and I do not offhand think of a good
way to do so.
^ permalink raw reply
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Junio C Hamano @ 2006-05-24 0:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060523214836.22628.2179.stgit@localhost.localdomain>
Hmmmmm.
To git-apply, this patch:
diff --git a/file b/file
--- a/file
+++ b/file
@@ -1,2 +1,3 @@
a
b
+c
currently means "I want to append a line c immediately after the
lines that have a and then b". Nothing else. And applying it
to
a
b
c
produces
a
b
c
c
The first c is what your patch added, and the second c is what
was originally there.
I do not think this is necessarily a bug. You _could_ make the
EOF a special case (i.e. you _could_ interpret the patch that it
also says, with "@@ -1,2", that "the result of this patch _must_
end with this line I just added"), and if you are going to do
that, you would also need a symmetric special case for the
beginning of the file, but I do not think it is the right thing
to do in general.
Realistically, you would have something like this:
diff --git a/apply.c b/apply.c
index 0ed9d13..f99c6fe 100644
--- a/apply.c
+++ b/apply.c
@@ -2297,3 +2297,8 @@ int main(int argc, char **argv)
return 0; /* end of main */
}
+
+static void this_function_is_unused(void)
+{
+ printf("hello, world\n");
+}
You added a useless function at the end of the file.
While you prepared the above patch, the upstream updated the
same file to end like this:
return 0; /* end of main */
}
static int some_new_function(void)
{
return 314;
}
Now, git-apply would produce this file if you apply the above
patch:
return 0; /* end of main */
}
static void this_function_is_unused(void)
{
printf("hello, world\n");
}
static int some_new_function(void)
{
return 314;
}
I think this current behaviour is more desirable than special
casing the end of file and refusing to apply.
In this particular case, expecting failure like your new test
does is somewhat understandable, but if you change the test case
to start with this file, you would realize that your expectation
is not the only valid understanding of what is really happening:
echo 'a' >file
echo 'b' >>file
echo 'd' >>file
Applying test-patch to this would result in
a
b
c
d
which I think is more useful behaviour.
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Junio C Hamano @ 2006-05-23 23:49 UTC (permalink / raw)
To: Björn Engelmann; +Cc: git
In-Reply-To: <44737353.20904@gmx.de>
Björn Engelmann <BjEngelmann@gmx.de> writes:
> I hope this time I got it right.
Thanks. Pushed out as a part of "next". Will hopefully be part
of "master" by the end of the week if not earlier.
^ permalink raw reply
* Re: Make more commands builtin
From: Junio C Hamano @ 2006-05-23 23:48 UTC (permalink / raw)
To: s022018; +Cc: git
In-Reply-To: <15865.7899396077$1148386583@news.gmane.org>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> Junio, I've formatted this batch of patches with -M, so
> they are easier to read.
Thanks. Pushed out as a part of "next". Will hopefully be part
of "master" by the end of the week if not earlier.
^ permalink raw reply
* Re: [PATCH 0/6] Detect non email patches in git-mailinfo
From: Junio C Hamano @ 2006-05-23 23:44 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m18xosjznu.fsf@ebiederm.dsl.xmission.com>
Thanks. Merged to "next", this probably would graduate to
"master" by the end of the week if not earlier.
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Junio C Hamano @ 2006-05-23 23:41 UTC (permalink / raw)
To: Jeff King; +Cc: Morten Welinder, Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <20060523205944.GA16164@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, May 23, 2006 at 01:47:01PM -0400, Morten Welinder wrote:
>
>> Why run "env" and not just muck with %ENV?
>> >+ my $pid = open2(my $commit_read, my $commit_write,
>> >+ 'env',
>> >+ "GIT_AUTHOR_NAME=$author_name",
>> >+ "GIT_AUTHOR_EMAIL=$author_email",
>> >+ "GIT_AUTHOR_DATE=$commit_date",
>> >+ "GIT_COMMITTER_NAME=$author_name",
>> >+ "GIT_COMMITTER_EMAIL=$author_email",
>> >+ "GIT_COMMITTER_DATE=$commit_date",
>> >+ 'git-commit-tree', $tree, @commit_args);
>
> Oops, that's an obvious fork optimization that I should have caught.
Are you two talking about running git-commit-tree via env is two
fork-execs instead of just one? Does that have a measurable
difference?
Not that I have anything against the updated code, but I do not
particularly thing it is such a big issue.
> PS What is the preferred format for throwing patches into replies like
> this? Putting the patch at the end (as here) or throwing the reply
> comments in the ignored section near the diffstat?
You could do it either way. Although I personally find the
former easier to read (meshes well with "do not top post"
mantra), it appears many other people finds the cover letter
material should come after the first '---' separator.
If you append the patch to your message, btw, you would need to
realize that the receiving end needs to edit your message to
remove the top part before running "git am" to apply.
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Junio C Hamano @ 2006-05-23 23:15 UTC (permalink / raw)
To: Björn Engelmann; +Cc: git
In-Reply-To: <44737353.20904@gmx.de>
Björn Engelmann <BjEngelmann@gmx.de> writes:
> I am currently wondering where to store the reference to such a
> sub-repository. It certainly is a head, but I would like to avoid anyone
> commiting code into this "branch". Maybe I will create a new directory
> .git/refs/annotations.
I would recommend against that. Why shouldn't it be an ordinary
branch that is different from the default "master"?
If you are in a shared repository settings, then update hook is
there for you to prevent people who do not have any business
touching that branch head from mucking with it.
> I am not sure how git would perform in such an environment. Do you think
> the "git-push"-implementation is sufficiently "thread-save" for this ?
Yes.
And I do not necessarily think your workflow would want to have
such "an empty file works as a lock" convention.
Just do things locklessly. If two people in the group happened
to do duplicated work, the first push would succeed and the
second person would be prevented from pushing (and suggested to
merge in the work first). When the second person pulls, he
would realize the scan result by the first person is already
there. If that is considered to be too much wasted work, then
it means your distributed workflow did not have sufficient
communication among people. Being able to work distributed does
not mean you need no coordination, and a distributed SCM is not
a substitute for comminication among paticipants.
> 1.) Do you intend to add some more advanced metadata-functionality to
> git in the future or should I send a patch with my implementation once
> it is finished ? Will be just some scripts using similar commands to
> what Linus sent me (thanks for that, btw)
Neither, until/unless we have a clear design.
I think the annotation branch (or a separate repository) is a
very natural consequence of what the tool already give you, and
the tools work just fine as they are. There is nothing
innovative in what I suggested above nor Linus outlined in the
other message.
If you are talking about an application that builds on top of
git to do issue management (or QA or whatever), that uses
metadata linked to the commits on the main development branch,
that would be a wonderful system, but that does not necessarily
have to come with git (it's just an application on top of git,
and the workflow of your organization may or may not match other
people's workflow).
> 2.) Searching for a way to add objects to the database I spent quite a
> while to find the right command. Don't you think it would be much more
> intuitive having an
>
> git-create-object [-t <type>] [-n] [-f] [-z] [--stdin] <file> [-r
> <ref-name>]
>
> command for creating any type of object (-t blob as default).
No, I do not think we would want to make it too easy and relaxed
to create arbitrary object-looking thing. Each type have
defined format and semantics, and creation of an object of each
type should be validated. I do not want to encourage bypassing
it by introducing such a backdoor. The backdoor is easy to
write, but I suspect it would actively harm us, instead of
helping us, by encouraging "let's build a custom type of object,
we do not care if other people would not understand it"
mentality.
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Junio C Hamano @ 2006-05-23 22:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060523210615.GB5869@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> Very simple to reproduce on FAT and NTFS, and under Windows, as usual,
> when a problem is especially annoying. I seem to have no chance to
> get my hands on this myself, so I at least let everyone know about the
> problem.
Isn't it like complaining that the following sequence loses your
precious file on a case-challenged filesystem?
$ echo precious contents >foo
$ rm -f FOO
Is it a problem for the user? Certainly yes. You lost your
precious file.
Is it a bug in the operating system and/or the filesystem?
Probably not; it is doing what it is asked to do -- its
definition of what string matches what file on the filesystem is
dubious, but that is how it sees the world and you accept that
view while you are on such a system. Is it a bug in "rm"?
Probably not; it is doing what it is asked to do within the
context that you gave it.
I'd call that a PEBCAK.
If you _know_ you are working on a case challenged filesystem, I
think the best thing you can do is not to work on a project that
has files in different cases on such a filesystem.
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Ben Clifford @ 2006-05-23 22:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <20060523210615.GB5869@steel.home>
On OS X using whatever filesystem it comes with by default, I get the
following, which doesn't seem right (but in a different way).
$ mkdir case-sensitivity-test
$ cd case-sensitivity-test
$ git init-db
defaulting to local storage area
$ echo foo > foo
$ echo bar > bar
$ git add foo bar
$ git commit -m initial\ commit
Committing initial tree 89ff1a2aefcbff0f09197f0fd8beeb19a7b6e51c
$ git checkout -b side
$ echo bar-side >> bar
$ git commit -m side\ commit -o bar
$ git checkout master
$ rm foo
$ git update-index --remove foo
$ echo FOO > FOO
$ git add FOO
$ git commit -m case\ change
$ ls
FOO bar
$ git pull . side
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with e1f1e78035b099fad2bbfb82af7ec31864d8e4c1
Merging:
5d70969775bf595dd5144a2bacc25d32cc288352 case change
e1f1e78035b099fad2bbfb82af7ec31864d8e4c1 side commit
found 1 common ancestor(s):
e35c42fad4f08c2ccf61d93409a0208e92028a51 initial commit
Merge 98bf1cae75776c141ad3b61dc2cb938c71c303ef, made by recursive.
bar | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
$
$ ls
bar
$ git ls-files -d
FOO
$ git ls-tree HEAD
100644 blob b7d6715e2df11b9c32b2341423273c6b3ad9ae8a FOO
100644 blob 5f8b81e197a2cb27816112fb5a6b86b7031ffde8 bar
The checkout is losing the FOO file but the merged tree object has the
merged FOO in it.
--
^ permalink raw reply
* Re: Current Issues #3
From: Jakub Narebski @ 2006-05-23 21:58 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605220216310.3697@g5.osdl.org>
Linus Torvalds wrote:
[...]
> But with the above, you can fairly naturally do:
>
> - "git pull"
>
> No arguments. fetch the remote described by the current branch,
> and merge into current branch (we might decide to fetch all the
> remotes associated with that repo, just because once we do this,
> we might as well, but that's not that important to the end
> result).
>
> - "git pull <repo>"
(i.e. re-clone)
> fetch all remotes that use <repo>. IFF the current branch is
> matched to one of those remotes, merge the changes into the
> current branch. But if you happened to be on another unrelated
> branch, nothing happens aside from the fetch.
>
> - "git pull <remote>"
>
> fetch just the named remote. IFF that remote is also the remote
> for the current branch, do merge it into current. Again, we
> _might_ decide to just do the whole repo.
>
> - "git pull <repo> <branchname>"
>
> fetch the named branch from the named repository and merge it into
> current (no ifs, buts or maybes - now we've basically overridden
> the default relationships, so now the <repo> is just a pure
> shorthand for the location of the repository)
Fetch into curret branch, or specified by branch configuration, then current
if unspecified?
> - "git pull <repo> <src>:<dst>"
>
> same as now. fetch <repo> <src> into <dst>, and merge it into the
> current branch (again, we've overridden any default relationships).
>
> but maybe this is overdesigned. Comments?
It all means that within <repo> annd <remote> names should be unique
(to know if we use "git pull <repo>" or "git pull <remote>").
Perhaps it would be nice to have
- "git pull <repo> *:<dst>"
- "git pull <repo> <src>:*"
- "git pull <repo> *:*"
and
- "git pull <repo> <src>:<dst>:<to-merge>"
as easier to remember options. Of course what is the remote branch related
to <dst>, and what is local branch related to <src> would be in
branch/remotes/repos configuration.
BTW. what about --use-separate-remotes option support?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] Add a test-case for git-apply trying to add an ending line
From: Catalin Marinas @ 2006-05-23 21:48 UTC (permalink / raw)
To: git
From: Catalin Marinas <catalin.marinas@gmail.com>
git-apply adding an ending line doesn't seem to fail if the ending line is
already present in the patched file.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
t/t4113-apply-ending.sh | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/t/t4113-apply-ending.sh b/t/t4113-apply-ending.sh
new file mode 100755
index 0000000..d021ae8
--- /dev/null
+++ b/t/t4113-apply-ending.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Catalin Marinas
+#
+
+test_description='git-apply trying to add an ending line.
+
+'
+. ./test-lib.sh
+
+# setup
+
+cat >test-patch <<\EOF
+diff --git a/file b/file
+--- a/file
++++ b/file
+@@ -1,2 +1,3 @@
+ a
+ b
++c
+EOF
+
+echo 'a' >file
+echo 'b' >>file
+echo 'c' >>file
+
+test_expect_success setup \
+ 'git-update-index --add file'
+
+# test
+
+test_expect_failure apply \
+ 'git-apply --index test-patch'
+
+test_done
^ permalink raw reply related
* Re: file name case-sensitivity issues
From: Linus Torvalds @ 2006-05-23 21:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0605231412350.5623@g5.osdl.org>
On Tue, 23 May 2006, Linus Torvalds wrote:
>
> The closest I can imagine is to add a config option like "core.lowercase",
> and that would make us always add files to the index in lower case.
Side note: doing it by just changing the name compare functions to ignore
case is _not_ a good things to do, because that would generate tree
objects that simply don't work (or fsck) correctly on any other machine.
The index and tree objects are all sorted by pathname, and thus the
sorting order has to be something that everybody agrees on, and any locale
dependencies are not appropriate.
It might be worth asking the monotone guys what they do - they've worked
on Windows for a long time.
Linus
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Linus Torvalds @ 2006-05-23 21:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20060523210615.GB5869@steel.home>
On Tue, 23 May 2006, Alex Riesen wrote:
>
> Very simple to reproduce on FAT and NTFS, and under Windows, as usual,
> when a problem is especially annoying. I seem to have no chance to
> get my hands on this myself, so I at least let everyone know about the
> problem.
I don't think we can fix it.
At least not in the short term.
The closest I can imagine is to add a config option like "core.lowercase",
and that would make us always add files to the index in lower case. That,
together with making sure that "setup_pathspec()" &co always also
lower-case their arguments might get things limping along with minimal
trouble.
But it won't ever do things _well_. Anything non-ascii would be just a
nightmare.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Martin Langhoff @ 2006-05-23 21:13 UTC (permalink / raw)
To: Martin Langhoff, Linus Torvalds, Junio C Hamano, Matthias Urlichs,
git
In-Reply-To: <20060523211016.GB16164@coredump.intra.peff.net>
On 5/24/06, Jeff King <peff@peff.net> wrote:
> On Wed, May 24, 2006 at 08:29:07AM +1200, Martin Langhoff wrote:
>
> > Strange! Cannot repro here with v5.8.8 (debian/etch 5.8.8-4) but
> > initialising it doesn't hurt, so let's do it:
>
> I can reproduce with debian perl 5.8.8-4. The bug is only triggered by
> 0-length files, so presumably your test repo doesn't have any.
Given that we are all working off the gentoo repo here, it means that
my machine is slower than Linus' unreleased Intel box. And that I am
too impatient...
In any case, the fix is correct as Junio points out.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-23 21:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <46a038f90605231329w35d10cfdg1ac413ebf8d32e11@mail.gmail.com>
On Wed, May 24, 2006 at 08:29:07AM +1200, Martin Langhoff wrote:
> Strange! Cannot repro here with v5.8.8 (debian/etch 5.8.8-4) but
> initialising it doesn't hurt, so let's do it:
I can reproduce with debian perl 5.8.8-4. The bug is only triggered by
0-length files, so presumably your test repo doesn't have any.
-Peff
^ 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