* Re: Regression: git-svn clone failure
From: Junio C Hamano @ 2009-12-22 21:38 UTC (permalink / raw)
To: Sam Vilain; +Cc: Andrew Myrick, Eric Wong, git
In-Reply-To: <1261516416.23944.44.camel@denix>
Sam Vilain <sam@vilain.net> writes:
> With git, merge parent relationships imply (conceptually, anyway) that
> all of the changes reachable from that branch are included in the
> commit. If someone is doing cherry-picking, then they are specifically
> excluding some commits, so adding a merge parent to that branch isn't
> right. This is what the warning is saying. It's happening every commit
> because that section of code doesn't know whether a mergeinfo record is
> new or not.
> ...
> Subject: [PATCH] git-svn: consider 90% of a branch cherry picked to be a merge
>
> Be slightly fuzzy when deciding if a branch is a merge or a cherry pick; in
> some instances this might indicate intentionally skipping changes as not
> required, as if they had performed a real merge and then skipped those
> files.
>
> Signed-off-by: Sam Vilain <sam@vilain.net>
If I were _using_ git-svn (or any other tool), I would rather be forced to
see overlapping changes from both branches to sort out the conflict myself
when I merge such a cherry-picked history, rather than an automated but
unreliable operation that drops changes randomly, still records that
everything from the branch is now merged, and reports "everything is
peachy".
That sounds horrible, as you cannot trust your merges anymore. I hope I
am mis-interpreting what you wrote above.
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Sam Vilain @ 2009-12-22 21:13 UTC (permalink / raw)
To: Andrew Myrick; +Cc: Eric Wong, git
In-Reply-To: <B82A784D-C8D7-4DDF-AE63-390C7AE1CC2D@apple.com>
On Tue, 2009-12-22 at 11:38 -0800, Andrew Myrick wrote:
> Worked like a charm; the fetch is proceeding now. Thanks, Eric!
>
> Do you know what the "svn cherry-pick ignored" warnings mean, and if it's
> something I should be concerned about? This particular project is missing
> up to 65 commits at some revisions.
With git, merge parent relationships imply (conceptually, anyway) that
all of the changes reachable from that branch are included in the
commit. If someone is doing cherry-picking, then they are specifically
excluding some commits, so adding a merge parent to that branch isn't
right. This is what the warning is saying. It's happening every commit
because that section of code doesn't know whether a mergeinfo record is
new or not.
This wasn't happening with the old code, because it was simply not
detecting them correctly and adding merge parents anyway.
However in the case that someone is merging from another branch, merging
most commits, and only skipping a few, then it may make sense to record
it as a real merge. Here we start getting into non-deterministic
conversion; I had to do this for perl.git, because the merge records
weren't reliable. Basically I had the script, when the amount of merged
records was within a certain window, prompt me to ask me whether - based
on the change comment and outstanding files to merge - whether it should
be recorded as a real merge or not. Then, depending on which option I
picked, it would write out to the commit message a note of which files
were not *actually* merged in that commit.
Something like the below change might be the right thing for you, it
might not - before using it, make sure you keep a complete copy of your
git-svn clone so you can restart if required. Run it for a bit and
inspect the results. Basically considers a 90% merge "good enough" and
records the differences in the log. It could be possible to record the
cherry-pick information in the commit message, too - but we'd need to
also know which merge records were *added* in the current commit.
Actually, knowing that would make the whole thing much faster anyway, so
perhaps we need to bite the bullet and record it somewhere in the
metadata.
Anyway, this change may work - it doesn't break the test suite so that's
a good sign. But hopefully it should give you an idea of the direction
things could have to take. Perhaps you can see why I built a
high-performance fastimport importer for perl.git...
Subject: [PATCH] git-svn: consider 90% of a branch cherry picked to be a merge
Be slightly fuzzy when deciding if a branch is a merge or a cherry pick; in
some instances this might indicate intentionally skipping changes as not
required, as if they had performed a real merge and then skipped those
files.
Signed-off-by: Sam Vilain <sam@vilain.net>
---
git-svn.perl | 31 ++++++++++++++++++++++++++-----
1 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index f06e535..3064504 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2562,6 +2562,10 @@ sub do_git_commit {
unless ($self->no_metadata) {
print $msg_fh "\ngit-svn-id: $log_entry->{metadata}\n"
or croak $!;
+ if ($log_entry->{merge_notes}) {
+ print $msg_fh "\ngit-svn-merge: $log_entry->{merge_notes}\n"
+ or croak $!;
+ }
}
$msg_fh->flush == 0 or croak $!;
close $msg_fh or croak $!;
@@ -3027,10 +3031,11 @@ sub check_cherry_pick {
my @ranges = @_;
my %commits = map { $_ => 1 }
_rev_list("--no-merges", $tip, "--not", $base);
+ my $before = keys %commits;
for my $range ( @ranges ) {
delete @commits{_rev_list($range)};
}
- return (keys %commits);
+ return ($before, keys %commits);
}
BEGIN {
@@ -3103,6 +3108,8 @@ sub find_extra_svn_parents {
my %excluded = map { $_ => 1 }
parents_exclude($parents, grep { defined } @merge_tips);
+ my @merge_warnings;
+
# check merge tips for new parents
my @new_parents;
for my $merge_tip ( @merge_tips ) {
@@ -3118,14 +3125,25 @@ sub find_extra_svn_parents {
);
# double check that there are no missing non-merge commits
- my (@incomplete) = check_cherry_pick(
+ my ($total, @incomplete) = check_cherry_pick(
$merge_base, $merge_tip,
@$ranges,
);
- if ( @incomplete ) {
+ if ( @incomplete and @incomplete > ($total*0.10) ) {
warn "W:svn cherry-pick ignored ($spec) - missing "
- .@incomplete." commit(s) (eg $incomplete[0])\n";
+ .@incomplete."/$total commit(s) (eg $incomplete[0])\n";
+ # XXX - can't do this, it will appear every time;
+ # we need to know this record was added this commit
+ #push @merge_warnings, "picked: ". join(" ",
+ # map { my $x=$_; $x=~
+ # s{([a-f0-9]{12})[a-f0-9]+}{$1}g } @$ranges)
+ } elsif ( @incomplete ) {
+ warn "W:treating svn cherry-pick as merge "
+ .@incomplete."/$total commit(s) included\n";
+ push @merge_warnings, "skipped: ".
+ join(" ", map { substr $_, 0, 12 } @incomplete)
+ .")";
} else {
warn
"Found merge parent (svn:mergeinfo prop): ",
@@ -3151,6 +3169,7 @@ sub find_extra_svn_parents {
}
}
push @$parents, grep { defined } @new_parents;
+ return ( @merge_warnings ? join("; ", @merge_warnings) : undef );
}
sub make_log_entry {
@@ -3159,6 +3178,7 @@ sub make_log_entry {
my @parents = @$parents;
my $ps = $ed->{path_strip} || "";
+ my $merge_notes;
for my $path ( grep { m/$ps/ } %{$ed->{dir_prop}} ) {
my $props = $ed->{dir_prop}{$path};
if ( $props->{"svk:merge"} ) {
@@ -3166,7 +3186,7 @@ sub make_log_entry {
($ed, $props->{"svk:merge"}, \@parents);
}
if ( $props->{"svn:mergeinfo"} ) {
- $self->find_extra_svn_parents
+ $merge_notes = $self->find_extra_svn_parents
($ed,
$props->{"svn:mergeinfo"},
\@parents);
@@ -3269,6 +3289,7 @@ sub make_log_entry {
$log_entry{email} = $email;
$log_entry{commit_name} = $commit_name;
$log_entry{commit_email} = $commit_email;
+ $log_entry{merge_notes} = $merge_notes;
\%log_entry;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [spf:guess] Re: Regression: git-svn clone failure
From: Sam Vilain @ 2009-12-22 20:35 UTC (permalink / raw)
To: Eric Wong; +Cc: Andrew Myrick, git
In-Reply-To: <20091222192115.GA10313@dcvr.yhbt.net>
On Tue, 2009-12-22 at 11:21 -0800, Eric Wong wrote:
> That looks like a simple error, does the following patch help?
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 3670960..dba0d12 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -3163,7 +3163,8 @@ sub find_extra_svn_parents {
> next unless $new_parents[$i];
> next unless $new_parents[$j];
> my $revs = command_oneline(
> - "rev-list", "-1", "$i..$j",
> + "rev-list", "-1",
> + "$new_parents[$i]..$new_parents[$j]",
> );
Yes, that is the intent.
Hrm, I'd have thought my test would have stepped over that code when it
merged in a branch which merged two an svn branch which included a merge
of another svn branch. Obviously not! I'll cook something up to cover
that..
Sam.
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Eric Wong @ 2009-12-22 20:26 UTC (permalink / raw)
To: Junio C Hamano, Andrew Myrick; +Cc: git, sam
In-Reply-To: <B82A784D-C8D7-4DDF-AE63-390C7AE1CC2D@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> On Dec 22, 2009, at 11:21 AM, Eric Wong wrote:
> > That looks like a simple error, does the following patch help?
<snip>
> Worked like a charm; the fetch is proceeding now. Thanks, Eric!
Awesome, tanks for the feedback, Andrew.
I've pushed out a proper commit to git://git.bogomips.org/git-svn
for Junio (which also contains the previous pull request).
Andrew Myrick (1):
git-svn: Remove obsolete MAXPARENT check
Eric Wong (3):
git svn: fix --revision when fetching deleted paths
update release notes for git svn in 1.6.6
git svn: lookup new parents correctly from svn:mergeinfo
Sam Vilain (5):
git-svn: expand the svn mergeinfo test suite, highlighting some failures
git-svn: memoize conversion of SVN merge ticket info to git commit ranges
git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges
git-svn: exclude already merged tips using one rev-list call
git-svn: detect cherry-picks correctly.
> Do you know what the "svn cherry-pick ignored" warnings mean, and if
> it's something I should be concerned about? This particular project
> is missing up to 65 commits at some revisions.
Definitely a question for Sam :)
--
Eric Wong
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Andrew Myrick @ 2009-12-22 19:38 UTC (permalink / raw)
To: Eric Wong; +Cc: git, sam
In-Reply-To: <20091222192115.GA10313@dcvr.yhbt.net>
On Dec 22, 2009, at 11:21 AM, Eric Wong wrote:
> That looks like a simple error, does the following patch help?
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 3670960..dba0d12 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -3163,7 +3163,8 @@ sub find_extra_svn_parents {
> next unless $new_parents[$i];
> next unless $new_parents[$j];
> my $revs = command_oneline(
> - "rev-list", "-1", "$i..$j",
> + "rev-list", "-1",
> + "$new_parents[$i]..$new_parents[$j]",
> );
> if ( !$revs ) {
> undef($new_parents[$i]);
>
>
Worked like a charm; the fetch is proceeding now. Thanks, Eric!
Do you know what the "svn cherry-pick ignored" warnings mean, and if it's something I should be concerned about? This particular project is missing up to 65 commits at some revisions.
-Andrew
^ permalink raw reply
* Re: Regression: git-svn clone failure
From: Eric Wong @ 2009-12-22 19:21 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git, sam
In-Reply-To: <8BD646EB-3F47-41F8-918C-19133CCCA89C@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> [Resending because I forgot to make the message plain text]
>
> I was testing the latest changes to git-svn pushed to Eric's repo
> (git://git.bogomips.org/git-svn) by cloning a few other projects that
> I work on, and one of those clones failed where it had succeeded with
> git 1.6.5. The error message I received is:
>
> W:svn cherry-pick ignored (/branches/BranchA:3933-3950) - missing 1 commit(s) (eg 3fc50d3a7e0f555547ab34bb570db47ce71e1abb)
> W:svn cherry-pick ignored (/branches/BranchB:3951-3970) - missing 1 commit(s) (eg 3beb9f2fde0a91aa0e8097e05f9054b23b221daf)
> W:svn cherry-pick ignored (/branches/BranchC:3971-3985) - missing 1 commit(s) (eg a7ae202254604f8a78cca391be36c58efc79eb20)
> Found merge parent (svn:mergeinfo prop): 8b2cf9e9250b5ff1fe47c68215d0a178cfe35a3b
> Found merge parent (svn:mergeinfo prop): 59f8c571ae77885469bb31f007b0048ee7812e07
> fatal: ambiguous argument '0..1': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
> rev-list -1 0..1: command returned error: 128
Hi Andrew,
That looks like a simple error, does the following patch help?
diff --git a/git-svn.perl b/git-svn.perl
index 3670960..dba0d12 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3163,7 +3163,8 @@ sub find_extra_svn_parents {
next unless $new_parents[$i];
next unless $new_parents[$j];
my $revs = command_oneline(
- "rev-list", "-1", "$i..$j",
+ "rev-list", "-1",
+ "$new_parents[$i]..$new_parents[$j]",
);
if ( !$revs ) {
undef($new_parents[$i]);
Unfortunately I don't know my way around the rest of this code well
so I shall defer to Sam if it's something else...
--
Eric Wong
^ permalink raw reply related
* [PATCH] Prevent git blame from segfaulting on a missing author name
From: David Reiss @ 2009-12-22 18:51 UTC (permalink / raw)
To: git
The author name should never be missing in a valid commit, but
git shouldn't segfault no matter what is in the object database.
(Most of the C code was written by Junio.)
Signed-off-by: David Reiss <dreiss@facebook.com>
---
builtin-blame.c | 13 ++++++++++---
t/t8003-blame.sh | 13 +++++++++++++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index d4e25a5..14830a3 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1305,6 +1305,7 @@ static void get_ac_line(const char *inbuf, const char *what,
error_out:
/* Ugh */
*tz = "(unknown)";
+ strcpy(person, *tz);
strcpy(mail, *tz);
*time = 0;
return;
@@ -1314,20 +1315,26 @@ static void get_ac_line(const char *inbuf, const char *what,
tmp = person;
tmp += len;
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp == person)
+ goto error_out;
*tz = tmp+1;
tzlen = (person+len)-(tmp+1);
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp == person)
+ goto error_out;
*time = strtoul(tmp, NULL, 10);
timepos = tmp;
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp <= person)
+ return;
mailpos = tmp + 1;
*tmp = 0;
maillen = timepos - tmp;
diff --git a/t/t8003-blame.sh b/t/t8003-blame.sh
index 13c25f1..ad834f2 100755
--- a/t/t8003-blame.sh
+++ b/t/t8003-blame.sh
@@ -144,4 +144,17 @@ test_expect_success 'blame path that used to be a directory' '
git blame HEAD^.. -- path
'
+test_expect_success 'blame to a commit with no author name' '
+ TREE=`git rev-parse HEAD:`
+ cat >badcommit <<EOF
+tree $TREE
+author <noname> 1234567890 +0000
+committer David Reiss <dreiss@facebook.com> 1234567890 +0000
+
+some message
+EOF
+ COMMIT=`git hash-object -t commit -w badcommit`
+ git --no-pager blame $COMMIT -- uno >/dev/null
+'
+
test_done
--
1.6.3.3
^ permalink raw reply related
* Regression: git-svn clone failure
From: Andrew Myrick @ 2009-12-22 18:43 UTC (permalink / raw)
To: git; +Cc: Eric Wong, sam
[Resending because I forgot to make the message plain text]
I was testing the latest changes to git-svn pushed to Eric's repo (git://git.bogomips.org/git-svn) by cloning a few other projects that I work on, and one of those clones failed where it had succeeded with git 1.6.5. The error message I received is:
W:svn cherry-pick ignored (/branches/BranchA:3933-3950) - missing 1 commit(s) (eg 3fc50d3a7e0f555547ab34bb570db47ce71e1abb)
W:svn cherry-pick ignored (/branches/BranchB:3951-3970) - missing 1 commit(s) (eg 3beb9f2fde0a91aa0e8097e05f9054b23b221daf)
W:svn cherry-pick ignored (/branches/BranchC:3971-3985) - missing 1 commit(s) (eg a7ae202254604f8a78cca391be36c58efc79eb20)
Found merge parent (svn:mergeinfo prop): 8b2cf9e9250b5ff1fe47c68215d0a178cfe35a3b
Found merge parent (svn:mergeinfo prop): 59f8c571ae77885469bb31f007b0048ee7812e07
fatal: ambiguous argument '0..1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
rev-list -1 0..1: command returned error: 128
At this point, the clone got stuck in a loop and I had to kill it.
Note that all of the projects I cloned had "svn cherry-pick ignored" warnings sprinkled throughout the fetch logs; I'm not sure how much they matter. It comes from find_extra_svn_parents(), which I would guess is a best-effort algorithm, and any failures to detect extra parents aren't anything to worry about.
Does anyone have suggestions on how I can debug this? If you want to poke around, I can't provide access to the repository, but I can run commands and relay (sanitized) output if it will aid in debugging.
-Andrew
^ permalink raw reply
* Re: following untracked parents in git-svn
From: Eric Wong @ 2009-12-22 18:38 UTC (permalink / raw)
To: Robert Schiele; +Cc: git
In-Reply-To: <20091222102815.GA12259@sigfpe.ibm.com>
Robert Schiele <rschiele@gmail.com> wrote:
> Hi Eric et al.,
>
> While using git-svn to work with a repository with a very complex history I
> discovered a very unfortunate behavior:
>
> In general when a branch was derived (copied) from somewhere else git-svn
> follows this parent branch and imports it. If multiple branches do that
> git-svn detects that the corresponding parrent branch already had been
> imported and reuses the imported data. Unfortunately when the parent
> directory in the svn repository is not tracked as a branch in the svn-remote
> section of the config file (for instance when it is just a subdirectory of a
> tracked branch) this situation is no longer detected and this parent branch is
> imported multiple times with the same result. In a large repository this can
> increase importing time drastically.
>
> My analysis (as far as I understand the code) is that this is because the map
> files in .git/svn are indexed by their ref name in the git repository.
> Untracked branches are indexed by the name of their following branch ref name
> followed by @XX where XX is the revision number of the branch point.
> Obviously with that scheme the index name for two branches following a common
> parent tree is different and thus an already imported tree is not correctly
> detected.
Hi Robert, I'm aware of this problem. It's not hit too often, but
occassional repositories I follow tend to hit this.
> My thoughts where now that this could potentially be fixed by not indexing
> those map files by their ref name in the git repository but by their location
> in the original svn repository. Given that my understanding of the git-svn
> code is not good enough to decide about all the consequences of such a design
> change I'd like to ask you whether you think this change would be a good idea
> or whether I might have overlooked a fundamental problem that makes it
> impossible (or at least hard) to implement this idea.
Your idea sounds like it should work. Unfortunately the code is a mess
and I've been lazy and lacking time/sufficient motivation to clean it
up, but I'd be glad to accept patches since the test coverage is pretty
good.
--
Eric Wong
^ permalink raw reply
* Re: [RFC PATCH] Record a single transaction for conflicting push operations
From: Catalin Marinas @ 2009-12-22 18:33 UTC (permalink / raw)
To: Karl Wiberg; +Cc: git, Gustav Hållberg
In-Reply-To: <b8197bcb0912210548q67c1da4bhe023bed2811394d4@mail.gmail.com>
Updated patch below:
Record a single transaction for conflicting push operations
From: Catalin Marinas <catalin.marinas@gmail.com>
StGit commands resulting in a conflicting patch pushing record two
transactions in the log (with one of them being inconsistent with HEAD
!= top). Undoing such operations requires two "stg undo" (possibly with
--hard) commands which is unintuitive. This patch changes such
operations to only record one log entry and "stg undo" reverts the stack
to the state prior to the operation.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Cc: Gustav Hållberg <gustav@virtutech.com>
Cc: Karl Wiberg <kha@treskal.com>
---
stgit/lib/transaction.py | 35 ++++++++++++++++-------------------
t/t3101-reset-hard.sh | 2 +-
t/t3103-undo-hard.sh | 4 ++--
3 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 30a153b..d82e724 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -90,7 +90,6 @@ class StackTransaction(object):
self.__applied = list(self.__stack.patchorder.applied)
self.__unapplied = list(self.__stack.patchorder.unapplied)
self.__hidden = list(self.__stack.patchorder.hidden)
- self.__conflicting_push = None
self.__error = None
self.__current_tree = self.__stack.head.data.tree
self.__base = self.__stack.base
@@ -232,10 +231,9 @@ class StackTransaction(object):
self.__stack.patchorder.hidden = self.__hidden
log.log_entry(self.__stack, msg)
old_applied = self.__stack.patchorder.applied
- write(self.__msg)
- if self.__conflicting_push != None:
- self.__patches = _TransPatchMap(self.__stack)
- self.__conflicting_push()
+ if not self.__conflicts:
+ write(self.__msg)
+ else:
write(self.__msg + ' (CONFLICT)')
if print_current_patch:
_print_current_patch(old_applied, self.__applied)
@@ -358,26 +356,25 @@ class StackTransaction(object):
elif not merge_conflict and cd.is_nochange():
s = 'empty'
out.done(s)
- def update():
- if comm:
- self.patches[pn] = comm
- if pn in self.hidden:
- x = self.hidden
- else:
- x = self.unapplied
- del x[x.index(pn)]
- self.applied.append(pn)
+
if merge_conflict:
# We've just caused conflicts, so we must allow them in
# the final checkout.
self.__allow_conflicts = lambda trans: True
+ self.__patches = _TransPatchMap(self.__stack)
- # Save this update so that we can run it a little later.
- self.__conflicting_push = update
- self.__halt("%d merge conflict(s)" % len(self.__conflicts))
+ # Update the stack state
+ if comm:
+ self.patches[pn] = comm
+ if pn in self.hidden:
+ x = self.hidden
else:
- # Update immediately.
- update()
+ x = self.unapplied
+ del x[x.index(pn)]
+ self.applied.append(pn)
+
+ if merge_conflict:
+ self.__halt("%d merge conflict(s)" % len(self.__conflicts))
def push_tree(self, pn):
"""Push the named patch without updating its tree."""
diff --git a/t/t3101-reset-hard.sh b/t/t3101-reset-hard.sh
index bd97b3a..45e86dc 100755
--- a/t/t3101-reset-hard.sh
+++ b/t/t3101-reset-hard.sh
@@ -47,7 +47,7 @@ test_expect_success 'Try to reset with --hard' '
stg reset --hard master.stgit^~1 &&
stg status a > actual.txt &&
test_cmp expected.txt actual.txt &&
- test "$(echo $(stg series))" = "> p1 - p2 - p3"
+ test "$(echo $(stg series))" = "+ p1 + p2 > p3"
'
test_done
diff --git a/t/t3103-undo-hard.sh b/t/t3103-undo-hard.sh
index 2d0f382..df14b1f 100755
--- a/t/t3103-undo-hard.sh
+++ b/t/t3103-undo-hard.sh
@@ -46,11 +46,11 @@ test_expect_success 'Try to undo without --hard' '
cat > expected.txt <<EOF
EOF
-test_expect_failure 'Try to undo with --hard' '
+test_expect_success 'Try to undo with --hard' '
stg undo --hard &&
stg status a > actual.txt &&
test_cmp expected.txt actual.txt &&
- test "$(echo $(stg series))" = "> p1 - p2 - p3" &&
+ test "$(echo $(stg series))" = "+ p1 + p2 > p3" &&
test "$(stg id)" = "$(stg id $(stg top))"
'
^ permalink raw reply related
* Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Tomas Carnecky @ 2009-12-22 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmy1a3mrh.fsf@alter.siamese.dyndns.org>
On 12/22/09 7:08 PM, Junio C Hamano wrote:
> Tomas Carnecky<tomas.carnecky@gmail.com> writes:
>
>> $ git --version
>> git version 1.6.6.rc4
>>
>> # Documentation/perf_counter is missing from the master branch, so
>> first let's find
>> # out what the last commit was that touched that subdirectory:
>> $ git log --all -1 -- Documentation/perf_counter
>> commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> Author: Peter Zijlstra<a.p.zijlstra@chello.nl>
>> Date: Tue Jun 2 21:02:36 2009 +0200
>> ...
>> M Documentation/perf_counter/builtin-report.c
>>
>> # Great, let's look in which branch that commit is
>> $ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> * master
>>
>> # So, let's look at the log of master and limit it to that subdirectory:
>> $ git log master -- Documentation/perf_counter
>> $
>
> Add --full-history so that you would get _all_ possible explanation of the
> history, perhaps?
>
> In a history with this shape:
>
> ---A---B---C---D---E
> \ /
> F---G
>
> suppose that
>
> - commit F introduces a path;
> - commit G removes the path;
> - no other commit has the path in question.
>
> Without --full-history, "log E -- path" is asked to give "_one_ possible
> way to explain the current state of path in E" (iow, "why there is nothing
> there right now at E?").
>
> Two explanations are possible even in this vastly simplified toy history.
>
> - It didn't exist in A, and none of the subsequent commits B, C, D that
> lead to E did anything to change that.
>
> - F added it, but G changed mind and removed it.
>
> When "log" encounters a merge commit while traversing the history
> backwards (in this case D) with paths limiter, if there is a commit among
> its parent whose tree matches its tree with respect to the paths, side
> branches leading to all the other parents are culled and only that one
> history is followed to explain the history. In this case, neither C or D
> has the path, so their trees with respect to the paths limiter match, and
> git doesn't follow the side branch that has F and G without
> --full-history.
I've never used nor seen --full-history before, but it did help in this
case, git log now correctly sees the commits touching that subdirectory.
Thanks for the explanation.
tom
^ permalink raw reply
* Re: Huge pack file from small unpacked objects
From: Junio C Hamano @ 2009-12-22 18:11 UTC (permalink / raw)
To: Nick Triantos; +Cc: B Smith-Mannschott, git@vger.kernel.org
In-Reply-To: <75B8C0BEE0AE2A44AA971D218D9FE99E6B06F111@VMBX125.ihostexchange.net>
Nick Triantos <nick@perceptivepixel.com> writes:
> Is there an easy way to unpack the pack file and see what's inside (including sizes)?
Unpack?
(mkdir /var/tmp/junk &&
cd /var/tmp/junk &&
git init && git unpack-objects) <.git/objects/pack/pack-$that_one.pack
It might also be interesting to see
git verify-pack -v .git/objects/pack/pack-$that_one.pack
^ permalink raw reply
* Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Junio C Hamano @ 2009-12-22 18:08 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Git Mailing List
In-Reply-To: <4B3099A5.6040808@gmail.com>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> $ git --version
> git version 1.6.6.rc4
>
> # Documentation/perf_counter is missing from the master branch, so
> first let's find
> # out what the last commit was that touched that subdirectory:
> $ git log --all -1 -- Documentation/perf_counter
> commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Tue Jun 2 21:02:36 2009 +0200
> ...
> M Documentation/perf_counter/builtin-report.c
>
> # Great, let's look in which branch that commit is
> $ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
> * master
>
> # So, let's look at the log of master and limit it to that subdirectory:
> $ git log master -- Documentation/perf_counter
> $
Add --full-history so that you would get _all_ possible explanation of the
history, perhaps?
In a history with this shape:
---A---B---C---D---E
\ /
F---G
suppose that
- commit F introduces a path;
- commit G removes the path;
- no other commit has the path in question.
Without --full-history, "log E -- path" is asked to give "_one_ possible
way to explain the current state of path in E" (iow, "why there is nothing
there right now at E?").
Two explanations are possible even in this vastly simplified toy history.
- It didn't exist in A, and none of the subsequent commits B, C, D that
lead to E did anything to change that.
- F added it, but G changed mind and removed it.
When "log" encounters a merge commit while traversing the history
backwards (in this case D) with paths limiter, if there is a commit among
its parent whose tree matches its tree with respect to the paths, side
branches leading to all the other parents are culled and only that one
history is followed to explain the history. In this case, neither C or D
has the path, so their trees with respect to the paths limiter match, and
git doesn't follow the side branch that has F and G without
--full-history.
^ permalink raw reply
* RE: Huge pack file from small unpacked objects
From: Nick Triantos @ 2009-12-22 18:04 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: git@vger.kernel.org
In-Reply-To: <28c656e20912220054qc7b6497t79e135c913865c22@mail.gmail.com>
I've tried running 'git gc' (which should be pruning) and that hasn't helped.
Is there an easy way to unpack the pack file and see what's inside (including sizes)?
thanks,
-Nick
-----Original Message-----
From: B Smith-Mannschott [mailto:bsmith.occs@gmail.com]
Sent: Tuesday, December 22, 2009 12:55 AM
To: Nick Triantos
Cc: git@vger.kernel.org
Subject: Re: Huge pack file from small unpacked objects
On Wed, Dec 16, 2009 at 17:34, Nick Triantos <nick@perceptivepixel.com> wrote:
> Hi,
>
> I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
>
> I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
>
> Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
Have you tried "git prune"?
// Ben
^ permalink raw reply
* Re: Huge pack file from small unpacked objects
From: Nicolas Pitre @ 2009-12-22 17:41 UTC (permalink / raw)
To: Nick Triantos; +Cc: 'git@vger.kernel.org'
In-Reply-To: <75B8C0BEE0AE2A44AA971D218D9FE99E6B06F030@VMBX125.ihostexchange.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 727 bytes --]
On Tue, 22 Dec 2009, Nick Triantos wrote:
> I recently created a repo from SVN via git-svn. The bare repo was
> about ~600MB. I cloned it, and on the clone, I added 2 small files
> (.gitignore and .gitattributes) to a branch, merged them to master,
> and pushed that back to the origin. The cloned repo remains at about
> 600MB, while my origin repo (the one from svn) is now about 2.4GB. I
> found that it created a file in objects/pack which accounts for this
> huge size.
>
> I've tried running 'git repack -a -d' but that didn't shrink the size
> of this pack file.
This is rather weird.
Any chance the original repository could be downloaded somewhere in
order to attempt reproducing this issue?
Nicolas
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Michael J Gruber @ 2009-12-22 17:22 UTC (permalink / raw)
To: Craig Moore; +Cc: git
In-Reply-To: <d4133e470912220814h465175bfr8fd10942898096a1@mail.gmail.com>
Craig Moore venit, vidit, dixit 22.12.2009 17:14:
> 2009/12/22 Michael J Gruber <git@drmicha.warpmail.net>:
>> Craig Moore venit, vidit, dixit 22.12.2009 16:50:
>>> Hi,
>>>
>>> I'm getting the following error when I make the info target:
>>>
>>> $ make prefix=/usr info
>>> make -C Documentation info
>>> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
>>> make[2]: Entering directory `/local/software/git-1.6.5.7'
>>> make[2]: `GIT-VERSION-FILE' is up to date.
>>> make[2]: Leaving directory `/local/software/git-1.6.5.7'
>>> DB2TEXI user-manual.texi
>>> Usage: jw [<options>] <sgml_file>
>>> where <options> are:
>>> -f|--frontend <frontend>: Specify the frontend (source format)
>>> (default is docbook)
>>> -b|--backend <backend>: Specify the backend (destination format)
>>> (default is html)
>>> -c|--cat <file>: Specify an extra SGML open catalog
>>> -n|--nostd: Do not use the standard SGML open catalogs
>>> -d|--dsl <file>|default|none: Specify an alternate style sheet
>>> (default is to use the default stylesheet)
>>> -l|--dcl <file>: Specify an alternate SGML declaration
>>> (usual ones like xml.dcl get detected
>>> automatically)
>>> -s|--sgmlbase <path>: Change base directory for SGML distribution
>>> (usually /usr/share/sgml)
>>> -p|--parser <program>: Specify the parser if several are installed
>>> (jade or openjade)
>>> -o|--output <directory>: Set output directory
>>> -u|--nochunks: Output only one big file
>>> (overrides the stylesheet settings)
>>> -i|--include <section>: Specify a SGML marked section to include
>>> (should be marked as "ignore" in the SGML text)
>>> -w|--warning <warning_type>|list: Control warnings or display the allowed
>>> warning types
>>> -e|--errors <error_type>|list: Control errors or display the allowed error types
>>> -h|--help: Print this help message and exit
>>> -V <variable[=value]>: Set a variable
>>> -v|--version: Print the version and exit
>>> make[1]: *** [user-manual.texi] Error 1
>>> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
>>> make: *** [info] Error 2
>>>
>>> I can see that the error is likely related to the fact that it enters the
>>> Documentation directing, then exits the Documentation directory, and then tries
>>> to build the user-manual.texi file in the root directory (however, that file is
>>> in the Documentation directory, which it just left). I've tried to track down
>>> and change where it exits the Documentation directory, but I've had no success.
>>>
>>> I would appreciate any recommendations you might have. I've already been able to
>>> install git, but I couldn't install the 'info' target because of this error.
>>
>> Does it work without prefix?
>> Also, you may want to cd into Documentation and try to make there.
>>
>> Michael
>>
>>
>
> Hey Michael,
>
> Here is what happens when I run it inside the Documentation directory
> (without the prefix):
>
> user@server: /local/software/git-1.6.5.7/Documentation
> $ make info
> SUBDIR ../
> make[1]: `GIT-VERSION-FILE' is up to date.
> DB2TEXI user-manual.texi
> Usage: jw [<options>] <sgml_file>
> where <options> are:
> -f|--frontend <frontend>: Specify the frontend (source format)
> (default is docbook)
> -b|--backend <backend>: Specify the backend (destination format)
> (default is html)
> -c|--cat <file>: Specify an extra SGML open catalog
> -n|--nostd: Do not use the standard SGML open catalogs
> -d|--dsl <file>|default|none: Specify an alternate style sheet
> (default is to use the default stylesheet)
> -l|--dcl <file>: Specify an alternate SGML declaration
> (usual ones like xml.dcl get detected
> automatically)
> -s|--sgmlbase <path>: Change base directory for SGML distribution
> (usually /usr/share/sgml)
> -p|--parser <program>: Specify the parser if several are installed
> (jade or openjade)
> -o|--output <directory>: Set output directory
> -u|--nochunks: Output only one big file
> (overrides the stylesheet settings)
> -i|--include <section>: Specify a SGML marked section to include
> (should be marked as "ignore" in the SGML text)
> -w|--warning <warning_type>|list: Control warnings or display the
> allowed warning types
> -e|--errors <error_type>|list: Control errors or display the allowed
> error types
> -h|--help: Print this help message and exit
> -V <variable[=value]>: Set a variable
> -v|--version: Print the version and exit
> make: *** [user-manual.texi] Error 1
>
> The first thing it does is go to the directory above, weird.
>
> Craig
I think it only looks like that. SUBDIR processing is finished at that
point, and the DB2TEXI line is where user-manual.texi is actually being
processed, and that's what's causing the error. Did you set the texinfo
processor in the Makefile or using variables?
V=1 make info
will show you the exact commands being executed.
Michael
^ permalink raw reply
* Re: git's fascination with absolute paths
From: J Chapman Flack @ 2009-12-22 17:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vy6kv4j2u.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Clarificaiton.
>
> The above, like many other messages from me, was not meant as a
> justification, but a mere explanation of the historical fact. IOW,
> don't get me wrong by interpreting that I am not interested in seeing
> a solution that does not use absolute paths.
No worries - a sense of the history is exactly the kind of response
I was hoping for. :)
> While I think the original "higher levels in the filesystems may not
> be accessible" is a rather unusual set-up, making paths absolute and
> relying on being able to always do so have another drawback in a
> not-so-unusual setup. A work tree that is shallow (say, has only one
> t/ subdirectory and short filenames) may not be usable if it is so
> deep in the filesystem hierarchy that the result of getcwd(3) exceeds
> PATH_MAX. The "hand roll
This is funny; I think in my own career I've seen applications that keep
sensitive data in subtrees restricted at the top somewhat routinely (which
might not mean "really often in absolute terms" but something more like
"whenever it made sense for the app") going back at least as far as uucp
(IIRC) ... Solaris Zones are set up that way too (when viewed from the
global zone). By the same token, while I'd never be surprised to hear
of someone with deep hierarchies that exceed PATH_MAX, I'm not sure I've
ever actually seen it happen myself.
I don't intend that as the start of a "which case is more unusual"
comparison, I think it just illustrates the difficulty in making such
judgments of usualness, as different people's career trajectories expose
them to very different things. I'd rather spend the mental effort trying
to extract whatever general principle can be used to code robustly so the
fewest judgments of usualness need to be made. Here the general principle
(which I think you've already kind of stated yourself, so I'm not trying
to preach but just to finish the thought) is that, for various reasons,
trying to transform a relative into an absolute path is not always well
defined, can't even always be done, can have implementation-dependent
side effects and race conditions, and ought to be an operation that gets
pulled out of the arsenal only with deliberation and only for specific
paths that must be made absolute if that's the only way to satisfy some
known functional requirement of the app.
It might be tied in to the principle of least astonishment, just by
assuming that whatever path the caller, user, or admin provides is
probably the path s/he wants you to use, for any number of possible
reasons that you don't need to be able to foresee.
>> By rewriting that part of the "root-level-discovery" code to do
>> something like
>>
>> - while test -d .git is not true:
>> - stat(".") to get the inum;
>> - chdir(".."); and
>> - opendir(".") and readdir() to find where we were;
>>
>> while going up every level, you should be able to construct the prefix
>> without being to able to read all the way up to the filesystem root.
You
>> only need to be able to read your work tree.
Yes, that's exactly what I would have suggested for the root level
discovery. As long as you can find .git before reaching any inaccessible
ancestor, life is good. (And if you can't it's a perfectly good reason
to give up without astonishing the user.)
It would still be better to open "." once at the beginning and
fchdir back to it, rather than trying to chdir back to the
constructed path string (an inherent race condition), just as the
Notes section in linux getcwd(3) says.
An interesting point, the chdir ../opendir/readdir algorithm you
give above is no longer necessarily what getcwd does, though it
traditionally was. These days there's often a kernel name cache
that getcwd gets at through a syscall or /proc. You can tell,
because when I tried to use 'git init' in my situation, the error
was not from getcwd but from the later access() call done on the
full path that getcwd successfully returned.
[there's a side issue: access(2) isn't for what a lot of people
think it's for. It's a rather esoteric call for testing access
by the real ids instead of the effective ones, and it's needed
in code that (a) runs set{u,g}id AND (b) wants to confirm that
a user-specified file is really something the user has rights to.
Using access() routinely just to ask "can I open this" has
a couple of problems: (1) it has a race condition and gives you
less information than just trying the open and testing errno;
(2) if anybody down the road does try to use your program or
code under set{u,g}id circumstances, astonishing failures can
result. Even for its intended purpose access() suffers from a
race; current OSes make it fairly easy to just drop to the real
user's IDs, try the open, and test errno, so access() is a bit
of a dinosaur.]
Anyway, it would also be possible to make use of the modern
optimized getcwd in the root-level-discovery algorithm. If getcwd
gives a result you can just follow it backwards until you find .git,
confirming in each step that you can stat the name of the child and
the inums match (an O(1) test instead of O(directory-size) for readdir).
Just don't follow it back past the directory containing .git. The
slower fallback code is only needed for less modern systems in case
getcwd returns EACCES. But now we're in the realm of optimization;
the traditional loop does the trick.
(well, one nice feature of the modern approach, beyond speed, is that
it only needs x on the directories up to .git and not r. but since
I'm doubtful anything else git does would actually work without r,
that's probably moot.)
>> Admittedly the code complexity got worse later when we added support
>> for GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they
>> fundamentally need to know where you are relative to the root of the
>> filesystem tree and need a working getcwd(3) support
That's the kind of thing I wondered about, are there particular
features that genuinely require an absolute path? I'm a git newbie
and I don't know what these features do, so I can't comment. (This
project was going to be my excuse for learning git, but rcs actually
suffices and I need to get it done.)
Do these features actually need to traverse the full path, or just
to know what it is? On a system with modern getcwd that can return
the path even if it isn't traversable, could they make use of that?
-Chap
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Craig Moore @ 2009-12-22 16:14 UTC (permalink / raw)
To: git
In-Reply-To: <4B30ECA1.2040508@drmicha.warpmail.net>
2009/12/22 Michael J Gruber <git@drmicha.warpmail.net>:
> Craig Moore venit, vidit, dixit 22.12.2009 16:50:
>> Hi,
>>
>> I'm getting the following error when I make the info target:
>>
>> $ make prefix=/usr info
>> make -C Documentation info
>> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
>> make[2]: Entering directory `/local/software/git-1.6.5.7'
>> make[2]: `GIT-VERSION-FILE' is up to date.
>> make[2]: Leaving directory `/local/software/git-1.6.5.7'
>> DB2TEXI user-manual.texi
>> Usage: jw [<options>] <sgml_file>
>> where <options> are:
>> -f|--frontend <frontend>: Specify the frontend (source format)
>> (default is docbook)
>> -b|--backend <backend>: Specify the backend (destination format)
>> (default is html)
>> -c|--cat <file>: Specify an extra SGML open catalog
>> -n|--nostd: Do not use the standard SGML open catalogs
>> -d|--dsl <file>|default|none: Specify an alternate style sheet
>> (default is to use the default stylesheet)
>> -l|--dcl <file>: Specify an alternate SGML declaration
>> (usual ones like xml.dcl get detected
>> automatically)
>> -s|--sgmlbase <path>: Change base directory for SGML distribution
>> (usually /usr/share/sgml)
>> -p|--parser <program>: Specify the parser if several are installed
>> (jade or openjade)
>> -o|--output <directory>: Set output directory
>> -u|--nochunks: Output only one big file
>> (overrides the stylesheet settings)
>> -i|--include <section>: Specify a SGML marked section to include
>> (should be marked as "ignore" in the SGML text)
>> -w|--warning <warning_type>|list: Control warnings or display the allowed
>> warning types
>> -e|--errors <error_type>|list: Control errors or display the allowed error types
>> -h|--help: Print this help message and exit
>> -V <variable[=value]>: Set a variable
>> -v|--version: Print the version and exit
>> make[1]: *** [user-manual.texi] Error 1
>> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
>> make: *** [info] Error 2
>>
>> I can see that the error is likely related to the fact that it enters the
>> Documentation directing, then exits the Documentation directory, and then tries
>> to build the user-manual.texi file in the root directory (however, that file is
>> in the Documentation directory, which it just left). I've tried to track down
>> and change where it exits the Documentation directory, but I've had no success.
>>
>> I would appreciate any recommendations you might have. I've already been able to
>> install git, but I couldn't install the 'info' target because of this error.
>
> Does it work without prefix?
> Also, you may want to cd into Documentation and try to make there.
>
> Michael
>
>
Hey Michael,
Here is what happens when I run it inside the Documentation directory
(without the prefix):
user@server: /local/software/git-1.6.5.7/Documentation
$ make info
SUBDIR ../
make[1]: `GIT-VERSION-FILE' is up to date.
DB2TEXI user-manual.texi
Usage: jw [<options>] <sgml_file>
where <options> are:
-f|--frontend <frontend>: Specify the frontend (source format)
(default is docbook)
-b|--backend <backend>: Specify the backend (destination format)
(default is html)
-c|--cat <file>: Specify an extra SGML open catalog
-n|--nostd: Do not use the standard SGML open catalogs
-d|--dsl <file>|default|none: Specify an alternate style sheet
(default is to use the default stylesheet)
-l|--dcl <file>: Specify an alternate SGML declaration
(usual ones like xml.dcl get detected
automatically)
-s|--sgmlbase <path>: Change base directory for SGML distribution
(usually /usr/share/sgml)
-p|--parser <program>: Specify the parser if several are installed
(jade or openjade)
-o|--output <directory>: Set output directory
-u|--nochunks: Output only one big file
(overrides the stylesheet settings)
-i|--include <section>: Specify a SGML marked section to include
(should be marked as "ignore" in the SGML text)
-w|--warning <warning_type>|list: Control warnings or display the
allowed warning types
-e|--errors <error_type>|list: Control errors or display the allowed
error types
-h|--help: Print this help message and exit
-V <variable[=value]>: Set a variable
-v|--version: Print the version and exit
make: *** [user-manual.texi] Error 1
The first thing it does is go to the directory above, weird.
Craig
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Michael J Gruber @ 2009-12-22 15:58 UTC (permalink / raw)
To: Craig Moore; +Cc: git
In-Reply-To: <loom.20091222T164442-704@post.gmane.org>
Craig Moore venit, vidit, dixit 22.12.2009 16:50:
> Hi,
>
> I'm getting the following error when I make the info target:
>
> $ make prefix=/usr info
> make -C Documentation info
> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
> make[2]: Entering directory `/local/software/git-1.6.5.7'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/local/software/git-1.6.5.7'
> DB2TEXI user-manual.texi
> Usage: jw [<options>] <sgml_file>
> where <options> are:
> -f|--frontend <frontend>: Specify the frontend (source format)
> (default is docbook)
> -b|--backend <backend>: Specify the backend (destination format)
> (default is html)
> -c|--cat <file>: Specify an extra SGML open catalog
> -n|--nostd: Do not use the standard SGML open catalogs
> -d|--dsl <file>|default|none: Specify an alternate style sheet
> (default is to use the default stylesheet)
> -l|--dcl <file>: Specify an alternate SGML declaration
> (usual ones like xml.dcl get detected
> automatically)
> -s|--sgmlbase <path>: Change base directory for SGML distribution
> (usually /usr/share/sgml)
> -p|--parser <program>: Specify the parser if several are installed
> (jade or openjade)
> -o|--output <directory>: Set output directory
> -u|--nochunks: Output only one big file
> (overrides the stylesheet settings)
> -i|--include <section>: Specify a SGML marked section to include
> (should be marked as "ignore" in the SGML text)
> -w|--warning <warning_type>|list: Control warnings or display the allowed
> warning types
> -e|--errors <error_type>|list: Control errors or display the allowed error types
> -h|--help: Print this help message and exit
> -V <variable[=value]>: Set a variable
> -v|--version: Print the version and exit
> make[1]: *** [user-manual.texi] Error 1
> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
> make: *** [info] Error 2
>
> I can see that the error is likely related to the fact that it enters the
> Documentation directing, then exits the Documentation directory, and then tries
> to build the user-manual.texi file in the root directory (however, that file is
> in the Documentation directory, which it just left). I've tried to track down
> and change where it exits the Documentation directory, but I've had no success.
>
> I would appreciate any recommendations you might have. I've already been able to
> install git, but I couldn't install the 'info' target because of this error.
Does it work without prefix?
Also, you may want to cd into Documentation and try to make there.
Michael
^ permalink raw reply
* Trouble with 'make prefix=/usr info'
From: Craig Moore @ 2009-12-22 15:50 UTC (permalink / raw)
To: git
Hi,
I'm getting the following error when I make the info target:
$ make prefix=/usr info
make -C Documentation info
make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
make[2]: Entering directory `/local/software/git-1.6.5.7'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/local/software/git-1.6.5.7'
DB2TEXI user-manual.texi
Usage: jw [<options>] <sgml_file>
where <options> are:
-f|--frontend <frontend>: Specify the frontend (source format)
(default is docbook)
-b|--backend <backend>: Specify the backend (destination format)
(default is html)
-c|--cat <file>: Specify an extra SGML open catalog
-n|--nostd: Do not use the standard SGML open catalogs
-d|--dsl <file>|default|none: Specify an alternate style sheet
(default is to use the default stylesheet)
-l|--dcl <file>: Specify an alternate SGML declaration
(usual ones like xml.dcl get detected
automatically)
-s|--sgmlbase <path>: Change base directory for SGML distribution
(usually /usr/share/sgml)
-p|--parser <program>: Specify the parser if several are installed
(jade or openjade)
-o|--output <directory>: Set output directory
-u|--nochunks: Output only one big file
(overrides the stylesheet settings)
-i|--include <section>: Specify a SGML marked section to include
(should be marked as "ignore" in the SGML text)
-w|--warning <warning_type>|list: Control warnings or display the allowed
warning types
-e|--errors <error_type>|list: Control errors or display the allowed error types
-h|--help: Print this help message and exit
-V <variable[=value]>: Set a variable
-v|--version: Print the version and exit
make[1]: *** [user-manual.texi] Error 1
make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
make: *** [info] Error 2
I can see that the error is likely related to the fact that it enters the
Documentation directing, then exits the Documentation directory, and then tries
to build the user-manual.texi file in the root directory (however, that file is
in the Documentation directory, which it just left). I've tried to track down
and change where it exits the Documentation directory, but I've had no success.
I would appreciate any recommendations you might have. I've already been able to
install git, but I couldn't install the 'info' target because of this error.
Thanks,
Craig
^ permalink raw reply
* Re: git fast-import not verifying commit author lines?
From: Shawn O. Pearce @ 2009-12-22 15:06 UTC (permalink / raw)
To: David Reiss; +Cc: git
In-Reply-To: <4B304987.7030201@facebook.com>
David Reiss <dreiss@facebook.com> wrote:
> mtn git_export produces this output on a simple repo:
>
> blob
> mark :1
> data 8
> content
>
> commit refs/heads/com.example.badexport
> mark :2
> author <somename> 1261454209 +0000
> committer <somename> 1261454209 +0000
> data 8
> acommit
>
> M 100644 :1 "afile"
> progress revision 9b0e11e4d66eba8a3cf26095fb573116b886cd37 (1/1)
> #############################################################
>
> The author and committer lines are missing the names (I've filed this as a
> bug with monotone). git commit-tree refuses to to produce a commit object
> like this, so it seems like git fast-import should detect and report this
> instead of silently writing the invalid commit object to the repository.
Nope.
These objects can still be processed by git commands, you just can't
normally create them with Git tools. To some extent fast-import
allows the caller to import data that you wouldn't otherwise create
in Git because we know you are coming from a foreign system where
the data might not reasonably exist.
--
Shawn.
^ permalink raw reply
* Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Tomas Carnecky @ 2009-12-22 12:23 UTC (permalink / raw)
To: Daniel, Git Mailing List
In-Reply-To: <6b08a1ab.3349a908.4b30b80f.ab91f@o2.pl>
On 12/22/09 1:14 PM, Daniel wrote:
> Dnia 22 grudnia 2009 11:04 Tomas Carnecky<tomas.carnecky@gmail.com> napisał(a):
>
>> $ git --version
>> git version 1.6.6.rc4
>>
>> # Documentation/perf_counter is missing from the master branch, so first
>> let's find
>> # out what the last commit was that touched that subdirectory:
>> $ git log --all -1 -- Documentation/perf_counter
>> commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> Author: Peter Zijlstra<a.p.zijlstra@chello.nl>
>> Date: Tue Jun 2 21:02:36 2009 +0200
>> ...
>> M Documentation/perf_counter/builtin-report.c
>>
>> # Great, let's look in which branch that commit is
>> $ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> * master
>>
>> # So, let's look at the log of master and limit it to that subdirectory:
>> $ git log master -- Documentation/perf_counter
>> $
>>
>> # Damn, that doesn't make any sense. In commit 43622 there were files in
>> that subdirectory, in master they have gone missing and yet log doesn't
>> show any commit touching that subdirectory?
>> # Let's try something different:
>> $ git log --diff-filter=D --name-status --all -- Documentation/perf_counter
>> ...
>>
>> # Ah, now we're getting somewhere, but still no sight of a commit which
>> removed for example Documentation/perf_counter/.gitignore
>> # I'm sure I'm probably just missing a tiny little switch for git-log. I
>> also tried other combination of name-status, diff-filter etc, but soon
>> after gave up.
>>
>> tom
>> --
> Try
>
> $ git log --follow -- Documentation/perf_counter
>
Ah, that did the trick:
86470930, perf_counter tools: Move from Documentation/perf_counter/ to
tools/perf/
However, that still doesn't answer my question why a simple git log
doesn't show the commits. There are commits which touch that
subdirectory, so why is a list of 'commits which touch that
subdirectory' empty? Or am I misunderstanding what 'git log -- dir/' is
supposed to do? I thought it did exactly that.
tom
^ permalink raw reply
* following untracked parents in git-svn
From: Robert Schiele @ 2009-12-22 10:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
[-- Attachment #1.1: Type: text/plain, Size: 3680 bytes --]
Hi Eric et al.,
While using git-svn to work with a repository with a very complex history I
discovered a very unfortunate behavior:
In general when a branch was derived (copied) from somewhere else git-svn
follows this parent branch and imports it. If multiple branches do that
git-svn detects that the corresponding parrent branch already had been
imported and reuses the imported data. Unfortunately when the parent
directory in the svn repository is not tracked as a branch in the svn-remote
section of the config file (for instance when it is just a subdirectory of a
tracked branch) this situation is no longer detected and this parent branch is
imported multiple times with the same result. In a large repository this can
increase importing time drastically.
My analysis (as far as I understand the code) is that this is because the map
files in .git/svn are indexed by their ref name in the git repository.
Untracked branches are indexed by the name of their following branch ref name
followed by @XX where XX is the revision number of the branch point.
Obviously with that scheme the index name for two branches following a common
parent tree is different and thus an already imported tree is not correctly
detected.
My thoughts where now that this could potentially be fixed by not indexing
those map files by their ref name in the git repository but by their location
in the original svn repository. Given that my understanding of the git-svn
code is not good enough to decide about all the consequences of such a design
change I'd like to ask you whether you think this change would be a good idea
or whether I might have overlooked a fundamental problem that makes it
impossible (or at least hard) to implement this idea.
Since my description of the problem might be a bit confusing without an
example I created a very small svn repository that shows this problem. A svn
repository dump for it is attached. When importing this repository using the
svn-remote section
[svn-remote "svn"]
url = file:///dev/shm/x/svn1
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
you will get the following behavior during the import:
$ git svn init -s file:///dev/shm/x/svn1
Initialized empty Git repository in /dev/shm/x/git2/.git/
$ git svn fetch
r1 = 7920f3e7e70c9bb9d8a7caf28830c7ed205c20c6 (refs/remotes/trunk)
A x/alpha
r2 = db7ad1b41f1d2ad18d198b9a80d2606b27557faf (refs/remotes/trunk)
A x/beta
r3 = a35cab9c510f66d96437f21ecb738c93e0c6b793 (refs/remotes/trunk)
Found possible branch point: file:///dev/shm/x/svn1/trunk/x => file:///dev/shm/x/svn1/branches/foo1, 2
Initializing parent: refs/remotes/foo1@2
A alpha
r2 = 5584693b5216dc1fa05f56455c67dfd61093ee43 (refs/remotes/foo1@2)
Found branch parent: (refs/remotes/foo1) 5584693b5216dc1fa05f56455c67dfd61093ee43
Following parent with do_switch
A beta
Successfully followed parent
r4 = d0cb7cfc1f69e52ecd39d8eb67518abe136b53d3 (refs/remotes/foo1)
Found possible branch point: file:///dev/shm/x/svn1/trunk/x => file:///dev/shm/x/svn1/branches/foo2, 2
Initializing parent: refs/remotes/foo2@2
A alpha
r2 = 5584693b5216dc1fa05f56455c67dfd61093ee43 (refs/remotes/foo2@2)
Found branch parent: (refs/remotes/foo2) 5584693b5216dc1fa05f56455c67dfd61093ee43
Following parent with do_switch
A beta
Successfully followed parent
r5 = 181cb81070b816bef74adefa1bc4c451100a5eef (refs/remotes/foo2)
Checked out HEAD:
file:///dev/shm/x/svn1/trunk r3
As you can see file:///dev/shm/x/svn1/trunk/x is imported twice. For this
small repository this is not a big issue but when this tree had a deep history
in a large repository you wanted to avoid that.
Robert
[-- Attachment #1.2: svndump.gz --]
[-- Type: application/x-gzip, Size: 616 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [BUG REPORT] git-svn fails to create branches if ssh+svn gets used as protocol.
From: Florian Köberle @ 2009-12-22 9:53 UTC (permalink / raw)
To: git
Hello
I haven't seen a link to a bug tracker so I am sending this bug report
to the mailing list, I hope it's okay.
If you try to run
$ git svn branch foo
in a project using a svn+ssh url, you get the following error log:
Copying svn+ssh://example.org/svn/project/trunk at r1000 to
svn+ssh://me@example.org/svn/project/branches/foo...
Trying to use an unsupported feature: Source and dest appear not to be
in the same repository (src: 'svn+ssh://example.org/svn/project/trunk';
dst: 'svn+ssh://me@example.org/svn/project/branches/foo') at
/home/florian/libexec/git-core/git-svn line 722
It fails as the username is missing in the source url. If you modify the
git-svn script and add the username it works. The bug can be reproduced
with git-svn version 1.6.5.7 (svn 1.5.1).
Best regards,
Florian
^ permalink raw reply
* Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Tomas Carnecky @ 2009-12-22 10:04 UTC (permalink / raw)
To: Git Mailing List
$ git --version
git version 1.6.6.rc4
# Documentation/perf_counter is missing from the master branch, so first
let's find
# out what the last commit was that touched that subdirectory:
$ git log --all -1 -- Documentation/perf_counter
commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Tue Jun 2 21:02:36 2009 +0200
...
M Documentation/perf_counter/builtin-report.c
# Great, let's look in which branch that commit is
$ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
* master
# So, let's look at the log of master and limit it to that subdirectory:
$ git log master -- Documentation/perf_counter
$
# Damn, that doesn't make any sense. In commit 43622 there were files in
that subdirectory, in master they have gone missing and yet log doesn't
show any commit touching that subdirectory?
# Let's try something different:
$ git log --diff-filter=D --name-status --all -- Documentation/perf_counter
...
# Ah, now we're getting somewhere, but still no sight of a commit which
removed for example Documentation/perf_counter/.gitignore
# I'm sure I'm probably just missing a tiny little switch for git-log. I
also tried other combination of name-status, diff-filter etc, but soon
after gave up.
tom
^ 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