* Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
From: Junio C Hamano @ 2006-12-28 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061228073517.GG17867@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Users may also now use `git-pull . foo~3` to merge the early part
> of branch foo. This was not previously possible as git-fetch does
> not know how to fetch foo~3 from a repository.
I personally think this is not an improvement, but rather a new
source of confusion. If the user wants a local merge, there is
'git-merge'. And the distinction between the commands makes it
clear that local merge can merge any commits exactly because
they are available locally, while remote fetch+merge needs to
choose from what the remote side offers so not arbitrary commits
like foo@{3.days.ago} cannot be pulled.
Also I thought there was a configuration variable that talks
about "remote = ." (didn't I merge that patch -- I do not
remember offhand) and I wonder how that interacts with this
change.
How much performance gain are we talking about here?
^ permalink raw reply
* Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.
From: Junio C Hamano @ 2006-12-28 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061228073534.GK17867@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> For a really trivial merge which can be handled entirely by
> `read-tree -m -u`, skipping the read-tree and just going directly
> into merge-recursive saves on average 50 ms on my PowerPC G4 system.
> May sound odd, but it does appear to be true.
This sounds awfully attractive yet disruptive. Should be cooked
in 'next' for at least two weeks, maybe even longer to verify
that performance figure holds for everybody.
Also I think you need to make sure running merge-recursive
upfront offers the same safety as the code you are removing then
running it, as I vaguely recall its checking for local changes
were slightly looser.
^ permalink raw reply
* Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
From: Shawn Pearce @ 2006-12-28 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xgsxx1r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Users may also now use `git-pull . foo~3` to merge the early part
> > of branch foo. This was not previously possible as git-fetch does
> > not know how to fetch foo~3 from a repository.
>
> I personally think this is not an improvement, but rather a new
> source of confusion. If the user wants a local merge, there is
> 'git-merge'. And the distinction between the commands makes it
> clear that local merge can merge any commits exactly because
> they are available locally, while remote fetch+merge needs to
> choose from what the remote side offers so not arbitrary commits
> like foo@{3.days.ago} cannot be pulled.
True. But you know you are doing a local merge with `git pull .`.
So why should you be restricted from using the capabilities of a
local merge just because the frontend you prefer to use is limited
when its doing remote merges?
I didn't really do this change for this feature, I did for the
performance (see below).
> Also I thought there was a configuration variable that talks
> about "remote = ." (didn't I merge that patch -- I do not
> remember offhand) and I wonder how that interacts with this
> change.
I must have missed that discussion on the list. Not sure how as
I read everything. Oh, its that grey stuff upstairs not recalling
history as well as Git does... ;-)
> How much performance gain are we talking about here?
It halves my 'git pull . foo' times on my Mac OS X PowerPC 64 system:
Without: ~900 ms
With: ~440 ms
--
Shawn.
^ permalink raw reply
* Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.
From: Shawn Pearce @ 2006-12-28 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejqkxx1s.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > For a really trivial merge which can be handled entirely by
> > `read-tree -m -u`, skipping the read-tree and just going directly
> > into merge-recursive saves on average 50 ms on my PowerPC G4 system.
> > May sound odd, but it does appear to be true.
>
> This sounds awfully attractive yet disruptive. Should be cooked
> in 'next' for at least two weeks, maybe even longer to verify
> that performance figure holds for everybody.
I agree. I have been thinking about doing this for a while but
just never sat down and did it until night. To get it in 1.5.0 I
probably should have done this back in early Decmember. Whoops,
bad timing on my part. ;-)
> Also I think you need to make sure running merge-recursive
> upfront offers the same safety as the code you are removing then
> running it, as I vaguely recall its checking for local changes
> were slightly looser.
>From what I can tell, merge-recursive and read-tree -m are running
exactly the same code. So aside from the fact that I bypassed the
update-index --refresh by accident, I don't think they will have
different outcomes.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Junio C Hamano @ 2006-12-28 8:25 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Johannes Schindelin
In-Reply-To: <20061228073441.GB17304@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I'd like to see these appear in v1.5.0, but we're getting close to
> the release so I can understand if they get delayed.
I think shooting for -rc1 by mid January and stabilizing by
early to mid February for the real release, would be a realistic
timeline.
Actually I am getting more greedy, and would not mind to have
clean ups and a few more features in the new release, even the
ones that we have talked about but have not implemented.
I am very tempted to have sliding window mmap() if it helps
people on cygwin, for example. Also, I've been running with
"next" for my daily pushes and pulls without trouble, and I am
very tempted to push out the shallow-clone topic. Not that I
think its shallow-clone part is useful -- I do not use the
feature myself so I cannot judge -- but at least when shallow is
enabled on neither ends, it does not seem to break anything.
Although I do find the detached HEAD attractive and would want
to have it eventually, I suspect that even if it materializes
soon enough, it would at least need a couple of weeks of testing
in 'next', so making -rc1 wait for it might push back the
release a bit too much.
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Shawn Pearce @ 2006-12-28 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vmz58whnx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Actually I am getting more greedy, and would not mind to have
> clean ups and a few more features in the new release, even the
> ones that we have talked about but have not implemented.
I know Linus wants me to fix the bash completion so it adds a trailing
space when something gets completed and is unique and no additional
text is expected to follow for that argument. I just haven't put
the effort into it, even though I think I have a solution.
Basically I'm saying I probably could have another round of bash
completion in another week which may be worth considering for
inclusion. ;-)
> I am very tempted to have sliding window mmap() if it helps
> people on cygwin, for example.
Especially now that NO_MMAP is the default on that platform.
At this point it may be ready to graduate to next to try and get a
wider audience. Since fixing that segfault in pack-objects I can't
break it. Of course I couldn't break it before you found that error,
so take my words with a grain of salt... ;-)
> Also, I've been running with
> "next" for my daily pushes and pulls without trouble, and I am
> very tempted to push out the shallow-clone topic.
Hasn't that been in next for a while now? I pretty much always
run next, and have also been using it on that non-publishable
repository for almost two months now. I've got 20 other users who I
collaborate with on cygwin running next... we haven't had any issue
with the portions of shallow-clone which had already moved in, and
I upgrade that environment almost daily to keep current. Of course
we also haven't tried to actually use the shallow-clone feature as
we haven't needed it (the repository is only 50 MiB packed).
> Although I do find the detached HEAD attractive and would want
> to have it eventually, I suspect that even if it materializes
> soon enough, it would at least need a couple of weeks of testing
> in 'next', so making -rc1 wait for it might push back the
> release a bit too much.
Agreed. It would be nice to implement, expecially for a major
release like 1.5.0. I don't think its that difficult to do, we've
all just been distracted by other topics and nobody has put code
forward for it. If a well-written implementation materialized in
the next few days it might get enough cooking time before rc1 to
include it.
--
Shawn.
^ permalink raw reply
* [PATCH 1/3] t6024-recursive-merge: quiet down this test
From: Eric Wong @ 2006-12-28 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11672970521665-git-send-email-normalperson@yhbt.net>
We get an extra measure of error checking here as well.
While we're at it, also removed a less portable use of export.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t6024-recursive-merge.sh | 90 +++++++++++++++++++++++---------------------
1 files changed, 47 insertions(+), 43 deletions(-)
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
index 69b18f7..31b9625 100644
--- a/t/t6024-recursive-merge.sh
+++ b/t/t6024-recursive-merge.sh
@@ -11,50 +11,54 @@ test_description='Test merge without common ancestors'
# X \
# 2 - C - E - G
-export GIT_COMMITTER_DATE="2006-12-12 23:28:00 +0100"
-echo 1 > a1
-git add a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:00" git commit -m 1 a1
-
-git checkout -b A master
-echo A > a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:01" git commit -m A a1
-
-git checkout -b B master
-echo B > a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:02" git commit -m B a1
-
-git checkout -b D A
-git-rev-parse B > .git/MERGE_HEAD
-echo D > a1
-git update-index a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:03" git commit -m D
-
-git symbolic-ref HEAD refs/heads/other
-echo 2 > a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:04" git commit -m 2 a1
-
-git checkout -b C
-echo C > a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:05" git commit -m C a1
-
-git checkout -b E C
-git-rev-parse B > .git/MERGE_HEAD
-echo E > a1
-git update-index a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:06" git commit -m E
-
-git checkout -b G E
-git-rev-parse A > .git/MERGE_HEAD
-echo G > a1
-git update-index a1
-GIT_AUTHOR_DATE="2006-12-12 23:00:07" git commit -m G
-
-git checkout -b F D
-git-rev-parse C > .git/MERGE_HEAD
-echo F > a1
-git update-index a1
+GIT_COMMITTER_DATE="2006-12-12 23:28:00 +0100"
+export GIT_COMMITTER_DATE
+
+test_expect_success "setup tests" '
+echo 1 > a1 &&
+git add a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:00" git commit -m 1 a1 &&
+
+git checkout -b A master &&
+echo A > a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:01" git commit -m A a1 &&
+
+git checkout -b B master &&
+echo B > a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:02" git commit -m B a1 &&
+
+git checkout -b D A &&
+git-rev-parse B > .git/MERGE_HEAD &&
+echo D > a1 &&
+git update-index a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:03" git commit -m D &&
+
+git symbolic-ref HEAD refs/heads/other &&
+echo 2 > a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:04" git commit -m 2 a1 &&
+
+git checkout -b C &&
+echo C > a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:05" git commit -m C a1 &&
+
+git checkout -b E C &&
+git-rev-parse B > .git/MERGE_HEAD &&
+echo E > a1 &&
+git update-index a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:06" git commit -m E &&
+
+git checkout -b G E &&
+git-rev-parse A > .git/MERGE_HEAD &&
+echo G > a1 &&
+git update-index a1 &&
+GIT_AUTHOR_DATE="2006-12-12 23:00:07" git commit -m G &&
+
+git checkout -b F D &&
+git-rev-parse C > .git/MERGE_HEAD &&
+echo F > a1 &&
+git update-index a1 &&
GIT_AUTHOR_DATE="2006-12-12 23:00:08" git commit -m F
+'
test_expect_failure "combined merge conflicts" "git merge -m final G"
--
1.4.4.3.gd4ada
^ permalink raw reply related
* quieting down git-commit (and init-db) in tests
From: Eric Wong @ 2006-12-28 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
There are more places where the tests have gotten, but I noticed these
the most. Some non-portable uses of 'export' have been replaced.
I'll try to get to the rest in a day or two, but I'm sleepy and have
more things for git-svn to do.
--
t/t6024-recursive-merge.sh | 90 +++++++++++++++++++++-------------------
t/t9200-git-cvsexportcommit.sh | 10 +++--
t/test-lib.sh | 2 +-
3 files changed, 54 insertions(+), 48 deletions(-)
--
Eric Wong
^ permalink raw reply
* [PATCH 2/3] test-lib: quiet down init-db output for tests
From: Eric Wong @ 2006-12-28 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11672970542015-git-send-email-normalperson@yhbt.net>
I don't think anybody running tests needs to know they're
running init-db and creating a repository for testing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f0f9cd6..ad2b6f6 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -176,7 +176,7 @@ test_create_repo () {
repo="$1"
mkdir "$repo"
cd "$repo" || error "Cannot setup test environment"
- "$GIT_EXEC_PATH/git" init-db --template=$GIT_EXEC_PATH/templates/blt/ 2>/dev/null ||
+ "$GIT_EXEC_PATH/git" init-db --template=$GIT_EXEC_PATH/templates/blt/ >/dev/null 2>&1 ||
error "cannot run git init-db -- have you built things yet?"
mv .git/hooks .git/hooks-disabled
cd "$owd"
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [PATCH 3/3] t9200-git-cvsexportcommit.sh: quiet down commit
From: Eric Wong @ 2006-12-28 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11672970561224-git-send-email-normalperson@yhbt.net>
Also, fixed an unportable use of 'export'.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9200-git-cvsexportcommit.sh | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index ca0513b..315119a 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -14,16 +14,18 @@ then
exit
fi
-export CVSROOT=$(pwd)/cvsroot
-export CVSWORK=$(pwd)/cvswork
+CVSROOT=$(pwd)/cvsroot
+CVSWORK=$(pwd)/cvswork
+GIT_DIR=$(pwd)/.git
+export CVSROOT CVSWORK GIT_DIR
+
rm -rf "$CVSROOT" "$CVSWORK"
mkdir "$CVSROOT" &&
cvs init &&
cvs -Q co -d "$CVSWORK" . &&
-export GIT_DIR=$(pwd)/.git &&
echo >empty &&
git add empty &&
-git commit -a -m "Initial" 2>/dev/null ||
+git commit -q -a -m "Initial" 2>/dev/null ||
exit 1
test_expect_success \
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [PATCH 1/4] git-svn: remove non-delta fetch code paths
From: Eric Wong @ 2006-12-28 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
We have less code to worry about now. As a bonus, --revision
can be used to reliably skip parts of history whenever fetch is
run, not just the first time. I'm not sure why anybody would
want to skip history in the middle, however...
For people (nearly everyone at the moment) without the
do_switch() function in their Perl SVN library, the entire tree
must be refetched if --follow-parent is used and a parent is
found. Future versions of SVN will have a working do_switch()
function accessible via Perl.
Accessing repositories on the local machine (especially file://
ones) is also slightly slower as a result; but I suspect most
git-svn users will be using it to access remote repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 194 ++++++----------------------------------------------------
t/Makefile | 3 +-
2 files changed, 21 insertions(+), 176 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index c2cdceb..0ef13b2 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -69,7 +69,7 @@ my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
$_version, $_upgrade, $_authors, $_branch_all_refs, @_opt_m,
$_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive,
- $_username, $_config_dir, $_no_auth_cache, $_xfer_delta,
+ $_username, $_config_dir, $_no_auth_cache,
$_pager, $_color);
my (@_branch_from, %tree_map, %users, %rusers, %equiv);
my ($_svn_can_do_switch);
@@ -2044,13 +2044,6 @@ sub libsvn_connect {
config => $config,
pool => SVN::Pool->new,
auth_provider_callbacks => $callbacks);
-
- my $df = $ENV{GIT_SVN_DELTA_FETCH};
- if (defined $df) {
- $_xfer_delta = $df;
- } else {
- $_xfer_delta = ($url =~ m#^file://#) ? undef : 1;
- }
$ra->{svn_path} = $url;
$ra->{repos_root} = $ra->get_repos_root;
$ra->{svn_path} =~ s#^\Q$ra->{repos_root}\E/*##;
@@ -2082,49 +2075,6 @@ sub libsvn_dup_ra {
auth auth_provider_callbacks repos_root svn_path/);
}
-sub libsvn_get_file {
- my ($gui, $f, $rev, $chg, $untracked) = @_;
- $f =~ s#^/##;
- print "\t$chg\t$f\n" unless $_q;
-
- my ($hash, $pid, $in, $out);
- my $pool = SVN::Pool->new;
- defined($pid = open3($in, $out, '>&STDERR',
- qw/git-hash-object -w --stdin/)) or croak $!;
- # redirect STDOUT for SVN 1.1.x compatibility
- open my $stdout, '>&', \*STDOUT or croak $!;
- open STDOUT, '>&', $in or croak $!;
- my ($r, $props) = $SVN->get_file($f, $rev, \*STDOUT, $pool);
- $in->flush == 0 or croak $!;
- open STDOUT, '>&', $stdout or croak $!;
- close $in or croak $!;
- close $stdout or croak $!;
- $pool->clear;
- chomp($hash = do { local $/; <$out> });
- close $out or croak $!;
- waitpid $pid, 0;
- $hash =~ /^$sha1$/o or die "not a sha1: $hash\n";
-
- my $mode = exists $props->{'svn:executable'} ? '100755' : '100644';
- if (exists $props->{'svn:special'}) {
- $mode = '120000';
- my $link = `git-cat-file blob $hash`; # no chomping symlinks
- $link =~ s/^link // or die "svn:special file with contents: <",
- $link, "> is not understood\n";
- defined($pid = open3($in, $out, '>&STDERR',
- qw/git-hash-object -w --stdin/)) or croak $!;
- print $in $link;
- $in->flush == 0 or croak $!;
- close $in or croak $!;
- chomp($hash = do { local $/; <$out> });
- close $out or croak $!;
- waitpid $pid, 0;
- $hash =~ /^$sha1$/o or die "not a sha1: $hash\n";
- }
- %{$untracked->{file_prop}->{$f}} = %$props;
- print $gui $mode,' ',$hash,"\t",$f,"\0" or croak $!;
-}
-
sub uri_encode {
my ($f) = @_;
$f =~ s#([^a-zA-Z0-9\*!\:_\./\-])#uc sprintf("%%%02x",ord($1))#eg;
@@ -2232,10 +2182,6 @@ sub process_rm {
}
sub libsvn_fetch {
- $_xfer_delta ? libsvn_fetch_delta(@_) : libsvn_fetch_full(@_);
-}
-
-sub libsvn_fetch_delta {
my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
my $pool = SVN::Pool->new;
my $ed = SVN::Git::Fetcher->new({ c => $last_commit, q => $_q });
@@ -2251,66 +2197,6 @@ sub libsvn_fetch_delta {
libsvn_log_entry($rev, $author, $date, $msg, [$last_commit], $ed);
}
-sub libsvn_fetch_full {
- my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
- my ($gui, $ctx) = command_input_pipe(qw/update-index -z --index-info/);
- my %amr;
- my $ut = { empty => {}, dir_prop => {}, file_prop => {} };
- my $p = $SVN->{svn_path};
- foreach my $f (keys %$paths) {
- my $m = $paths->{$f}->action();
- if (length $p) {
- $f =~ s#^/\Q$p\E/##;
- next if $f =~ m#^/#;
- } else {
- $f =~ s#^/##;
- }
- if ($m =~ /^[DR]$/) {
- my $t = process_rm($gui, $last_commit, $f, $_q);
- if ($m eq 'D') {
- $ut->{empty}->{$f} = 0 if $t == $SVN::Node::dir;
- next;
- }
- # 'R' can be file replacements, too, right?
- }
- my $pool = SVN::Pool->new;
- my $t = $SVN->check_path($f, $rev, $pool);
- if ($t == $SVN::Node::file) {
- if ($m =~ /^[AMR]$/) {
- $amr{$f} = $m;
- } else {
- die "Unrecognized action: $m, ($f r$rev)\n";
- }
- } elsif ($t == $SVN::Node::dir && $m =~ /^[AR]$/) {
- my @traversed = ();
- libsvn_traverse($gui, '', $f, $rev, \@traversed, $ut);
- if (@traversed) {
- foreach (@traversed) {
- $amr{$_} = $m;
- }
- } else {
- my ($dir, $file) = ($f =~ m#^(.*?)/?([^/]+)$#);
- delete $ut->{empty}->{$dir};
- $ut->{empty}->{$f} = 1;
- }
- }
- $pool->clear;
- }
- foreach (keys %amr) {
- libsvn_get_file($gui, $_, $rev, $amr{$_}, $ut);
- my ($d) = ($_ =~ m#^(.*?)/?(?:[^/]+)$#);
- delete $ut->{empty}->{$d};
- }
- unless (exists $ut->{dir_prop}->{''}) {
- my $pool = SVN::Pool->new;
- my (undef, undef, $props) = $SVN->get_dir('', $rev, $pool);
- %{$ut->{dir_prop}->{''}} = %$props;
- $pool->clear;
- }
- command_close_pipe($gui, $ctx);
- libsvn_log_entry($rev, $author, $date, $msg, [$last_commit], $ut);
-}
-
sub svn_grab_base_rev {
my $c = eval { command_oneline([qw/rev-parse --verify/,
"refs/remotes/$GIT_SVN^0"],
@@ -2362,41 +2248,6 @@ sub libsvn_parse_revision {
"Try using the command-line svn client instead\n";
}
-sub libsvn_traverse {
- my ($gui, $pfx, $path, $rev, $files, $untracked) = @_;
- my $cwd = length $pfx ? "$pfx/$path" : $path;
- my $pool = SVN::Pool->new;
- $cwd =~ s#^\Q$SVN->{svn_path}\E##;
- my $nr = 0;
- my ($dirent, $r, $props) = $SVN->get_dir($cwd, $rev, $pool);
- %{$untracked->{dir_prop}->{$cwd}} = %$props;
- foreach my $d (keys %$dirent) {
- my $t = $dirent->{$d}->kind;
- if ($t == $SVN::Node::dir) {
- my $i = libsvn_traverse($gui, $cwd, $d, $rev,
- $files, $untracked);
- if ($i) {
- $nr += $i;
- } else {
- $untracked->{empty}->{"$cwd/$d"} = 1;
- }
- } elsif ($t == $SVN::Node::file) {
- $nr++;
- my $file = "$cwd/$d";
- if (defined $files) {
- push @$files, $file;
- } else {
- libsvn_get_file($gui, $file, $rev, 'A',
- $untracked);
- my ($dir) = ($file =~ m#^(.*?)/?(?:[^/]+)$#);
- delete $untracked->{empty}->{$dir};
- }
- }
- }
- $pool->clear;
- $nr;
-}
-
sub libsvn_traverse_ignore {
my ($fh, $path, $r) = @_;
$path =~ s#^/+##g;
@@ -2488,8 +2339,8 @@ sub libsvn_find_parent_branch {
print STDERR "Found branch parent: ($GIT_SVN) $parent\n";
command_noisy('read-tree', $parent);
unless (libsvn_can_do_switch()) {
- return libsvn_fetch_full($parent, $paths, $rev,
- $author, $date, $msg);
+ return _libsvn_new_tree($paths, $rev, $author, $date,
+ $msg, [$parent]);
}
# do_switch works with svn/trunk >= r22312, but that is not
# included with SVN 1.4.2 (the latest version at the moment),
@@ -2514,7 +2365,7 @@ sub libsvn_find_parent_branch {
sub libsvn_get_log {
my ($ra, @args) = @_;
- $args[4]-- if $args[4] && $_xfer_delta && ! $_follow_parent;
+ $args[4]-- if $args[4] && ! $_follow_parent;
if ($SVN::Core::VERSION le '1.2.0') {
splice(@args, 3, 1);
}
@@ -2525,28 +2376,23 @@ sub libsvn_new_tree {
if (my $log_entry = libsvn_find_parent_branch(@_)) {
return $log_entry;
}
- my ($paths, $rev, $author, $date, $msg) = @_;
- my $ut;
- if ($_xfer_delta) {
- my $pool = SVN::Pool->new;
- my $ed = SVN::Git::Fetcher->new({q => $_q});
- my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
- my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
- $reporter->set_path('', $rev, 1, @lock, $pool);
- $reporter->finish_report($pool);
- $pool->clear;
- unless ($ed->{git_commit_ok}) {
- die "SVN connection failed somewhere...\n";
- }
- $ut = $ed;
- } else {
- $ut = { empty => {}, dir_prop => {}, file_prop => {} };
- my ($gui, $ctx) = command_input_pipe(qw/update-index
- -z --index-info/);
- libsvn_traverse($gui, '', $SVN->{svn_path}, $rev, undef, $ut);
- command_close_pipe($gui, $ctx);
+ my ($paths, $rev, $author, $date, $msg) = @_; # $pool is last
+ _libsvn_new_tree($paths, $rev, $author, $date, $msg, []);
+}
+
+sub _libsvn_new_tree {
+ my ($paths, $rev, $author, $date, $msg, $parents) = @_;
+ my $pool = SVN::Pool->new;
+ my $ed = SVN::Git::Fetcher->new({q => $_q});
+ my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
+ my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
+ $reporter->set_path('', $rev, 1, @lock, $pool);
+ $reporter->finish_report($pool);
+ $pool->clear;
+ unless ($ed->{git_commit_ok}) {
+ die "SVN connection failed somewhere...\n";
}
- libsvn_log_entry($rev, $author, $date, $msg, [], $ut);
+ libsvn_log_entry($rev, $author, $date, $msg, $parents, $ed);
}
sub find_graft_path_commit {
diff --git a/t/Makefile b/t/Makefile
index 250a190..19e3850 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -23,8 +23,7 @@ clean:
# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
full-svn-test:
- $(MAKE) $(TSVN) GIT_SVN_DELTA_FETCH=1 \
- GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
+ $(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
$(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=0 LC_ALL=en_US.UTF-8
.PHONY: $(T) clean
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [PATCH 2/4] git-svn: print out the SVN library version in --version, too
From: Eric Wong @ 2006-12-28 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11672973823960-git-send-email-normalperson@yhbt.net>
This could be useful in finding new problems and helping users
debug.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0ef13b2..a772ce8 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -216,7 +216,7 @@ information.
}
sub version {
- print "git-svn version $VERSION\n";
+ print "git-svn version $VERSION (svn $SVN::Core::VERSION)\n";
exit 0;
}
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [PATCH 4/4] git-svn: sort multi-init output
From: Eric Wong @ 2006-12-28 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11672973823960-git-send-email-normalperson@yhbt.net>
This looks a bit more pleasant for users.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 74a3424..b28c5bb 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2481,7 +2481,7 @@ sub libsvn_ls_fullurl {
my $pool = SVN::Pool->new;
my $r = defined $_revision ? $_revision : $ra->get_latest_revnum;
my ($dirent, undef, undef) = $ra->get_dir('', $r, $pool);
- foreach my $d (keys %$dirent) {
+ foreach my $d (sort keys %$dirent) {
if ($dirent->{$d}->kind == $SVN::Node::dir) {
push @ret, "$d/"; # add '/' for compat with cli svn
}
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [PATCH 3/4] git-svn: verify_ref() should actually --verify
From: Eric Wong @ 2006-12-28 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11672973823960-git-send-email-normalperson@yhbt.net>
Not sure how I missed this the first time around...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a772ce8..74a3424 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1098,7 +1098,8 @@ sub read_uuid {
sub verify_ref {
my ($ref) = @_;
- eval { command_oneline([ 'rev-parse', $ref ], { STDERR => 0 }) };
+ eval { command_oneline([ 'rev-parse', '--verify', $ref ],
+ { STDERR => 0 }); };
}
sub repo_path_split {
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [ANNOUNCE] qgit-1.5.4
From: Marco Costalba @ 2006-12-28 9:23 UTC (permalink / raw)
To: Git Mailing List
This is mostly a bug fix release. Plus a (big) performance increase when
loading a repository (warm cache case).
Data exchange with 'git rev-list' is now based on temporary files
instead of Qt QProcess class, this leads to a 40% increase under Linux
with a tmpfs filesystem mounted under /tmp, as is common with most
distributions. In case of portability issues it is possible to
fallback on a standard QProcess based interface. To do this uncomment
USE_QPROCESS define in 'src/dataloader.h' before to compile.
NOTE: qgit now uses faster 'git show-ref' instead of 'git peek-remote'
to read the tags so git v1.4.4 or later is required.
NOTE2: qgit is now compiled with -frepo option to remove redundant
template instantations, this leads to a little longer compile time and
some messages from 'collect' tool at the end of compilation. Don't
worry, it's all ok ;-)
Many thanks as usual to Pavel Roskin for help and patches.
Download tarball from http://www.sourceforge.net/projects/qgit
or directly from git public repository
git://git.kernel.org/pub/scm/qgit/qgit.git
Please refer to http://digilander.libero.it/mcostalba/ for additional
information.
Marco
ChangeLog from 1.5.3
- improve load speed of 40% using a temporary file to read from 'git rev-list'
- fix many typos found by aspell, mostly in the comments (Pavel Roskin)
- increase to seven the number of recent repos menu entries
- fix a possible NULL dereferencing spotted by Klockwork K7.5
- fix a warning on 64-bit systems (Pavel Roskin)
- show also load speed as MB/s in status bar
- read file names cache after repository has been loaded. Good speedup 'feeling'
- allow to tag the same revision more then once
- mark with light green tag only current branch
- remove current HEAD from startup tag list. Spotted by Toralf Foerster
- use faster 'git show-ref' instead of 'git peek-remote'. Requires git v1.4.4
- complete rewrite references reading and handling: speedup and cleaner code
- be more user friendly when creating a new action
- quit if unable to parse command line arguments
- fix display issue when commit title length is less then 4
- increase file history list browsing speed
- resolve links also for an abbreviated sha in revision description pane
- fix tree view not correctly updated in rare cases
- fix an issue in file history with revisions that delete a file
- hide tag marker for HEAD also when is under refs/remotes
- compile with -frepo flag to remove duplicated template instances
^ permalink raw reply
* Re: [PATCH 3/3] t9200-git-cvsexportcommit.sh: quiet down commit
From: Junio C Hamano @ 2006-12-28 9:24 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11672970581666-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Also, fixed an unportable use of 'export'.
As a traditionalist, I tend to prefer "var=val; export var" over
"export var=val" myself, but I wonder how unportable this is
these days.
Just wondering, no objection.
Do you have a specific shell in mind that groks other constructs
used in our tests but not "export var=val" form?
^ permalink raw reply
* Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
From: Junio C Hamano @ 2006-12-28 9:35 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228081701.GA18029@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> I personally think this is not an improvement, but rather a new
>> source of confusion. If the user wants a local merge, there is
>> 'git-merge'. And the distinction between the commands makes it
>> clear that local merge can merge any commits exactly because
>> they are available locally, while remote fetch+merge needs to
>> choose from what the remote side offers so not arbitrary commits
>> like foo@{3.days.ago} cannot be pulled.
>
> True. But you know you are doing a local merge with `git pull .`.
> So why should you be restricted from using the capabilities of a
> local merge just because the frontend you prefer to use is limited
> when its doing remote merges?
Personally I do not mind much about it because I happen to
understand what "git pull" is doing.
But I do mind having to spend time defending why we special case
only the dot form, when people with twisted minds start
complaining about inconsistencies among "git pull .git", "git
pull ." and "git pull $(pwd)". And no, I do not want to
introduce likes of "test `cd .git && pwd` == `cd $1 && pwd`" in
the code to make them behave consistently.
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Junio C Hamano @ 2006-12-28 11:04 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228084245.GA18150@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
> ...
>> I am very tempted to have sliding window mmap() if it helps
>> people on cygwin, for example.
>
> Especially now that NO_MMAP is the default on that platform.
> At this point it may be ready to graduate to next to try and get a
> wider audience. Since fixing that segfault in pack-objects I can't
> break it. Of course I couldn't break it before you found that error,
> so take my words with a grain of salt... ;-)
Well, I have a bad news for you.
"ng refs/heads/master n/a (unpacker error)" is back. I cannot
push things out.
But a bad news is that the problem does not decompose so easily;
git-push has too many players involved. I _think_ I have the
list of positive and negative objects fed to rev-list --objects
--thin --stdin, whose output is in turn fed to pack-objects, but
manually running these steps in isolation seems to produce an Ok
result that index-pack --stdin --fix-thin accepts happily.
While I was looking at the problem, I noticed something a bit
easier to reproduce and should be lot easier to diagnose. At
http://userweb.kernel.org/~junio/broken.tar, I have a tarball of
git.git repository.
When you extract it, you will have a directory "broken/" with a
single directory ".git/" in it. The repository passes
"fsck-objects --full" from master just fine.
However, if you try to "git repack -a -d" it using "next" plus
"sp/mmap" with your latest fix ("pu" also has it), you will see:
Generating pack...
Done counting 32054 objects.
fatal: internal error: pack revindex corrupt
In that sample repository, I have pack.window, and
repack.deltabaseoffset. These settings do not seem to affect
the breakage.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Jakub Narebski @ 2006-12-28 11:50 UTC (permalink / raw)
To: git
In-Reply-To: <7v64bw3ewk.fsf@assigned-by-dhcp.cox.net>
[Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>,
"Horst H. von Brand" <vonbrand@inf.utfsm.cl>]
Junio C Hamano wrote:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>
>> Junio C Hamano <junkio@cox.net> wrote:
>>> This is still rough, but I think we have a pretty good idea what
>>> will and what won't be in v1.5.0 by now, and end-of-year is a
>>> good slow time to summarize what we have done.
>>
>> Could somebody please summarize how to "upgrade" a repository to the new
>> layout? This has got my head spinning... and I'm /not/ cloning the
>> various repos I've got here just to take advantage of the changes.
>
> The old layout was to map remote branch $B to local tracking
> branch .git/refs/heads/$B, unless $B == 'master' in which case
> it was mapped to .git/refs/heads/origin (and I think we
> discarded 'origin' at remote).
How to discard 'origin' in the new wildcard / globbing remote config?
IIRC there was proposal to use '-' or '!' to exclude branch from
fetching, but no code...
[...]
> - create the config section like the above in .git/config, and
You can use contrib/remotes2config.sh script...
> - remove .git/remotes/origin when you are done.
...which saves remotes/ under remotes.old/
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] Teach git-reset to let others override its reflog entry.
From: Jakub Narebski @ 2006-12-28 11:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vslf0zgwp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Then calls to "git-update-ref -m" could use the value of
> "$GIT_REFLOG_ACTION", without explicit --reflog-action=
> parameters and $rloga variables.
I think that --reflog-action should then be used to set GIT_REFLOG_ACTION,
slightly similarly to how --git-dir sets GIT_DIR variable.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: t9200-git-cvsexportcommit.sh failed on CYGWIN
From: Jakub Narebski @ 2006-12-28 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <459338AA.8000407@gmail.com>
[Cc: git@vger.kernel.org]
SungHyun Nam wrote:
> Below is the test messages.
>
> BTW, I hope I can define 'NO_CVS_TESTS' to skip this test.
[...]
> * ok 7: Update file with spaces in file name
> * FAIL 8: File with non-ascii file name
> mkdir -p
What filesystem? Some filesystems are just broken...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] update hook: redirect _both_ diagnostic lines to stderr upon tag failure
From: Jim Meyering @ 2006-12-28 15:05 UTC (permalink / raw)
To: git
Otherwise, sending the diagnostic to stdout would provoke a protocol failure.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
templates/hooks--update | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index 76d5ac2..9863a80 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -19,7 +19,7 @@ # Remove this code to treat dumb tags th
case "$1","$ref_type" in
refs/tags/*,commit)
echo "*** Un-annotated tags are not allowed in this repo" >&2
- echo "*** Use 'git tag [ -a | -s ]' for tags you want to propagate."
+ echo "*** Use 'git tag [ -a | -s ]' for tags you want to propagate." >&2
exit 1;;
refs/tags/*,tag)
echo "### Pushing version '${1##refs/tags/}' to the masses" >&2
--
1.4.2.GIT
^ permalink raw reply related
* [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Johannes Schindelin @ 2006-12-28 16:13 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <87fyb11ouy.fsf@wine.dyndns.org>
The function xdl_refine_conflicts() tries to break down huge
conflicts by doing a diff on the conflicting regions. However,
this does not make sense when one side is empty.
Worse, when one side is not only empty, but after EOF, the code
accessed unmapped memory.
Noticed by Luben Tuikov, Shawn Pearce and Alexandre Julliard, the
latter providing a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Thank you Alexandre! I looked for the bug for quite some time, but
was never close to the real culprit.
t/t6023-merge-file.sh | 22 ++++++++++++++++++++++
xdiff/xmerge.c | 4 ++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index 5d9b6f3..1c21d8c 100644
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -112,5 +112,27 @@ EOF
test_expect_success "expected conflict markers, with -L" \
"diff -u test.txt expect.txt"
+sed "s/ tu / TU /" < new1.txt > new5.txt
+test_expect_failure "conflict in removed tail" \
+ "git-merge-file -p orig.txt new1.txt new5.txt > out"
+
+cat > expect << EOF
+Dominus regit me,
+et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+<<<<<<< orig.txt
+=======
+Nam et si ambulavero in medio umbrae mortis,
+non timebo mala, quoniam TU mecum es:
+virga tua et baculus tuus ipsa me consolata sunt.
+>>>>>>> new5.txt
+EOF
+
+test_expect_success "expected conflict markers" "diff -u expect out"
+
test_done
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 352207e..294450b 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -190,6 +190,10 @@ static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
if (m->mode)
continue;
+ /* no sense refining a conflict when one side is empty */
+ if (m->chg1 == 0 || m->chg2 == 0)
+ continue;
+
/*
* This probably does not work outside git, since
* we have a very simple mmfile structure.
--
1.5.0.rc0.g09372-dirty
^ permalink raw reply related
* Re: [PATCH 3/3] t9200-git-cvsexportcommit.sh: quiet down commit
From: Eric Wong @ 2006-12-28 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyb0wexo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Also, fixed an unportable use of 'export'.
>
> As a traditionalist, I tend to prefer "var=val; export var" over
> "export var=val" myself, but I wonder how unportable this is
> these days.
>
> Just wondering, no objection.
>
> Do you have a specific shell in mind that groks other constructs
> used in our tests but not "export var=val" form?
I can't remember, and I can't seem to find one, either. Even posh
(latest debian unstable) and ash (from woody) seem to support it...
On a related note, how portable is mkdir -p these days? I remember
seeing systems that don't have it, too.
--
Eric Wong
^ permalink raw reply
* read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Martin Langhoff @ 2006-12-28 20:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, H. Peter Anvin, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
On 12/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, just looking at the examples, it looks like memcached is
> fundamentally flawed, exactly the same way Apache mod_cache is
> fundamentally flawed.
memcached is really fast internally, but can be rather slow from the
POV of the client code, as it forces a costly
marshalling/unmarshalling of data. For perl-only situations where it
is OK to have per-server caches, I have been looking at
Cache::FastMmap. I will probably try to implement caching for the
projects, summary & log/shortlog pages using Cache::FastMap
And I'll do read-for-fill for it, and see how that goes.
(BTW, in the last week I've had to implement a similar
anti-thundering-herds cache in PHP using memcached and/or eaccelerator
-- a shmem cache -- and I've done a read-for-fill for both of them
that works reasonably well.)
cheers,
martin
^ 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