* Re: [PATCH] for-each-ref: add split message parts to %(contents:*).
From: Jeff King @ 2011-09-07 17:40 UTC (permalink / raw)
To: Michał Górny; +Cc: git, Junio C Hamano, Michael J Gruber
In-Reply-To: <20110902175323.GA29761@sigill.intra.peff.net>
On Fri, Sep 02, 2011 at 01:53:23PM -0400, Jeff King wrote:
> But there may be other corner cases. I need to read through the code
> more carefully, which I should have time to do later today.
This ended up a little trickier than I expected, but I think the series
below is what we should do. I tried to add extensive tests, but let me
know if you can think of any other corner cases.
[1/5]: t7004: factor out gpg setup
[2/5]: t6300: add more body-parsing tests
[3/5]: for-each-ref: refactor subject and body placeholder parsing
[4/5]: for-each-ref: handle multiline subjects like --pretty
[5/5]: for-each-ref: add split message parts to %(contents:*).
-Peff
^ permalink raw reply
* [PATCH v2] git-svn: teach git-svn to populate svn:mergeinfo
From: Bryan Jacobs @ 2011-09-07 17:36 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Sam Vilain
Allow git-svn to populate the svn:mergeinfo property automatically in
a narrow range of circumstances. Specifically, when dcommitting a
revision with multiple parents, all but (potentially) the first of
which have been committed to SVN in the same repository as the target
of the dcommit.
In this case, the merge info is the union of that given by each of the
parents, plus all changes introduced to the first parent by the other
parents.
In all other cases where a revision to be committed has multiple
parents, cause "git svn dcommit" to raise an error rather than
completing the commit and potentially losing history information in
the upstream SVN repository.
This behavior is disabled by default, and can be enabled by setting
the svn.pushmergeinfo config option.
Signed-off-by: Bryan Jacobs <bjacobs@woti.com>
---
This is the second revision of a patch I posted earlier. I believe this patch is now suitable for inclusion.
Significant changes from the last revision are:
- All revisions in the commit list are checked beforehand to ensure that all non-first-parents of merge commits have suitable SVN metadata attached.
- Cases where a merge commit is at the top of an uncommitted stack are tested and now work correctly.
- Cleanups as suggested by Eric Wong.
This code is still vulnerable to race conditions if the git repository is modified while a dcommit is in progress, but this is a fundamental problem with git-svn's continual-rebasing-series approach, as previously discussed.
I believe I have determined the source of the added+untracked files in the working copy. With this repository:
branch1: A - B
/
branch2: C
If a file is added in C, and you attempt to dcommit B (C must be dcommitted or the problem will be detected and the commit will abort), git-svn runs a reset --mixed. So because the files added in C were present in B, they remain present but are untracked when you reset --mixed to A. So you cannot apply B to the rebased state because it would "create" the file you already have (with, admittedly, identical contents).
I'm not clear on why git will not allow this to proceed - the file in the working copy is identical to the file that would be "created", so there's no loss of data. "file would be overwritten", yes, technically, but never altered, so no problem really... Might be a user-interface consistency issue to allow it, but I'd be inclined to say git's behavior should change.
Regardless, this could be solved by using a reset --hard to A before beginning. Since we already disallow dcommitting with a dirty WC, this should be safe (never thought I'd say that about a reset --hard). I'm not going to write that change, though.
Of course, users could also recover from even the worst disaster via the reflog.
Documentation/git-svn.txt | 8 +
git-svn.perl | 255 +++++++++++++++++++++++++
t/t9160-git-svn-mergeinfo-push.sh | 104 ++++++++++
t/t9160/branches.dump | 374 +++++++++++++++++++++++++++++++++++++
4 files changed, 741 insertions(+), 0 deletions(-)
create mode 100755 t/t9160-git-svn-mergeinfo-push.sh
create mode 100644 t/t9160/branches.dump
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ed5eca1..89955a2 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -213,6 +213,14 @@ discouraged.
store this information (as a property), and svn clients starting from
version 1.5 can make use of it. 'git svn' currently does not use it
and does not set it automatically.
++
+[verse]
+config key: svn.pushmergeinfo
++
+This option will cause git-svn to attempt to automatically populate the
+svn:mergeinfo property in the SVN repository when possible. Currently, this can
+only be done when dcommitting non-fast-forward merges where all parents but the
+first have already been pushed into SVN.
'branch'::
Create a branch in the SVN repository.
diff --git a/git-svn.perl b/git-svn.perl
index 89f83fd..bf60300 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -497,6 +497,195 @@ sub cmd_set_tree {
unlink $gs->{index};
}
+sub split_merge_info_range {
+ my ($range) = @_;
+ if ($range =~ /(\d+)-(\d+)/) {
+ return (int($1), int($2));
+ } else {
+ return (int($range), int($range));
+ }
+}
+
+sub combine_ranges {
+ my ($in) = @_;
+
+ my @fnums = ();
+ my @arr = split(/,/, $in);
+ for my $element (@arr) {
+ my ($start, $end) = split_merge_info_range($element);
+ push @fnums, $start;
+ }
+
+ my @sorted = @arr [ sort {
+ $fnums[$a] <=> $fnums[$b]
+ } 0..$#arr ];
+
+ my @return = ();
+ my $last = -1;
+ my $first = -1;
+ for my $element (@sorted) {
+ my ($start, $end) = split_merge_info_range($element);
+
+ if ($last == -1) {
+ $first = $start;
+ $last = $end;
+ next;
+ }
+ if ($start <= $last+1) {
+ if ($end > $last) {
+ $last = $end;
+ }
+ next;
+ }
+ if ($first == $last) {
+ push @return, "$first";
+ } else {
+ push @return, "$first-$last";
+ }
+ $first = $start;
+ $last = $end;
+ }
+
+ if ($first != -1) {
+ if ($first == $last) {
+ push @return, "$first";
+ } else {
+ push @return, "$first-$last";
+ }
+ }
+
+ return join(',', @return);
+}
+
+sub merge_revs_into_hash {
+ my ($hash, $minfo) = @_;
+ my @lines = split(' ', $minfo);
+
+ for my $line (@lines) {
+ my ($branchpath, $revs) = split(/:/, $line);
+
+ if (exists($hash->{$branchpath})) {
+ # Merge the two revision sets
+ my $combined = "$hash->{$branchpath},$revs";
+ $hash->{$branchpath} = combine_ranges($combined);
+ } else {
+ # Just do range combining for consolidation
+ $hash->{$branchpath} = combine_ranges($revs);
+ }
+ }
+}
+
+sub merge_merge_info {
+ my ($mergeinfo_one, $mergeinfo_two) = @_;
+ my %result_hash = ();
+
+ merge_revs_into_hash(\%result_hash, $mergeinfo_one);
+ merge_revs_into_hash(\%result_hash, $mergeinfo_two);
+
+ my $result = '';
+ # Sort below is for consistency's sake
+ for my $branchname (sort keys(%result_hash)) {
+ my $revlist = $result_hash{$branchname};
+ $result .= "$branchname:$revlist\n"
+ }
+ return $result;
+}
+
+sub populate_merge_info {
+ my ($d, $gs, $uuid, $linear_refs, $rewritten_parent) = @_;
+
+ my %parentshash;
+ read_commit_parents(\%parentshash, $d);
+ my @parents = @{$parentshash{$d}};
+ if ($#parents > 0) {
+ # Merge commit
+ my $all_parents_ok = 1;
+ my $aggregate_mergeinfo = '';
+ my $rooturl = $gs->repos_root;
+
+ if (defined($rewritten_parent)) {
+ # Replace first parent with newly-rewritten version
+ shift @parents;
+ unshift @parents, $rewritten_parent;
+ }
+
+ foreach my $parent (@parents) {
+ my ($branchurl, $svnrev, $paruuid) =
+ cmt_metadata($parent);
+
+ unless (defined($svnrev)) {
+ # Should have been caught be preflight check
+ fatal "merge commit $d has ancestor $parent, but that change "
+ ."does not have git-svn metadata!";
+ }
+ unless ($branchurl =~ /^$rooturl(.*)/) {
+ fatal "commit $parent git-svn metadata changed mid-run!";
+ }
+ my $branchpath = $1;
+
+ my $ra = Git::SVN::Ra->new($branchurl);
+ my (undef, undef, $props) =
+ $ra->get_dir(canonicalize_path("."), $svnrev);
+ my $par_mergeinfo = $props->{'svn:mergeinfo'};
+ unless (defined $par_mergeinfo) {
+ $par_mergeinfo = '';
+ }
+ # Merge previous mergeinfo values
+ $aggregate_mergeinfo =
+ merge_merge_info($aggregate_mergeinfo,
+ $par_mergeinfo, 0);
+
+ next if $parent eq $parents[0]; # Skip first parent
+ # Add new changes being placed in tree by merge
+ my @cmd = (qw/rev-list --reverse/,
+ $parent, qw/--not/);
+ foreach my $par (@parents) {
+ unless ($par eq $parent) {
+ push @cmd, $par;
+ }
+ }
+ my @revsin = ();
+ my ($revlist, $ctx) = command_output_pipe(@cmd);
+ while (<$revlist>) {
+ my $irev = $_;
+ chomp $irev;
+ my (undef, $csvnrev, undef) =
+ cmt_metadata($irev);
+ unless (defined $csvnrev) {
+ # A child is missing SVN annotations...
+ # this might be OK, or might not be.
+ warn "W:child $irev is merged into revision "
+ ."$d but does not have git-svn metadata. "
+ ."This means git-svn cannot determine the "
+ ."svn revision numbers to place into the "
+ ."svn:mergeinfo property. You must ensure "
+ ."a branch is entirely committed to "
+ ."SVN before merging it in order for "
+ ."svn:mergeinfo population to function "
+ ."properly";
+ }
+ push @revsin, $csvnrev;
+ }
+ command_close_pipe($revlist, $ctx);
+
+ last unless $all_parents_ok;
+
+ # We now have a list of all SVN revnos which are
+ # merged by this particular parent. Integrate them.
+ next if $#revsin == -1;
+ my $newmergeinfo = "$branchpath:" . join(',', @revsin);
+ $aggregate_mergeinfo =
+ merge_merge_info($aggregate_mergeinfo,
+ $newmergeinfo, 1);
+ }
+ if ($all_parents_ok and $aggregate_mergeinfo) {
+ return $aggregate_mergeinfo;
+ }
+ }
+
+ return undef;
+}
+
sub cmd_dcommit {
my $head = shift;
command_noisy(qw/update-index --refresh/);
@@ -547,6 +736,62 @@ sub cmd_dcommit {
"without --no-rebase may be required."
}
my $expect_url = $url;
+
+ my $push_merge_info = eval {
+ command_oneline(qw/config --get svn.pushmergeinfo/)
+ };
+ if (not defined($push_merge_info)
+ or $push_merge_info eq "false"
+ or $push_merge_info eq "no"
+ or $push_merge_info eq "never") {
+ $push_merge_info = 0;
+ }
+
+ unless (defined $_merge_info or not $push_merge_info) {
+ # Preflight check of changes to ensure no issues with mergeinfo
+ # This includes check for uncommitted-to-SVN parents
+ # (other than the first parent, which we will handle),
+ # information from different SVN repos, and paths
+ # which are not underneath this repository root.
+ my $rooturl = $gs->repos_root;
+ foreach my $d (@$linear_refs) {
+ my %parentshash;
+ read_commit_parents(\%parentshash, $d);
+ my @realparents = @{$parentshash{$d}};
+ if ($#realparents > 0) {
+ # Merge commit
+ shift @realparents; # Remove/ignore first parent
+ foreach my $parent (@realparents) {
+ my ($branchurl, $svnrev, $paruuid) = cmt_metadata($parent);
+ unless (defined $paruuid) {
+ # A parent is missing SVN annotations...
+ # abort the whole operation.
+ fatal "$parent is merged into revision $d, "
+ ."but does not have git-svn metadata. "
+ ."Either dcommit the branch or use a "
+ ."local cherry-pick, FF merge, or rebase "
+ ."instead of an explicit merge commit.";
+ }
+
+ unless ($paruuid eq $uuid) {
+ # Parent has SVN metadata from different repository
+ fatal "merge parent $parent for change $d has "
+ ."git-svn uuid $paruuid, while current change "
+ ."has uuid $uuid!";
+ }
+
+ unless ($branchurl =~ /^$rooturl(.*)/) {
+ # This branch is very strange indeed.
+ fatal "merge parent $parent for $d is on branch "
+ ."$branchurl, which is not under the "
+ ."git-svn root $rooturl!";
+ }
+ }
+ }
+ }
+ }
+
+ my $rewritten_parent;
Git::SVN::remove_username($expect_url);
while (1) {
my $d = shift @$linear_refs or last;
@@ -561,6 +806,13 @@ sub cmd_dcommit {
print "diff-tree $d~1 $d\n";
} else {
my $cmt_rev;
+
+ unless (defined $_merge_info or not $push_merge_info) {
+ $_merge_info = populate_merge_info($d, $gs, $uuid,
+ $linear_refs,
+ $rewritten_parent);
+ }
+
my %ed_opts = ( r => $last_rev,
log => get_commit_entry($d)->{log},
ra => Git::SVN::Ra->new($url),
@@ -603,6 +855,9 @@ sub cmd_dcommit {
@finish = qw/reset --mixed/;
}
command_noisy(@finish, $gs->refname);
+
+ $rewritten_parent = command_oneline(qw/rev-parse HEAD/);
+
if (@diff) {
@refs = ();
my ($url_, $rev_, $uuid_, $gs_) =
diff --git a/t/t9160-git-svn-mergeinfo-push.sh b/t/t9160-git-svn-mergeinfo-push.sh
new file mode 100755
index 0000000..216f3d7
--- /dev/null
+++ b/t/t9160-git-svn-mergeinfo-push.sh
@@ -0,0 +1,104 @@
+#!/bin/sh
+#
+# Portions copyright (c) 2007, 2009 Sam Vilain
+# Portions copyright (c) 2011 Bryan Jacobs
+#
+
+test_description='git-svn svn mergeinfo propagation'
+
+. ./lib-git-svn.sh
+
+test_expect_success 'load svn dump' "
+ svnadmin load -q '$rawsvnrepo' \
+ < '$TEST_DIRECTORY/t9160/branches.dump' &&
+ git svn init --minimize-url -R svnmerge \
+ -T trunk -b branches '$svnrepo' &&
+ git svn fetch --all
+ "
+
+test_expect_success 'propagate merge information' '
+ git config svn.pushmergeinfo yes &&
+ git checkout svnb1 &&
+ git merge --no-ff svnb2 &&
+ git svn dcommit
+ '
+
+test_expect_success 'check svn:mergeinfo' '
+ mergeinfo=$(svn_cmd propget svn:mergeinfo "$svnrepo"/branches/svnb1)
+ test "$mergeinfo" = "/branches/svnb2:3,8"
+ '
+
+test_expect_success 'merge another branch' '
+ git merge --no-ff svnb3 &&
+ git svn dcommit
+ '
+
+test_expect_success 'check primary parent mergeinfo respected' '
+ mergeinfo=$(svn_cmd propget svn:mergeinfo "$svnrepo"/branches/svnb1)
+ test "$mergeinfo" = "/branches/svnb2:3,8
+/branches/svnb3:4,9"
+ '
+
+test_expect_success 'merge existing merge' '
+ git merge --no-ff svnb4 &&
+ git svn dcommit
+ '
+
+test_expect_success "check both parents' mergeinfo respected" '
+ mergeinfo=$(svn_cmd propget svn:mergeinfo "$svnrepo"/branches/svnb1)
+ test "$mergeinfo" = "/branches/svnb2:3,8
+/branches/svnb3:4,9
+/branches/svnb4:5-6,10-12
+/branches/svnb5:6,11"
+ '
+
+test_expect_success 'make further commits to branch' '
+ git checkout svnb2 &&
+ touch newb2file &&
+ git add newb2file &&
+ git commit -m "later b2 commit" &&
+ touch newb2file-2 &&
+ git add newb2file-2 &&
+ git commit -m "later b2 commit 2" &&
+ git svn dcommit
+ '
+
+test_expect_success 'second forward merge' '
+ git checkout svnb1 &&
+ git merge --no-ff svnb2 &&
+ git svn dcommit
+ '
+
+test_expect_success 'check new mergeinfo added' '
+ mergeinfo=$(svn_cmd propget svn:mergeinfo "$svnrepo"/branches/svnb1)
+ test "$mergeinfo" = "/branches/svnb2:3,8,16-17
+/branches/svnb3:4,9
+/branches/svnb4:5-6,10-12
+/branches/svnb5:6,11"
+ '
+
+test_expect_success 'reintegration merge' '
+ git checkout svnb4 &&
+ git merge --no-ff svnb1 &&
+ git svn dcommit
+ '
+
+test_expect_success 'check reintegration mergeinfo' '
+ mergeinfo=$(svn_cmd propget svn:mergeinfo "$svnrepo"/branches/svnb4)
+ test "$mergeinfo" = "/branches/svnb1:2-4,7-9,13-18
+/branches/svnb2:3,8,16-17
+/branches/svnb3:4,9
+/branches/svnb4:5-6,10-12
+/branches/svnb5:6,11"
+ '
+
+test_expect_success 'dcommit a merge at the top of a stack' '
+ git checkout svnb1 &&
+ touch anotherfile &&
+ git add anotherfile &&
+ git commit -m "a commit" &&
+ git merge svnb4 &&
+ git svn dcommit
+ '
+
+test_done
diff --git a/t/t9160/branches.dump b/t/t9160/branches.dump
new file mode 100644
index 0000000..e61c3e7
--- /dev/null
+++ b/t/t9160/branches.dump
@@ -0,0 +1,374 @@
+SVN-fs-dump-format-version: 2
+
+UUID: 1ef08553-f2d1-45df-b38c-19af6b7c926d
+
+Revision-number: 0
+Prop-content-length: 56
+Content-length: 56
+
+K 8
+svn:date
+V 27
+2011-09-02T16:08:02.941384Z
+PROPS-END
+
+Revision-number: 1
+Prop-content-length: 114
+Content-length: 114
+
+K 7
+svn:log
+V 12
+Base commit
+
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:08:27.205062Z
+PROPS-END
+
+Node-path: branches
+Node-kind: dir
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+
+Node-path: trunk
+Node-kind: dir
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 2
+Prop-content-length: 121
+Content-length: 121
+
+K 7
+svn:log
+V 19
+Create branch svnb1
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:09:43.628137Z
+PROPS-END
+
+Node-path: branches/svnb1
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
+
+Revision-number: 3
+Prop-content-length: 121
+Content-length: 121
+
+K 7
+svn:log
+V 19
+Create branch svnb2
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:09:46.339930Z
+PROPS-END
+
+Node-path: branches/svnb2
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
+
+Revision-number: 4
+Prop-content-length: 121
+Content-length: 121
+
+K 7
+svn:log
+V 19
+Create branch svnb3
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:09:49.394515Z
+PROPS-END
+
+Node-path: branches/svnb3
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
+
+Revision-number: 5
+Prop-content-length: 121
+Content-length: 121
+
+K 7
+svn:log
+V 19
+Create branch svnb4
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:09:54.114607Z
+PROPS-END
+
+Node-path: branches/svnb4
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
+
+Revision-number: 6
+Prop-content-length: 121
+Content-length: 121
+
+K 7
+svn:log
+V 19
+Create branch svnb5
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:09:58.602623Z
+PROPS-END
+
+Node-path: branches/svnb5
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 1
+Node-copyfrom-path: trunk
+
+
+Revision-number: 7
+Prop-content-length: 110
+Content-length: 110
+
+K 7
+svn:log
+V 9
+b1 commit
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:10:20.292369Z
+PROPS-END
+
+Node-path: branches/svnb1/b1file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 0
+Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
+Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 8
+Prop-content-length: 110
+Content-length: 110
+
+K 7
+svn:log
+V 9
+b2 commit
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:10:38.429199Z
+PROPS-END
+
+Node-path: branches/svnb2/b2file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 0
+Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
+Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 9
+Prop-content-length: 110
+Content-length: 110
+
+K 7
+svn:log
+V 9
+b3 commit
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:10:52.843023Z
+PROPS-END
+
+Node-path: branches/svnb3/b3file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 0
+Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
+Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 10
+Prop-content-length: 110
+Content-length: 110
+
+K 7
+svn:log
+V 9
+b4 commit
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:11:17.489870Z
+PROPS-END
+
+Node-path: branches/svnb4/b4file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 0
+Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
+Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 11
+Prop-content-length: 110
+Content-length: 110
+
+K 7
+svn:log
+V 9
+b5 commit
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:11:32.277404Z
+PROPS-END
+
+Node-path: branches/svnb5/b5file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 0
+Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
+Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 12
+Prop-content-length: 192
+Content-length: 192
+
+K 7
+svn:log
+V 90
+Merge remote-tracking branch 'svnb5' into HEAD
+
+* svnb5:
+ b5 commit
+ Create branch svnb5
+K 10
+svn:author
+V 7
+bjacobs
+K 8
+svn:date
+V 27
+2011-09-02T16:11:54.274722Z
+PROPS-END
+
+Node-path: branches/svnb4
+Node-kind: dir
+Node-action: change
+Prop-content-length: 56
+Content-length: 56
+
+K 13
+svn:mergeinfo
+V 21
+/branches/svnb5:6,11
+
+PROPS-END
+
+
+Node-path: branches/svnb4/b5file
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 0
+Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
+Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
+Content-length: 10
+
+PROPS-END
+
+
--
1.7.6.1.5.g8ba83.dirty
^ permalink raw reply related
* Re: Git without morning coffee
From: Junio C Hamano @ 2011-09-07 17:35 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <7vehzs47we.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> git merge ":/Merge branch 'jk/generation-numbers' into pu"
>> fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
>> to a commit
>> # Huh?
>
> Interesting.
This is because 1c7b76b (Build in merge, 2008-07-07) grabs the name of the
commit to be merged using peel_to_type(), which was defined in 8177631
(expose a helper function peel_to_type()., 2007-12-24) in terms of
get_sha1_1(). It understands $commit~$n, $commit^$n and $ref@{$nth}, but
does not understand :/$str, $treeish:$path, and :$stage:$path.
^ permalink raw reply
* Re: [PATCH v2 2/5] sha1_file: remove a buggy value setting
From: wanghui @ 2011-09-07 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tali
In-Reply-To: <7vpqjdab76.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Wang Hui <Hui.Wang@windriver.com> writes:
>
>
>> From: Hui Wang <Hui.Wang@windriver.com>
>>
>> The ent->base[] is a character array, it has pfxlen characters from
>> position 0 to (pfxlen-1) to contain an alt object dir name, the
>> position pfxlen should be the string terminating character '\0' and
>> is deliberately set to '\0' at the previous code line. The position
>> (pfxlen+1) is given to ent->name.
>>
>
> Correct. Do you understand why?
>
> We temporarily NUL terminate the ent->base[] so that we can give it to
> is_directory() to see if that is a directory, but the invariants for a
> alternate_object_database instance after it is properly initialized by
> this function are to have:
>
> - the directory name followed by a slash in the base[] array;
> - the name pointer pointing at one byte beyond the slash;
> - name[2] filled with a slash; and
> - name[41] terminated with NUL.
>
> Later, has_loose_object_nonlocal() calls fill_sha1_path() with the name
> pointer to fill name[0..1, 3..40] with the hexadecimal representation of
> the object name, which would result in base[] array to have the pathname
> for a loose object found in that alternate. The same thing happens in
> open_sha1_file() to read from a loose object in an alternate.
>
> And you are breaking one of the above invariants by removing that slash
> after the directory name. These callers of fill_sha1_path() will see the
> directory name, your NUL, two hex, slash, and 38 hex in base[].
>
>
Understand now, thanks for your explanation.
> How would the code even work with your patch?
>
>
>
^ permalink raw reply
* Re: Git without morning coffee
From: Michael Witten @ 2011-09-07 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <7vehzs47we.fsf@alter.siamese.dyndns.org>
[Sorry for the repeat, Junio]
On Wed, Sep 7, 2011 at 16:46, Junio C Hamano <gitster@pobox.com> wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> git merge ":/Merge branch 'jk/generation-numbers' into pu"
>> fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
>> to a commit
>> # Huh?
>
> Interesting.
>
>> git merge $(git rev-parse ":/Merge branch 'jk/generation-numbers' into pu")
>> error: addinfo_cache failed for path 't/t7810-grep.sh'
>> Performing inexact rename detection: 100% (91476/91476), done.
>> error: addinfo_cache failed for path 't/t7810-grep.sh'
>
> Smells like another case where merge-recursive is looking at the work tree
> when it shouldn't inside an inner merge or something.
>
>> I mean, I'm merging a commit from origin/pu to origin/next when the
>> latter is basically contained in the former (except for some merge
>> commits).
>
> This falls into the "side note" category, but these days 'next' and 'pu'
> do not share any history beyond the tip of 'master'. Every time I update
> the 'pu' branch, it is rebuilt directly on top of 'master' from scratch by
> merging the topics in 'next' (and at this point I make sure its tree
> matches that of 'next') and then merging remaining topics on top of the
> result. A topic often goes through multiple iterations of fix-ups while in
> 'next', and these fix-ups result in multiple incremental merges of the
> same topic into 'next'; I do not want to see an incorrect merge when such
> a topic is merged in a single-step into 'master', and it is one way to
> ensure the health of the merge fixup machinery (including the rerere
> database) to attempt from-scratch-the-whole-topic-at-once merges and
> verify the result.
>
> The merge you attempted will have a lot of "the history leading to the
> current commit added/modified in a certain way and the history being
> merged did the same modification independently" kind of conflicts that
> should resolve to no-op.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I think it would be great if at some point you could write a detailed
tutorial of how you maintain git (using example topics, example patch
series and pull requests, and follow-along command sequences, etc.).
Most importantly, it would be nice to see an explicit description of
the maintenance properties you are trying to achieve with your
workflow.
^ permalink raw reply
* [PATCH v3 1/1] sha1_file: normalize alt_odb path before comparing and storing
From: Wang Hui @ 2011-09-07 10:37 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315391867-31277-1-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
When it needs to compare and add an alt object path to the
alt_odb_list, we normalize this path first since comparing normalized
path is easy to get correct result.
Use strbuf to replace some string operations, since it is cleaner and
safer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
sha1_file.c | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f7c3408..fa2484b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -248,27 +248,27 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
const char *objdir = get_object_directory();
struct alternate_object_database *ent;
struct alternate_object_database *alt;
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = len;
- int entlen = pfxlen + 43;
- int base_len = -1;
+ int pfxlen, entlen;
+ struct strbuf pathbuf = STRBUF_INIT;
if (!is_absolute_path(entry) && relative_base) {
- /* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
- entlen += base_len;
- pfxlen += base_len;
+ strbuf_addstr(&pathbuf, real_path(relative_base));
+ strbuf_addch(&pathbuf, '/');
}
- ent = xmalloc(sizeof(*ent) + entlen);
+ strbuf_add(&pathbuf, entry, len);
- if (!is_absolute_path(entry) && relative_base) {
- memcpy(ent->base, relative_base, base_len - 1);
- ent->base[base_len - 1] = '/';
- memcpy(ent->base + base_len, entry, len);
- }
- else
- memcpy(ent->base, entry, pfxlen);
+ normalize_path_copy(pathbuf.buf, pathbuf.buf);
+
+ pfxlen = strlen(pathbuf.buf);
+
+ /* Drop the last '/' from path can make memcmp more accurate */
+ if (pathbuf.buf[pfxlen-1] == '/')
+ pfxlen -= 1;
+
+ entlen = pfxlen + 43; /* '/' + 2 hex + '/' + 38 hex + NUL */
+ ent = xmalloc(sizeof(*ent) + entlen);
+ memcpy(ent->base, pathbuf.buf, pfxlen);
+ strbuf_release(&pathbuf);
ent->name = ent->base + pfxlen + 1;
ent->base[pfxlen + 3] = '/';
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH v2 1/5] sha1_file cleanup: remove redundant variable check
From: wanghui @ 2011-09-07 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tali
In-Reply-To: <7vaaaha9p2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Wang Hui <Hui.Wang@windriver.com> writes:
>
>
>> From: Hui Wang <Hui.Wang@windriver.com>
>>
>> This variable check is always true, so it is redundant and need to be
>> removed.
>>
>> We can't remove the init value for this variable, since removing
>> it will introduce building warning:
>> 'base_len' may be used uninitialized in this function.
>>
>
> If we are into cleaning things up, we should instead notice and say "yuck"
> to the repeated "is entry is absolute and relative base is given" check.
>
> Wouldn't something like this makes things easier to follow and also avoids
> the "when does the path normalized and made absolute" issue?
>
> Completely untested and I may have off-by-one errors and such, but I think
> you would get the idea...
>
>
Yes, i got the idea, and some errors are pointed out below. I will
prepare a V3 patch basing on it.
> sha1_file.c | 29 ++++++++++++-----------------
> 1 files changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index e002056..26aa3be 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -248,27 +248,22 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
> const char *objdir = get_object_directory();
> struct alternate_object_database *ent;
> struct alternate_object_database *alt;
> - /* 43 = 40-byte + 2 '/' + terminating NUL */
> - int pfxlen = len;
> - int entlen = pfxlen + 43;
> - int base_len = -1;
> + int pfxlen, entlen;
> + struct strbuf pathbuf = STRBUF_INIT;
>
> if (!is_absolute_path(entry) && relative_base) {
> - /* Relative alt-odb */
> - if (base_len < 0)
> - base_len = strlen(relative_base) + 1;
> - entlen += base_len;
> - pfxlen += base_len;
> + strbuf_addstr(&pathbuf, relative_base);
>
s/relative_base/real_path(relative_base)/ is better, since
normalize_path_copy is not good at handle relative path. e.g. ".
./objects/../../test2/objects" will be normalized to "objects"
> + strbuf_addch(&pathbuf, '/');
> }
> - ent = xmalloc(sizeof(*ent) + entlen);
> + strbuf_add(&pathbuf, entry, len);
> + normalize_path_copy(pathbuf.buf, pathbuf.buf);
>
if pathbuf.buf[strlen(pathbuf.buf)] is '/', remove it. this can avoid to
get a wrong result when comparing "/a/b" with "/a/b/".
> + strbuf_setlen(&pathbuf, strlen(pathbuf.buf));
>
above line can be removed, since we will release pathbuf soon.
>
> - if (!is_absolute_path(entry) && relative_base) {
> - memcpy(ent->base, relative_base, base_len - 1);
> - ent->base[base_len - 1] = '/';
> - memcpy(ent->base + base_len, entry, len);
> - }
> - else
> - memcpy(ent->base, entry, pfxlen);
> + pfxlen = pathbuf.len;
> + entlen = pfxlen + 43; /* '/' + 2 hex + '/' + 38 hex + NUL */
> + ent = xmalloc(sizeof(*ent) + entlen);
> + memcpy(ent->base, pathbuf.buf, pfxlen);
> + strbuf_release(&pathbuf);
>
> ent->name = ent->base + pfxlen + 1;
> ent->base[pfxlen + 3] = '/';
>
>
^ permalink raw reply
* [PATCH v3 0/1] sha1_file: normalize alt_odb path before comparing and storing
From: Wang Hui @ 2011-09-07 10:37 UTC (permalink / raw)
To: gitster, git, tali
Hi Junio & Martin,
In the V3, i prepared a patch basing on Junio's suggestion. If this patch can
pass review and be merged to upstream. What about the last two patches in the
V2 (remove relative alternates only possible at current repos limitation), do
you think it is safe to pick up these two patches?
Hui Wang (1):
sha1_file: normalize alt_odb path before comparing and storing
sha1_file.c | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Kyle Neath @ 2011-09-07 8:11 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <CAGdFq_h3KNuGuhhY2Zv-dHWqAY4Wq3HHBGh2f53rWzDT9PzSgQ@mail.gmail.com>
On Wed, Sep 7, 2011 at 12:46 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Junio mentioned in WC that he wants to see some feedback on it's
> usage, perhaps that you can help provide this by providing a git
> patched with this functionality to some of your users and see how they
> respond?
Perhaps this is where things get complicated. Due to the nature of the people
I'm discussing (people afraid of SSH keys), getting them to run a custom
version of git is pretty far out of the question. Peff alluded to this in his
reply.
I think the best evidence I can provide is in context of GitHub for Mac.
GitHub for Mac defaults to Smart HTTP, with the credentials cached in OSX's
Keychain. Effectively, it functions as a patched git with credential caching.
Two months after shipping, we have around 20,000 people that use the
application regularly. In that time, we've gotten a ton of positive feedback.
So there is a great number of people interested in a git client that uses
Smart HTTP. One of the bigger complaints we get is that people constantly have
to enter their username & password if they choose to drop to the command line.
Of course, this is all fuzzy data since it's not really comparable with git
core. But it's the only data I have.
Then again, perhaps the fact that we spent development time hacking around
git's limitation is a data point in itself. Git GUI developers are spending
development time to fill a hole in git core.
Kyle
^ permalink raw reply
* Add interactive patch menu help scrolled away if hunk is long
From: Sergio Callegari @ 2011-09-07 12:43 UTC (permalink / raw)
To: git
Hi,
when using git add -i, selecting the patch functionality, git shows the
Stage this hunk [y,n,q,a,d,/,K,j,J,g,s,e,?]?
question for each hunk.
Apparently the '?' entry meant to show help is not very useful when the hunk is
long since the help is scrolled away as the hunk is reprinted.
Probably it would be better not to reprint the hunk when '?' is selected.
Sergio
^ permalink raw reply
* Re: [ANNOUNCE] GitTogether 2011 - Oct 24th/25th
From: Scott Chacon @ 2011-09-07 17:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJu48DiVUDexuWJpVgq__zVTfO1Xz=AgfOz6wws00b2EaQ@mail.gmail.com>
Hey,
On Mon, Sep 5, 2011 at 12:56 PM, Shawn Pearce <spearce@spearce.org> wrote:
> Google is once again hosting a 2 day user/developer conference for Git
> users and developers to get together, share experiences, and hack on
> interesting features. This event will be held October 24th and 25th at
> Google's headquarters in Mountain View, CA.
>
> More details along with sign-up (as space is limited) can be found on the wiki:
>
> https://git.wiki.kernel.org/index.php/GitTogether11
It's been like 2 days and we're already overflowing. I've also
already heard people say they didn't sign up because it was full.
This is unacceptable. I want to drink with all of you guys.
Shawn, if you can't get a bigger venue at Google, we'll rent a meeting
space either at the hotel that most of the mentors are staying at or a
nearby one. I'm looking into spaces that will accomodate closer to 50
people and will serve us beer. :)
So, everybody that wants to come just sign up and we'll make sure
there is room for everyone. Also, if any regular Git contributors
need help with flights or lodging, please let me know and we'll see
what we can do to help.
Thanks,
Scott
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Sverre Rabbelier @ 2011-09-07 7:46 UTC (permalink / raw)
To: Kyle Neath, Junio C Hamano; +Cc: git
In-Reply-To: <CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com>
Heya,
On Wed, Sep 7, 2011 at 07:33, Kyle Neath <kneath@gmail.com> wrote:
> I'll summarize with a graph of my opinion of where git's potential for
> adoption lies:
>
> ------------------------------------------------------------------------------
> OPPORTUNITY FOR GIT ADOPTION ACCORDING TO KYLE NEATH
>
> Caching of http credentials
> |
> [=====================================================================||=====]
> |
> Everything else in the universe
>
> ------------------------------------------------------------------------------
I, personally, find the graph very convincing :).
Junio mentioned in WC that he wants to see some feedback on it's
usage, perhaps that you can help provide this by providing a git
patched with this functionality to some of your users and see how they
respond?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] date.c: Support iso8601 timezone formats
From: Junio C Hamano @ 2011-09-07 17:00 UTC (permalink / raw)
To: Haitao Li; +Cc: git, Jeff King
In-Reply-To: <1315374407-30828-1-git-send-email-lihaitao@gmail.com>
Haitao Li <lihaitao@gmail.com> writes:
> diff --git a/date.c b/date.c
> index 896fbb4..f970ea8 100644
> --- a/date.c
> +++ b/date.c
> @@ -556,15 +556,35 @@ static int match_tz(const char *date, int *offp)
> int min, hour;
> int n = end - date - 1;
>
> - min = offset % 100;
> - hour = offset / 100;
> + /*
> + * ISO8601:2004(E) allows time zone designator been separated
> + * by a clone in the extended format
> + */
> + if (*end == ':') {
> + if (isdigit(end[1])) {
> + hour = offset;
> + min = strtoul(end+1, &end, 10);
> + } else {
> + /* Mark as invalid */
> + n = -1;
> + }
> + } else {
> + /* Only hours specified */
That comment belongs to inside the following if() {...}.
> + if (n == 1 || n == 2) {
... i.e. here.
> + hour = offset;
> + min = 0;
> + } else {
> + hour = offset / 100;
> + min = offset % 100;
> + }
> + }
>
> /*
> + * Don't accept any random crap.. We might want to check that
> + * the minutes are divisible by 15 or something too. (Offset of
> + * Kathmandu, Nepal is UTC+5:45)
> */
> - if (min < 60 && n > 2) {
> + if (n > 0 && min < 60 && hour < 25) {
What is this "hour < 25" about? Aren't we talking about the UTC offset
value that come after the [-+] sign?
I do not mind adding a new check, but I do mind if it adds a check with
not much value. Even at Pacific/Kiritimati, the offset is 14; the new
check seems a bit too lenient.
> offset = hour*60+min;
> if (*date == '-')
> offset = -offset;
> diff --git a/t/t0006-date.sh b/t/t0006-date.sh
> index f87abb5..5235b7a 100755
> --- a/t/t0006-date.sh
> +++ b/t/t0006-date.sh
> @@ -40,6 +40,11 @@ check_parse 2008-02 bad
> check_parse 2008-02-14 bad
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
> +check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
> +check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
>
> check_approxidate() {
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.6.2
From: Sverre Rabbelier @ 2011-09-07 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vsjo84mx3.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Sep 7, 2011 at 13:22, Junio C Hamano <gitster@pobox.com> wrote:
>> That's interesting, how did revert a merge commit?
>
> Does "git revert --help" lack the description?
It warns that "As a result, later merges will only bring in tree
changes introduced by commits that are not ancestors of the previously
reverted merge." How would you later re-merge the series when the
problems it has are fixed though?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Michael J Gruber @ 2011-09-07 13:19 UTC (permalink / raw)
To: Francis Moreau; +Cc: Junio C Hamano, git
In-Reply-To: <CAC9WiBjrfJeJ854dkJMPwRSwuujRsYLnAd7QX7C_oU8_FdOvQA@mail.gmail.com>
Francis Moreau venit, vidit, dixit 06.09.2011 21:28:
> Hello Junio,
>
> On Tue, Sep 6, 2011 at 7:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Our assumption has always been that it is a notable event that a patch
>> that does not get filtered with internal "git cherry" (which culls patches
>> that are textually identical to those that are already merged to the
>> history you are rebasing onto) becomes totally unneeded and is safe to ask
>> for human confirmation in the form of "rebase --skip" than to ignore it
>> and give potentially incorrect result silently.
>
> Ok then I think this "git cherry" filtering is not working in my case
> since it seems to me that commit that I cherry-picked are not
> filtered, please see below.
>
>>
>> Obviously you do not find it a notable event for some reason. We would
>> need to understand why, and if the reason is sensible, it _might_ make
>> sense to allow a user to say "git rebase --ignore-merged" or something
>> when starting the rebase.
>
> My use case is the following: I'm maintaining a branch from an
> upstream project (the kernel one). While the upstream project follows
> its development cycle (including some fixes), my branch is stuck. I
> sometime want to includes (or rather backport) some commits that
> happened later in the development cycle. To do that I use "git
> cherry-pick".
>
> After some period, I'm allowed to rebase to a more recent commit from
> the upstream project and this rebase 'cancel' the previous 'git
> cherry-pick' I did. But for some reasons, git telling me "nothing
> added to commit ...", which is expected in my case, well I think,
> hence my question.
>
> Thanks.
Unless you had to resolve a conflict when cherry-picking, the picked
commit should be patch-equivalent to the original one, and thus dropped
by rebase automatically.
How do the two patches compare:
git show $picked >a
git show $original >b
git patch-id <a
git patch-id <b
git diff --no-index a b
Michael
^ permalink raw reply
* [PATCH] git-update-ref documentation: --no-deref can be used together with -d
From: Bernhard R. Link @ 2011-09-07 16:06 UTC (permalink / raw)
To: git
---
Documentation/git-update-ref.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index d377a35..5da3691 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -8,7 +8,7 @@ git-update-ref - Update the object name stored in a ref safely
SYNOPSIS
--------
[verse]
-'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
+'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<oldvalue>] | <ref> <newvalue> [<oldvalue>])
DESCRIPTION
-----------
--
1.7.2.5
^ permalink raw reply related
* Re: Git without morning coffee
From: Junio C Hamano @ 2011-09-07 16:46 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E6721E3.7000207@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> git merge ":/Merge branch 'jk/generation-numbers' into pu"
> fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
> to a commit
> # Huh?
Interesting.
> git merge $(git rev-parse ":/Merge branch 'jk/generation-numbers' into pu")
> error: addinfo_cache failed for path 't/t7810-grep.sh'
> Performing inexact rename detection: 100% (91476/91476), done.
> error: addinfo_cache failed for path 't/t7810-grep.sh'
Smells like another case where merge-recursive is looking at the work tree
when it shouldn't inside an inner merge or something.
> I mean, I'm merging a commit from origin/pu to origin/next when the
> latter is basically contained in the former (except for some merge
> commits).
This falls into the "side note" category, but these days 'next' and 'pu'
do not share any history beyond the tip of 'master'. Every time I update
the 'pu' branch, it is rebuilt directly on top of 'master' from scratch by
merging the topics in 'next' (and at this point I make sure its tree
matches that of 'next') and then merging remaining topics on top of the
result. A topic often goes through multiple iterations of fix-ups while in
'next', and these fix-ups result in multiple incremental merges of the
same topic into 'next'; I do not want to see an incorrect merge when such
a topic is merged in a single-step into 'master', and it is one way to
ensure the health of the merge fixup machinery (including the rerere
database) to attempt from-scratch-the-whole-topic-at-once merges and
verify the result.
The merge you attempted will have a lot of "the history leading to the
current commit added/modified in a certain way and the history being
merged did the same modification independently" kind of conflicts that
should resolve to no-op.
^ permalink raw reply
* Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo
From: Bryan Jacobs @ 2011-09-07 14:14 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20110906205750.GB12574@dcvr.yhbt.net>
On Tue, 6 Sep 2011 13:57:50 -0700
Eric Wong <normalperson@yhbt.net> wrote:
> Bryan Jacobs <bjacobs@woti.com> wrote:
> > +sub split_merge_info_range {
> > + my ($range) = @_;
> > + if ($range =~ /(\d+)-(\d+)/o) {
>
> No need for "/o" in regexps unless you have a (constant) variable
> expansion in there.
Okay, I'll take that out. I got into the habit of putting "optimize" on
all regexes without an explicitly dynamic variable on some earlier Perl
version.
> > +sub merge_commit_fail {
> > + my ($gs, $linear_refs, $d) = @_;
> > + #while (1) {
> > + # my $cs = shift @$linear_refs or last;
> > + # command_noisy(qw/cherry-pick/, $cs);
> > + #}
> > + #command_noisy(qw/cherry-pick -m/, '1', $d);
>
> Huh? If there's commented-out code, it must be explained or removed.
I think I did explain that in my earlier comments. I'm still not happy
with the recovery-from-aborted-commit-series handling. That commented
bit was my attempt.
The best suggestion so far is to prescan the commits to fail-fast. I
will do that in the next revision of the patch, just give me some time
to put it together.
> > + fatal "Aborted after failed dcommit of merge revision";
> > +}
>
> > +++ b/t/t9160-git-svn-mergeinfo-push.sh
> > @@ -0,0 +1,97 @@
> > +#!/bin/sh
> > +#
> > +# Copyright (c) 2007, 2009 Sam Vilain
>
> That should be: "Copyright (c) 2011 Brian Jacobs", correct?
Well, the file was copied from one bearing the Vilain copyright bit.
I'm not sure I entirely understand why it matters who holds the
individual copyrights if you have a collective license which is going to
be changed, but I can't just stick my own name on derived work - as the
setup code for that unit is.
> > +test_expect_success 'check svn:mergeinfo' '
> > + mergeinfo=$(svn_cmd propget svn:mergeinfo
> > "$svnrepo"/branches/svnb1)
> > + echo "$mergeinfo"
>
> No need to echo unless you're debugging a test, right?
>
Correct, leftover test-debugging cruft, will remove.
I will submit another revision shortly.
Bryan Jacobs
^ permalink raw reply
* [PATCH] RelNotes/1.7.7: minor fixes
From: Michael J Gruber @ 2011-09-07 11:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/RelNotes/1.7.7.txt | 52 +++++++++++++++++++-------------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/Documentation/RelNotes/1.7.7.txt b/Documentation/RelNotes/1.7.7.txt
index d819956..6e83082 100644
--- a/Documentation/RelNotes/1.7.7.txt
+++ b/Documentation/RelNotes/1.7.7.txt
@@ -8,7 +8,7 @@ Updates since v1.7.6
* Interix, Cygwin and Minix ports got updated.
- * Various updates git-p4 (in contrib/), fast-import, and git-svn.
+ * Various updates to git-p4 (in contrib/), fast-import, and git-svn.
* Gitweb learned to read from /etc/gitweb-common.conf when it exists,
before reading from gitweb_config.perl or from /etc/gitweb.conf
@@ -20,7 +20,7 @@ Updates since v1.7.6
platforms with 64-bit long, which has been corrected.
* Git now recognizes loose objects written by other implementations that
- uses non-standard window size for zlib deflation (e.g. Agit running on
+ use a non-standard window size for zlib deflation (e.g. Agit running on
Android with 4kb window). We used to reject anything that was not
deflated with 32kb window.
@@ -28,59 +28,59 @@ Updates since v1.7.6
been improved, especially when a command that is not built-in was
involved.
- * "git am" learned to pass "--exclude=<path>" option through to underlying
+ * "git am" learned to pass the "--exclude=<path>" option through to underlying
"git apply".
- * You can now feed many empty lines before feeding a mbox file to
+ * You can now feed many empty lines before feeding an mbox file to
"git am".
* "git archive" can be told to pass the output to gzip compression and
produce "archive.tar.gz".
- * "git bisect" can be used in a bare repository (provided if the test
+ * "git bisect" can be used in a bare repository (provided that the test
you perform per each iteration does not need a working tree, of
course).
* The length of abbreviated object names in "git branch -v" output
- now honors core.abbrev configuration variable.
+ now honors the core.abbrev configuration variable.
* "git check-attr" can take relative paths from the command line.
- * "git check-attr" learned "--all" option to list the attributes for a
+ * "git check-attr" learned an "--all" option to list the attributes for a
given path.
* "git checkout" (both the code to update the files upon checking out a
- different branch, the code to checkout specific set of files) learned
+ different branch and the code to checkout a specific set of files) learned
to stream the data from object store when possible, without having to
- read the entire contents of a file in memory first. An earlier round
+ read the entire contents of a file into memory first. An earlier round
of this code that is not in any released version had a large leak but
now it has been plugged.
- * "git clone" can now take "--config key=value" option to set the
+ * "git clone" can now take a "--config key=value" option to set the
repository configuration options that affect the initial checkout.
* "git commit <paths>..." now lets you feed relative pathspecs that
- refer outside your current subdirectory.
+ refer to outside your current subdirectory.
- * "git diff --stat" learned --stat-count option to limit the output of
- diffstat report.
+ * "git diff --stat" learned a --stat-count option to limit the output of
+ a diffstat report.
- * "git diff" learned "--histogram" option, to use a different diff
+ * "git diff" learned a "--histogram" option to use a different diff
generation machinery stolen from jgit, which might give better
performance.
- * "git diff" had a wierd worst case behaviour that can be triggered
+ * "git diff" had a weird worst case behaviour that can be triggered
when comparing files with potentially many places that could match.
* "git fetch", "git push" and friends no longer show connection
- errors for addresses that couldn't be connected when at least one
+ errors for addresses that couldn't be connected to when at least one
address succeeds (this is arguably a regression but a deliberate
one).
- * "git grep" learned --break and --heading options, to let users mimic
- output format of "ack".
+ * "git grep" learned "--break" and "--heading" options, to let users mimic
+ the output format of "ack".
- * "git grep" learned "-W" option that shows wider context using the same
+ * "git grep" learned a "-W" option that shows wider context using the same
logic used by "git diff" to determine the hunk header.
* Invoking the low-level "git http-fetch" without "-a" option (which
@@ -91,25 +91,25 @@ Updates since v1.7.6
highlight grafted and replaced commits.
* "git rebase master topci" no longer spews usage hints after giving
- "fatal: no such branch: topci" error message.
+ the "fatal: no such branch: topci" error message.
* The recursive merge strategy implementation got a fairly large
- fixes for many corner cases that may rarely happen in real world
+ fix for many corner cases that may rarely happen in real world
projects (it has been verified that none of the 16000+ merges in
the Linux kernel history back to v2.6.12 is affected with the
corner case bugs this update fixes).
- * "git stash" learned --include-untracked option.
+ * "git stash" learned an "--include-untracked option".
* "git submodule update" used to stop at the first error updating a
submodule; it now goes on to update other submodules that can be
updated, and reports the ones with errors at the end.
- * "git push" can be told with --recurse-submodules=check option to
+ * "git push" can be told with the "--recurse-submodules=check" option to
refuse pushing of the supermodule, if any of its submodules'
commits hasn't been pushed out to their remotes.
- * "git upload-pack" and "git receive-pack" learned to pretend only a
+ * "git upload-pack" and "git receive-pack" learned to pretend that only a
subset of the refs exist in a repository. This may help a site to
put many tiny repositories into one repository (this would not be
useful for larger repositories as repacking would be problematic).
@@ -118,7 +118,7 @@ Updates since v1.7.6
that is more efficient in reading objects in packfiles.
* test scripts for gitweb tried to run even when CGI-related perl modules
- are not installed; it now exits early when they are unavailable.
+ are not installed; they now exit early when the latter are unavailable.
Also contains various documentation updates and minor miscellaneous
changes.
@@ -127,7 +127,7 @@ changes.
Fixes since v1.7.6
------------------
-Unless otherwise noted, all the fixes in 1.7.6.X maintenance track are
+Unless otherwise noted, all fixes in the 1.7.6.X maintenance track are
included in this release.
* The error reporting logic of "git am" when the command is fed a file
--
1.7.7.rc0.438.gcfb82
^ permalink raw reply related
* Re: git-rebase skips automatically no more needed commits
From: Junio C Hamano @ 2011-09-07 16:29 UTC (permalink / raw)
To: Francis Moreau; +Cc: Michael J Gruber, git
In-Reply-To: <CAC9WiBi_bkLNJZckq2fr3eb6ie+KVfauE_PyA3GcaW5Ga-isFw@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
> If I start the rebase process with : "git rebase -i -p master foo"
> then the filtering is happening. Here 'foo' has been created with
> v2.6.39 tag as start point and contains some patches cherry-picked
> from the upstream.
>
> However if I call git-rebase this way: "git rebase -i -p --onto master
> v2.6.39 foo", then it seems that no filtering is done.
>
> Is that expected ?
Because "rebase --onto A B C" has to be usable when commit A does not have
any ancestry relationship with the history between B and C, I wouldn't be
surprised if the command does not look at commits on the history that lead
to A that _might_ be related to the ones between B and C. It does not know
how far to dig from A and stop, and obviously you do not want to dig down
to the beginning of the history. "rebase A B" on the other hand can safely
stop digging the history back from A down to where the history leading to
B forked (i.e. merge base between A and B).
I do not know if "expected" is the right adjective; understandable---yes,
unsurprised---yes, justifiable--- I dunno.
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Michael J Gruber @ 2011-09-07 12:56 UTC (permalink / raw)
To: Kyle Neath; +Cc: git
In-Reply-To: <CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com>
Kyle Neath venit, vidit, dixit 07.09.2011 07:33:
> Earlier today, Scott Chacon alerted me to this email thread:
> http://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I
> am not sure how to properly reference this email or reply to it since I have
> not been subscribed until today).
>
>> * jk/http-auth-keyring (2011-08-03) 13 commits
>> (merged to 'next' on 2011-08-03 at b06e80e)
>> + credentials: add "getpass" helper
>> + credentials: add "store" helper
>> + credentials: add "cache" helper
>> + docs: end-user documentation for the credential subsystem
>> + http: use hostname in credential description
>> + allow the user to configure credential helpers
>> + look for credentials in config before prompting
>> + http: use credential API to get passwords
>> + introduce credentials API
>> + http: retry authentication failures for all http requests
>> + remote-curl: don't retry auth failures with dumb protocol
>> + improve httpd auth tests
>> + url: decode buffers that are not NUL-terminated
>>
>> Looked mostly reasonable except for the limitation that it is not clear
>> how to deal with a site at which a user needs to use different passwords
>> for different repositories. Will keep it in "next" at least for one cycle,
>> until we start hearing real-world success reports on the list.
>>
>> Not urgent; will not be in 1.7.7.
>
> This is very disheartening to hear. Of all the minor changes, bugs, and
> potential features, I believe that http credential caching is the absolute
> most important thing that git core can do to promote adoption. I've believed
> this for more than a year now and I'm incredibly disappointed that it's being
> shelved for yet another release.
>
> Over the past two years as a designer for GitHub, I've answered ~thousands of
> support requests and talked face to face with ~thousands of developers of
> varying git skill levels. Once a month our company does online git training
> for newbies - https://github.com/training/online and I've had many discussions
> about newcomer's struggles with Matthew McCullough and Scott Chacon.
> Previously, I worked at ENTP where I helped polish the very popular "Git for
> Designers" guide http://hoth.entp.com/output/git_for_designers.html based on
> feedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at
> people less familiar with the command line.
So, it's been a year or more that you've been aware of the importance of
this issue (from your/github's perspective), and we hear about it now,
at the end of the rc phase. I don't know whether jk/http-auth-keyring
has been done on github payroll or during spare time. But as you can
see, all that is missing is real-world success reports, along with the
single-user-multiple-passwords issue which is probably answered best
from the real-world perspective (how common is it, do we even need to
address it now). So, given the importance this has for you and the
company, you sure can help out with what is still left to do, can you?
But note that the credential api is only as good a solution as the
helpers. Do we really want all users to employ credential-store because
it is "much simpler than ssh"? Deploying what we have now and advocating
it as a solution for the ssh-challenged (which will happen whether we,
you or someone else advocates it) could easily mean telling people to
store their credentials unencrypted. The slash-dot story will be "git
security hole", "git stores passwords unencrypted" and so on. And I
don't care as much about the PR as about the users whom we'd be serving
badly.
So, for the ssh-challenged, we really should make sure that secure
helpers are in their hand when the credential api hits a released
version (or revert the insecure store helper). There's a KDE attempt on
the list. Gnome, Win, Mac helpers anyone? Win version of the cache helper?
Michael
^ permalink raw reply
* Re: Issue fetching tags error: unable to find eb03b... ; git fsck shows no problem...
From: James Blackburn @ 2011-09-07 16:30 UTC (permalink / raw)
To: git
In-Reply-To: <CACyv8dcTi0pG_GPvxD1zoTf6iRG81KbaY43FA-pbxYJz2UVJcQ@mail.gmail.com>
I can get the fetch to work, by removing refs/original in the source repo:
bash:jamesb:xl-cbga-20:32942> git fetch --tags old
remote: Counting objects: 35469, done.
remote: Compressing objects: 100% (11562/11562), done.
remote: Total 33792 (delta 18883), reused 30509 (delta 16197)
Receiving objects: 100% (33792/33792), 28.10 MiB | 8.28 MiB/s, done.
Resolving deltas: 100% (18883/18883), completed with 443 local objects.
error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
bash:jamesb:xl-cbga-20:32943> rm -rf ../old_tagsX/.git/refs/original/
bash:jamesb:xl-cbga-20:32944> git fetch --tags old
remote: Counting objects: 1404, done.
remote: Compressing objects: 100% (570/570), done.
remote: Total 1014 (delta 480), reused 659 (delta 233)
Receiving objects: 100% (1014/1014), 1.66 MiB, done.
Resolving deltas: 100% (480/480), completed with 195 local objects.
From ../old_tagsX
* [new tag] 3.2.0-5 -> 3.2.0-5
...
bash:jamesb:xl-cbga-20:32945> git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
Date: Tue Oct 10 09:44:47 2006 +0000
This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
...
Note that the object was present all along!
(In old_repo I had done: git filter-branch --prune-empty -- --all)
I have a backup of the repo, and this is repeatable for me, is there
an odd interaction between fetch and refs/original?
Cheers,
James
On 7 September 2011 17:14, James Blackburn <jamesblackburn@gmail.com> wrote:
> Hi All,
>
> I've got an error I can't seem to resolve. Fsck reports both my
> repositories are OK, but git fetch --tags tells me it can't find an
> object.
>
> bash:jamesb:xl-cbga-20:32867> git --version
> git version 1.7.6
> bash:jamesb:xl-cbga-20:32864> git remote add old_tags ../old_tags/
> bash:jamesb:xl-cbga-20:32865> git fetch old_tags
> From ../old_tags
> * [new branch] master -> old_tags/master
> ...
> bash:jamesb:xl-cbga-20:32866> git fetch --tags old_tags
> remote: Counting objects: 33613, done.
> remote: Compressing objects: 100% (11778/11778), done.
> remote: Total 33529 (delta 18473), reused 30013 (delta 15779)
> Receiving objects: 100% (33529/33529), 28.59 MiB | 8.06 MiB/s, done.
> Resolving deltas: 100% (18473/18473), completed with 17 local objects.
> error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
> fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
>
> git fsck --full shows no errors in old_tags.
> git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f in old_tags seems to work:
>
> commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
> Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
> Date: Tue Oct 10 09:44:47 2006 +0000
>
> This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
>
> git-svn-id: svn://eng-cbga-2/tools/eclipse/tags/releases/3_2_0-5@39
> e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff
>
> diff --git a/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/allclasses-frame.html
> b/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/
> allclasses-frame.html
> ...
>
>
> Any ideas how to resolve this?
>
> Cheers,
> James
>
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.6.2
From: Junio C Hamano @ 2011-09-07 11:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <CAGdFq_gF8Uz_JTEUfb46kVii=Y0CwzCpOp5H81+HT8y=1PPUTQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> That's interesting, how did revert a merge commit?
Does "git revert --help" lack the description?
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Junio C Hamano @ 2011-09-07 11:21 UTC (permalink / raw)
To: Kyle Neath; +Cc: git
In-Reply-To: <CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com>
Kyle Neath <kneath@gmail.com> writes:
>> * jk/http-auth-keyring (2011-08-03) 13 commits
>> ...
>>
>> Looked mostly reasonable except for the limitation that it is not clear
>> how to deal with a site at which a user needs to use different passwords
>> for different repositories. Will keep it in "next" at least for one cycle,
>> until we start hearing real-world success reports on the list.
>>
>> Not urgent; will not be in 1.7.7.
>
> This is very disheartening to hear. Of all the minor changes, bugs, and
> potential features, I believe that http credential caching is the absolute
> most important thing that git core can do to promote adoption. I've believed
> this for more than a year now and I'm incredibly disappointed that it's being
> shelved for yet another release.
You are misreading the message utterly wrong that it is not even funny.
If this were a new, insignificant, and obscure feature in a piece of
software with mere 20k users, it may be OK to release a new version with
the feature in an uncooked shape. The feature may turn out to work only in
a very limited scope but not general enough to accomodate other needs you
did not anticipate, and your next version may have to fix it in a backward
incompatible way, forcing existing users to unlearn what the initial
uncooked design and implementation gave them, but by definition such an
insignificant and obscure new feature in a system with a small userbase
wouldn't have been used by too many people by the time you have to fix it,
and the extent of the damage is limited.
Git is not that piece of software with only 20k users, and a lot more
importantly, credential caching API is not a feature in an insignificant
and obscure corner of the user experience. We have to have at least a warm
fuzzy feeling that the API is right from the start so the plug-ins people
write for our initial version and the data its users will accumulate with
it will not go to waste by hastily releasing a version with an uncooked
design and implementation.
"Not urgent" is not "Not important". Quite the contrary, it is important
enough that we cannot afford to be hasty.
See http://thread.gmane.org/gmane.comp.version-control.git/180245 for an
example of how a discussion can be done to help us get closer to the warm
fuzzy feeling of getting the API right in a more mature manner. Don't feel
too bad if you become ashamed of the rant you wrote contrasting with that
exchange. It is a sign that you are learning.
> Then again, perhaps the fact that we spent development time hacking around
> git's limitation is a data point in itself. Git GUI developers are spending
> development time to fill a hole in git core.
Welcome to open source. Do not expect others to scratch every itch of your
niche. Think of it as an opportunity granted to you to make a difference,
not as a roadblock somebody else threw at you because they hate you.
Be thankful, not whiny.
Be good.
Have fun.
^ permalink raw reply
* Issue fetching tags error: unable to find eb03b... ; git fsck shows no problem...
From: James Blackburn @ 2011-09-07 16:14 UTC (permalink / raw)
To: git
Hi All,
I've got an error I can't seem to resolve. Fsck reports both my
repositories are OK, but git fetch --tags tells me it can't find an
object.
bash:jamesb:xl-cbga-20:32867> git --version
git version 1.7.6
bash:jamesb:xl-cbga-20:32864> git remote add old_tags ../old_tags/
bash:jamesb:xl-cbga-20:32865> git fetch old_tags
From ../old_tags
* [new branch] master -> old_tags/master
...
bash:jamesb:xl-cbga-20:32866> git fetch --tags old_tags
remote: Counting objects: 33613, done.
remote: Compressing objects: 100% (11778/11778), done.
remote: Total 33529 (delta 18473), reused 30013 (delta 15779)
Receiving objects: 100% (33529/33529), 28.59 MiB | 8.06 MiB/s, done.
Resolving deltas: 100% (18473/18473), completed with 17 local objects.
error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
git fsck --full shows no errors in old_tags.
git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f in old_tags seems to work:
commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
Date: Tue Oct 10 09:44:47 2006 +0000
This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
git-svn-id: svn://eng-cbga-2/tools/eclipse/tags/releases/3_2_0-5@39
e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff
diff --git a/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/allclasses-frame.html
b/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/
allclasses-frame.html
...
Any ideas how to resolve this?
Cheers,
James
^ 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