* 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: [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] 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: 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: 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
* [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: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
* 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
* [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
* [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
* 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
* 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] Add a test-case for git-apply trying to add an ending line
From: Junio C Hamano @ 2006-05-24 4:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.64.0605231905470.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 23 May 2006, Junio C Hamano wrote:
>
>> 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).
But this is exactly what I said I had trouble with in the above.
In the extreme case, wouldn't this make git apply to refuse to
apply a self generated patch with 0-line context? IOW,
$ git checkout -- foo ;# reset to indexed version
$ edit foo
$ git diff -U0 >P.diff
$ git checkout -- foo ;# reset to indexed version
$ git apply <P.diff
would fail, even though it _should_ cleanly apply.
I'd admit that trying to apply a patch without context like the
above example _is_ insane, and I realize that I am making this
problem unsolvable by refusing the heuristics to consider that
the patch is anchored at the end when we do not see any trailing
context. But somehow it feels wrong...
^ permalink raw reply
* A few stgit bugfixes
From: Karl Hasselström @ 2006-05-24 6:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Fixes for a few bugs recently introduced in stgit by yours truly.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH 1/3] Fix infinite recursion on absolute paths
From: Karl Hasselström @ 2006-05-24 6:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060524060537.GA1173@diana.vm.bytemark.co.uk>
Calling create_dirs with an absolute path caused infinite recursion,
since os.path.dirname('/') == '/'. Fix this by exiting early if the
given path already is a directory.
---
stgit/utils.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/utils.py b/stgit/utils.py
index 68b8f58..ed6e43c 100644
--- a/stgit/utils.py
+++ b/stgit/utils.py
@@ -130,7 +130,7 @@ def remove_file_and_dirs(basedir, file):
def create_dirs(directory):
"""Create the given directory, if the path doesn't already exist."""
- if directory:
+ if directory and not os.path.isdir(directory):
create_dirs(os.path.dirname(directory))
try:
os.mkdir(directory)
^ permalink raw reply related
* [PATCH 2/3] Fix indexing error during "diff -r/"
From: Karl Hasselström @ 2006-05-24 6:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060524060537.GA1173@diana.vm.bytemark.co.uk>
The string indexing when decoding the -r argument for diff made an
implicit assumption that the revision string was at least two
characters long, which broke on the simple invocation "diff -r/".
---
stgit/commands/diff.py | 8 ++++----
stgit/utils.py | 6 ++++++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/stgit/commands/diff.py b/stgit/commands/diff.py
index d765784..caa3c5b 100644
--- a/stgit/commands/diff.py
+++ b/stgit/commands/diff.py
@@ -56,11 +56,11 @@ def func(parser, options, args):
rev_list_len = len(rev_list)
if rev_list_len == 1:
rev = rev_list[0]
- if rev[-1] == '/':
+ if rev.endswith('/'):
# the whole patch
- rev = rev[:-1]
- if rev[-1] == '/':
- rev = rev[:-1]
+ rev = strip_suffix('/', rev)
+ if rev.endswith('/'):
+ rev = strip_suffix('/', rev)
rev1 = rev + '//bottom'
rev2 = rev + '//top'
else:
diff --git a/stgit/utils.py b/stgit/utils.py
index ed6e43c..67431ec 100644
--- a/stgit/utils.py
+++ b/stgit/utils.py
@@ -109,6 +109,12 @@ def strip_prefix(prefix, string):
assert string.startswith(prefix)
return string[len(prefix):]
+def strip_suffix(suffix, string):
+ """Return string, without the suffix. Blow up if string doesn't
+ end with suffix."""
+ assert string.endswith(suffix)
+ return string[:-len(suffix)]
+
def remove_dirs(basedir, dirs):
"""Starting at join(basedir, dirs), remove the directory if empty,
and try the same with its parent, until we find a nonempty
^ permalink raw reply related
* [PATCH 3/3] Explicitly specify utf-8 coding in file
From: Karl Hasselström @ 2006-05-24 6:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060524060537.GA1173@diana.vm.bytemark.co.uk>
uncommit.py has a non-ascii character in it (in my name in the
copyright line). Without this coding: comment, I get an error like the
following when I run stgit:
/home/kha/git/stgit/stgit/main.py:61: DeprecationWarning: Non-ASCII
character '\xc3' in file
/home/kha/git/stgit/stgit/commands/uncommit.py on line 3, but no
encoding declared; see http://www.python.org/peps/pep-0263.html for
details
---
stgit/commands/uncommit.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index e03d207..52ce5a8 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -1,3 +1,5 @@
+# -*- coding: utf-8 -*-
+
__copyright__ = """
Copyright (C) 2006, Karl Hasselström <kha@treskal.com>
^ permalink raw reply related
* Incremental cvsimports
From: Geoff Russell @ 2006-05-24 7:46 UTC (permalink / raw)
To: git
Dear Git,
I have a 3Gb repository (10 years of history) which I want to import into git.
I have tested little pieces of that and a 23Mb directory expands to 120Mb prior
to packing/pruning. Therefore I don't have a big enough disk to import the
whole repository at once. So I figure I could do it in pieces with a pack after
each piece.
So I tried something like:
1. $ git cvsimport -o austrics -v -d /cvsroot -C /GitRepo /cvsroot/A
followed by
2. $ git cvsimport -o austrics -v -d /cvsroot -C /GitRepo /cvsroot/B
After 1, /GitRepo/.git is set up but /GitRepo has the members of A,
not A itself.
After 2, /GitRepo also has members of B. This isn't quite what I wanted!
Is there a way to do this?
Cheers,
Geoff Russell
^ permalink raw reply
* [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-24 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
While working on git-quiltimport I decided to see if
I could transform Andrews patches where he imports git tress into
git-pull commands, which should result in better history and better
attribution.
To be accurate of his source Andrew records the sha1 of the commit
and the git tree he pulled from. Which looks like:
GIT b307e8548921c686d2eb948ca418ab2941876daa \
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
So I figured I would transform the above line into the obvious
git-pull command:
git-pull \
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
b307e8548921c686d2eb948ca418ab2941876daa
To my surprise that didn't work. There were a couple of little places
in the scripts where git-fetch and git-fetch-pack never expected to be
given a sha1 but that was easy to fix up, and had no real repercussions.
More problematic was the little bit in git-upload pack that only
allows you to a sha1 if it was on the list of sha1 generated from
looking at the heads. I'm not at all certain of the sense of
that check as you can get everything by just cloning the repository.
Can we fix the check in upload-pack.c something like my
patch below does? Are there any security implications for
doing that?
Could we just make the final check before dying if (!o) ?
/* We have sent all our refs already, and the other end
* should have chosen out of them; otherwise they are
* asking for nonsense.
*
* Hmph. We may later want to allow "want" line that
* asks for something like "master~10" (symbolic)...
* would it make sense? I don't know.
*/
diff --git a/upload-pack.c b/upload-pack.c
index 47560c9..0f2e544 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -207,7 +207,9 @@ static int receive_needs(void)
* would it make sense? I don't know.
*/
o = lookup_object(sha1_buf);
- if (!o || !(o->flags & OUR_REF))
+ if (!o)
+ o = parse_object(sha1_buf);
+ if (!o || ((o->type != commit_type) && (o->type != tag_type)))
die("git-upload-pack: not our ref %s", line+5);
if (!(o->flags & WANTED)) {
o->flags |= WANTED;
^ permalink raw reply related
* [PATCH] gitk: Replace "git-" commands with "git "
From: Timo Hirvonen @ 2006-05-24 7:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
git-* commands work only if gitexecdir is in PATH.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
NOTE: This is for the gitk repository.
cad90165494784f29aec40bca2c1e2bbc39e7a76
gitk | 52 ++++++++++++++++++++++++++--------------------------
1 files changed, 26 insertions(+), 26 deletions(-)
cad90165494784f29aec40bca2c1e2bbc39e7a76
diff --git a/gitk b/gitk
index bd8d4f1..7427856 100755
--- a/gitk
+++ b/gitk
@@ -34,10 +34,10 @@ proc start_rev_list {view} {
set order "--date-order"
}
if {[catch {
- set fd [open [concat | git-rev-list --header $order \
+ set fd [open [concat | git rev-list --header $order \
--parents --boundary --default HEAD $args] r]
} err]} {
- puts stderr "Error executing git-rev-list: $err"
+ puts stderr "Error executing git rev-list: $err"
exit 1
}
set commfd($view) $fd
@@ -94,10 +94,10 @@ proc getcommitlines {fd view} {
}
if {[string range $err 0 4] == "usage"} {
set err "Gitk: error reading commits$fv:\
- bad arguments to git-rev-list."
+ bad arguments to git rev-list."
if {$viewname($view) eq "Command line"} {
append err \
- " (Note: arguments to gitk are passed to git-rev-list\
+ " (Note: arguments to gitk are passed to git rev-list\
to allow selection of commits to be displayed.)"
}
} else {
@@ -148,7 +148,7 @@ proc getcommitlines {fd view} {
if {[string length $shortcmit] > 80} {
set shortcmit "[string range $shortcmit 0 80]..."
}
- error_popup "Can't parse git-rev-list output: {$shortcmit}"
+ error_popup "Can't parse git rev-list output: {$shortcmit}"
exit 1
}
set id [lindex $ids 0]
@@ -217,7 +217,7 @@ proc doupdate {} {
}
proc readcommit {id} {
- if {[catch {set contents [exec git-cat-file commit $id]}]} return
+ if {[catch {set contents [exec git cat-file commit $id]}]} return
parsecommit $id $contents 0
}
@@ -276,8 +276,8 @@ proc parsecommit {id contents listed} {
set headline $comment
}
if {!$listed} {
- # git-rev-list indents the comment by 4 spaces;
- # if we got this via git-cat-file, add the indentation
+ # git rev-list indents the comment by 4 spaces;
+ # if we got this via git cat-file, add the indentation
set newcomment {}
foreach line [split $comment "\n"] {
append newcomment " "
@@ -337,14 +337,14 @@ proc readrefs {} {
set type {}
set tag {}
catch {
- set commit [exec git-rev-parse "$id^0"]
+ set commit [exec git rev-parse "$id^0"]
if {"$commit" != "$id"} {
set tagids($name) $commit
lappend idtags($commit) $name
}
}
catch {
- set tagcontents($name) [exec git-cat-file tag "$id"]
+ set tagcontents($name) [exec git cat-file tag "$id"]
}
} elseif { $type == "heads" } {
set headids($name) $id
@@ -1287,7 +1287,7 @@ proc vieweditor {top n title} {
checkbutton $top.perm -text "Remember this view" -variable newviewperm($n)
grid $top.perm - -pady 5 -sticky w
message $top.al -aspect 1000 -font $uifont \
- -text "Commits to include (arguments to git-rev-list):"
+ -text "Commits to include (arguments to git rev-list):"
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
-background white
@@ -2941,7 +2941,7 @@ proc findpatches {} {
}
if {[catch {
- set f [open [list | git-diff-tree --stdin -s -r -S$findstring \
+ set f [open [list | git diff-tree --stdin -s -r -S$findstring \
<< $inputids] r]
} err]} {
error_popup "Error starting search process: $err"
@@ -2973,7 +2973,7 @@ proc readfindproc {} {
return
}
if {![regexp {^[0-9a-f]{40}} $line id]} {
- error_popup "Can't parse git-diff-tree output: $line"
+ error_popup "Can't parse git diff-tree output: $line"
stopfindproc
return
}
@@ -3038,10 +3038,10 @@ proc findfiles {} {
if {$l == $findstartline} break
}
- # start off a git-diff-tree process if needed
+ # start off a git diff-tree process if needed
if {$diffsneeded ne {}} {
if {[catch {
- set df [open [list | git-diff-tree -r --stdin << $diffsneeded] r]
+ set df [open [list | git diff-tree -r --stdin << $diffsneeded] r]
} err ]} {
error_popup "Error starting search process: $err"
return
@@ -3071,7 +3071,7 @@ proc readfilediffs {df} {
if {[catch {close $df} err]} {
stopfindproc
bell
- error_popup "Error in git-diff-tree: $err"
+ error_popup "Error in git diff-tree: $err"
} elseif {[info exists findid]} {
set id $findid
stopfindproc
@@ -3098,7 +3098,7 @@ proc donefilediff {} {
if {[info exists fdiffid]} {
while {[lindex $fdiffsneeded $fdiffpos] ne $fdiffid
&& $fdiffpos < [llength $fdiffsneeded]} {
- # git-diff-tree doesn't output anything for a commit
+ # git diff-tree doesn't output anything for a commit
# which doesn't change anything
set nullid [lindex $fdiffsneeded $fdiffpos]
set treediffs($nullid) {}
@@ -3526,7 +3526,7 @@ proc gettree {id} {
catch {unset diffmergeid}
if {![info exists treefilelist($id)]} {
if {![info exists treepending]} {
- if {[catch {set gtf [open [concat | git-ls-tree -r $id] r]}]} {
+ if {[catch {set gtf [open [concat | git ls-tree -r $id] r]}]} {
return
}
set treepending $id
@@ -3574,7 +3574,7 @@ proc showfile {f} {
return
}
set blob [lindex $treeidlist($diffids) $i]
- if {[catch {set bf [open [concat | git-cat-file blob $blob] r]} err]} {
+ if {[catch {set bf [open [concat | git cat-file blob $blob] r]} err]} {
puts "oops, error reading blob $blob: $err"
return
}
@@ -3616,7 +3616,7 @@ proc mergediff {id l} {
set diffids $id
# this doesn't seem to actually affect anything...
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [concat | git-diff-tree --no-commit-id --cc $id]
+ set cmd [concat | git diff-tree --no-commit-id --cc $id]
if {[catch {set mdf [open $cmd r]} err]} {
error_popup "Error getting merge diffs: $err"
return
@@ -3728,7 +3728,7 @@ proc gettreediffs {ids} {
set treepending $ids
set treediff {}
if {[catch \
- {set gdtf [open [concat | git-diff-tree --no-commit-id -r $ids] r]} \
+ {set gdtf [open [concat | git diff-tree --no-commit-id -r $ids] r]} \
]} return
fconfigure $gdtf -blocking 0
fileevent $gdtf readable [list gettreediffline $gdtf $ids]
@@ -3764,7 +3764,7 @@ proc getblobdiffs {ids} {
global nextupdate diffinhdr treediffs
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [concat | git-diff-tree --no-commit-id -r -p -C $ids]
+ set cmd [concat | git diff-tree --no-commit-id -r -p -C $ids]
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
@@ -4301,7 +4301,7 @@ proc mkpatchgo {} {
set oldid [$patchtop.fromsha1 get]
set newid [$patchtop.tosha1 get]
set fname [$patchtop.fname get]
- if {[catch {exec git-diff-tree -p $oldid $newid >$fname &} err]} {
+ if {[catch {exec git diff-tree -p $oldid $newid >$fname &} err]} {
error_popup "Error creating patch: $err"
}
catch {destroy $patchtop}
@@ -4868,11 +4868,11 @@ proc tcl_encoding {enc} {
# defaults...
set datemode 0
set diffopts "-U 5 -p"
-set wrcomcmd "git-diff-tree --stdin -p --pretty"
+set wrcomcmd "git diff-tree --stdin -p --pretty"
set gitencoding {}
catch {
- set gitencoding [exec git-repo-config --get i18n.commitencoding]
+ set gitencoding [exec git repo-config --get i18n.commitencoding]
}
if {$gitencoding == ""} {
set gitencoding "utf-8"
@@ -4928,7 +4928,7 @@ if {$i >= 0} {
set revtreeargs [lrange $revtreeargs 0 [expr {$i - 1}]]
} elseif {$revtreeargs ne {}} {
if {[catch {
- set f [eval exec git-rev-parse --no-revs --no-flags $revtreeargs]
+ set f [eval exec git rev-parse --no-revs --no-flags $revtreeargs]
set cmdline_files [split $f "\n"]
set n [llength $cmdline_files]
set revtreeargs [lrange $revtreeargs 0 end-$n]
--
1.3.3.g40505-dirty
^ permalink raw reply related
* Re: Incremental cvsimports
From: Martin Langhoff @ 2006-05-24 8:21 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <93c3eada0605240046t10e00119n4cfc39ec33fe1d92@mail.gmail.com>
On 5/24/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> Dear Git,
Dear Geoff,
if you look at the list archive for the last couple of days, you'll
see there's been quite a bit of activity in tuning cvsimport so that
it scales better with large imports like yours. We have been playing
with a gentoo cvs repo with 300K commits / 1.6GB uncompressed.
Don't split up the tree... that'll lead to something rather ackward.
Instead, fetch and build git from Junio's 'master' branch which seems
to have collected most (all?) of the patches posted, including one
from Linus that will repack the repo every 1K commits -- keeping the
import size down.
You _will_ need a lot of memory though, as cvsps grows large (working
on a workaround now) and cvsimport grows a bit over time (where is
that last leak?!). And a fast machine -- specially fast IO. I've just
switched from an old test machine to an AMD64 with fast disks, and
it's importing around 10K commits per hour.
You will probably want to run cvsps by hand, and later use the -P flag.
cheers,
martin
^ permalink raw reply
* Re: Incremental cvsimports
From: Martin Langhoff @ 2006-05-24 8:25 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <46a038f90605240121o117fadb6vf3ce910a3ad3e90@mail.gmail.com>
On 5/24/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> You _will_ need a lot of memory though, as cvsps grows large (working
> on a workaround now)
While the workaround is worked around, you can create the cvsps file
using something like
CVSROOT=~/tmp/gentoorepo/ cvsps --norc -x -u -A gentoo-x86 >
gentoo.cvsps 2> gentoo.err
and then pass a -P gentoo.cvsps to cvsimport. s/gentoo/myproject/ ;-)
martin
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-24 9:07 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m164jvj1x3.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Can we fix the check in upload-pack.c something like my
> patch below does? Are there any security implications for
> doing that?
> Could we just make the final check before dying if (!o) ?
The primary implication is about correctness, so I am reluctant
to break it without a careful alternative check in place.
The issue is that having a single object in the repository does
not guarantee that you have everything reachable from it, and we
need that guarantee. Reachability from the refs is what
guarantees that.
We are careful to update the ref at the very end of the transfer
(fetch/clone or push); so if an object is reachable from a ref,
then all the objects reachable from that object are available in
the repository.
Imagine http commit walker started fetching tip of upstream into
your repository and you interrupted the transfer. Objects near
the tip of the upstream history are available after such an
interrupted transfer. But a bit older history (but still later
than what we had before we started the transfer) are not.
We do not update the ref with the downloaded tip object, so that
we would not break the guarantee. This guarantee is needed for
feeding clients from the repository later. If you tell your
clients, after such an interrupted transfer, that you are
willing to serve the objects near the (new) tip, the clients may
rightfully request objects that are reachable from these
objects, some of them you do _not_ have!
So this "on demand SHA1" stuff needs to be solved by checking if
the given object is reachable from our refs in upload-pack,
instead of the current check to see if the given object is
pointed by our refs. When upload-pack can prove that the object
is reachable from one of the refs, it is OK to use it; otherwise
you should not.
Now, proving that a given SHA1 is the name of an object that
exists in the repository is cheap (has_sha1_file()), but proving
that the object is reachable from some of our refs can become
quite expensive. That gives this issue a security implication
as well -- you can easily DoS the git-daemon that way, for
example.
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-24 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <7vpsi41f82.fsf@assigned-by-dhcp.cox.net>
On Tue, May 23, 2006 at 04:41:33PM -0700, Junio C Hamano wrote:
> 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?
Yes, that's what I was talking about. No, probably not a huge
difference. I did some performance measurements of all of the recent
cvsimport changes on a small-ish personal repo (I don't have the gentoo
repo). The results were not significant (<= 1% improvement for each
change). I would expect some of the changes (index-info, fetchfile) to
have an impact on a repo with different characteristics (like the gentoo
one).
-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