* [PATCH] Make t4101-apply-nonl bring along its patches
From: Dennis Stosberg @ 2006-06-17 15:02 UTC (permalink / raw)
To: Michael Somos; +Cc: git, rene.scharfe
In-Reply-To: <200606171446.k5HEkZAx006686@grail.cba.csuohio.edu>
Some versions of "diff" (e.g. on FreeBSD and older Linux systems) do
not support the "\ No newline at end of file" remark and are not
able to generate the patches needed for this test. This lets the
test fail, although git-apply is working perfectly. This patch adds
the pre-generated patches to t/t4100/ and makes the test use them.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
t/t4101-apply-nonl.sh | 6 +-----
t/t4101/diff.0-1 | 6 ++++++
t/t4101/diff.0-2 | 7 +++++++
t/t4101/diff.0-3 | 8 ++++++++
t/t4101/diff.1-0 | 6 ++++++
t/t4101/diff.1-2 | 8 ++++++++
t/t4101/diff.1-3 | 8 ++++++++
t/t4101/diff.2-0 | 7 +++++++
t/t4101/diff.2-1 | 8 ++++++++
t/t4101/diff.2-3 | 7 +++++++
t/t4101/diff.3-0 | 8 ++++++++
t/t4101/diff.3-1 | 8 ++++++++
t/t4101/diff.3-2 | 7 +++++++
13 files changed, 89 insertions(+), 5 deletions(-)
diff --git a/t/t4101-apply-nonl.sh b/t/t4101-apply-nonl.sh
index 26b131d..026fac8 100755
--- a/t/t4101-apply-nonl.sh
+++ b/t/t4101-apply-nonl.sh
@@ -20,14 +20,10 @@ do
for j in 0 1 2 3
do
test $i -eq $j && continue
- diff -u frotz.$i frotz.$j |
- sed -e '
- /^---/s|.*|--- a/frotz|
- /^+++/s|.*|+++ b/frotz|' >diff.$i-$j
cat frotz.$i >frotz
test_expect_success \
"apply diff between $i and $j" \
- "git-apply <diff.$i-$j && diff frotz.$j frotz"
+ "git-apply <../t4101/diff.$i-$j && diff frotz.$j frotz"
done
done
diff --git a/t/t4101/diff.0-1 b/t/t4101/diff.0-1
new file mode 100644
index 0000000..1010a88
--- /dev/null
+++ b/t/t4101/diff.0-1
@@ -0,0 +1,6 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
+ b
++c
diff --git a/t/t4101/diff.0-2 b/t/t4101/diff.0-2
new file mode 100644
index 0000000..36460a2
--- /dev/null
+++ b/t/t4101/diff.0-2
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,2 @@
+ a
+-b
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.0-3 b/t/t4101/diff.0-3
new file mode 100644
index 0000000..b281c43
--- /dev/null
+++ b/t/t4101/diff.0-3
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
+-b
++c
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.1-0 b/t/t4101/diff.1-0
new file mode 100644
index 0000000..f0a2e92
--- /dev/null
+++ b/t/t4101/diff.1-0
@@ -0,0 +1,6 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+ b
+-c
diff --git a/t/t4101/diff.1-2 b/t/t4101/diff.1-2
new file mode 100644
index 0000000..2a440a5
--- /dev/null
+++ b/t/t4101/diff.1-2
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+-b
+-c
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.1-3 b/t/t4101/diff.1-3
new file mode 100644
index 0000000..61aff97
--- /dev/null
+++ b/t/t4101/diff.1-3
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,3 @@
+ a
+-b
+ c
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.2-0 b/t/t4101/diff.2-0
new file mode 100644
index 0000000..c2e71ee
--- /dev/null
+++ b/t/t4101/diff.2-0
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,2 @@
+ a
+-b
+\ No newline at end of file
++b
diff --git a/t/t4101/diff.2-1 b/t/t4101/diff.2-1
new file mode 100644
index 0000000..a66d9fd
--- /dev/null
+++ b/t/t4101/diff.2-1
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
+-b
+\ No newline at end of file
++b
++c
diff --git a/t/t4101/diff.2-3 b/t/t4101/diff.2-3
new file mode 100644
index 0000000..5633c83
--- /dev/null
+++ b/t/t4101/diff.2-3
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
++c
+ b
+\ No newline at end of file
diff --git a/t/t4101/diff.3-0 b/t/t4101/diff.3-0
new file mode 100644
index 0000000..10b1a41
--- /dev/null
+++ b/t/t4101/diff.3-0
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+-c
+-b
+\ No newline at end of file
++b
diff --git a/t/t4101/diff.3-1 b/t/t4101/diff.3-1
new file mode 100644
index 0000000..c799c60
--- /dev/null
+++ b/t/t4101/diff.3-1
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,3 @@
+ a
++b
+ c
+-b
+\ No newline at end of file
diff --git a/t/t4101/diff.3-2 b/t/t4101/diff.3-2
new file mode 100644
index 0000000..f8d1ba6
--- /dev/null
+++ b/t/t4101/diff.3-2
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+-c
+ b
+\ No newline at end of file
--
1.4.0
^ permalink raw reply related
* Re: git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 14:46 UTC (permalink / raw)
To: dennis; +Cc: git, rene.scharfe
Dennis Stosberg wrote :
> I have seen this test failing on FreeBSD 5.3, too. FreeBSD comes with a
> version of "diff" which does not add the "\ No newline at end of file"
> remark. Maybe your "diff" is simply too old. In that case, it's not a
> serious problem because Git uses its own internal diff implementation.
You are exactly right. My "diff" is a bit too old. It was 2.7 and the
latest stable is 2.8.1 which fixes the newline problem.
> The intention of this test is to test git-apply and not the system's
> "diff", so perhaps it should bring along all its patches and not rely
> on the system's "diff" to generate them...
That seems like a good suggestion if it is as you wrote. Thanks for the
information regarding diff and git. Shalom, Michael
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Chris Shoemaker @ 2006-06-17 14:34 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060617134717.GR7766@nowhere.earth>
On Sat, Jun 17, 2006 at 03:47:17PM +0200, Yann Dirson wrote:
> On Sat, Jun 17, 2006 at 09:20:23AM -0400, Chris Shoemaker wrote:
> > >
> > > * when run with "-A" cvsps notices the inconsistency:
> > >
> > > invalid initial_branch for file a, probably from old cache, run with -x.
> >
> > good advice.
> >
> > >
> > >
> > > I have included the current version of your patch in branch "to-check"
> > > in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
> > > look at it closely yet - do you plan to work on this issue ?
> >
> > I wondered if you'd find that. Evidentally, you're being thorough. :)
> >
> > The intent of my patch is only to affect the branch ancestry
> > calculation. IIRC, the patch version is incompatible with cached
> > results from unpatched versions. Hence I would only expect it to work
> > with '-x -A' (unless there was no pre-existing cache file).
>
> All those tests were done with your patch applied, so the cache was
> generated and re-read using the pached version.
Are you saying there was no pre-existing cache file when the patched
version was first run? Did you delete it? If so, then there's a bug
somewhere.
>
> > There's probably some nicer way to handle the cache incompatibility,
> > but my current approach has been to tell people to delete their old
> > cache file or run wih -x. Suggestions are welcome.
>
> If the cache format is changed, this would be a good candidate for the
> "v2" cache format. I already have 2 (incomplete) patches that well
> need to bump the cache format version - see branches multitag (allow
> several tags per patchset) and semicolon (allow semicolons in
> filenames).
IIRC, it's not syntactically incompatible - it's just that the patched
version can tell that it doesn't trust the initial branch
determinations that are stored in the cache file by an unpatched
version.
The complaint is basically, Hey, there's an initial branch
determination already made for this file, but it's not the one I would
have made, so it must have been restored from a cache file that I
didn't make.
-chris
>
> Best regards,
> --
> Yann Dirson <ydirson@altern.org> |
> Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
> | Freedom, Power, Stability, Gratis
> http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Yann Dirson @ 2006-06-17 13:47 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: GIT list, cvsps
In-Reply-To: <20060617132023.GA29452@pe.Belkin>
On Sat, Jun 17, 2006 at 09:20:23AM -0400, Chris Shoemaker wrote:
> >
> > * when run with "-A" cvsps notices the inconsistency:
> >
> > invalid initial_branch for file a, probably from old cache, run with -x.
>
> good advice.
>
> >
> >
> > I have included the current version of your patch in branch "to-check"
> > in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
> > look at it closely yet - do you plan to work on this issue ?
>
> I wondered if you'd find that. Evidentally, you're being thorough. :)
>
> The intent of my patch is only to affect the branch ancestry
> calculation. IIRC, the patch version is incompatible with cached
> results from unpatched versions. Hence I would only expect it to work
> with '-x -A' (unless there was no pre-existing cache file).
All those tests were done with your patch applied, so the cache was
generated and re-read using the pached version.
> There's probably some nicer way to handle the cache incompatibility,
> but my current approach has been to tell people to delete their old
> cache file or run wih -x. Suggestions are welcome.
If the cache format is changed, this would be a good candidate for the
"v2" cache format. I already have 2 (incomplete) patches that well
need to bump the cache format version - see branches multitag (allow
several tags per patchset) and semicolon (allow semicolons in
filenames).
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Chris Shoemaker @ 2006-06-17 13:20 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060617122158.GQ7766@nowhere.earth>
On Sat, Jun 17, 2006 at 02:21:58PM +0200, Yann Dirson wrote:
> [for original thread see
> http://www.gelato.unsw.edu.au/archives/git/0511/11812.html]
>
> Hi Chris,
>
> I was looking at your patch and test script to decide whether to
> include it in my cvsps patch collection, but it seems there are still
> problems:
>
> * when run with "-x" it gives the expected result, even with "-A"
This is expected.
>
> * when run without "-x" and without "-A", the patchset introducing
> file "b" and branch "stable" does not appear, without even a warning
With out "-A" I don't think the patch is operative.
>
> * when run with "-A" cvsps notices the inconsistency:
>
> invalid initial_branch for file a, probably from old cache, run with -x.
good advice.
>
>
> I have included the current version of your patch in branch "to-check"
> in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
> look at it closely yet - do you plan to work on this issue ?
I wondered if you'd find that. Evidentally, you're being thorough. :)
The intent of my patch is only to affect the branch ancestry
calculation. IIRC, the patch version is incompatible with cached
results from unpatched versions. Hence I would only expect it to work
with '-x -A' (unless there was no pre-existing cache file).
I've had one independent report of success from someone who found and
used my patch.
I haven't had to use cvsps recently, so I don't know how much time
I'll have for cvsps hacking, but I'm interested in getting feedback on
my current patch.
There's probably some nicer way to handle the cache incompatibility,
but my current approach has been to tell people to delete their old
cache file or run wih -x. Suggestions are welcome.
-chris
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Dennis Stosberg @ 2006-06-17 13:09 UTC (permalink / raw)
To: Michael Somos; +Cc: rene.scharfe, git
In-Reply-To: <200606171016.k5HAGQ1D005560@grail.cba.csuohio.edu>
Michael Somos wrote:
> A good suggestion, but I am a newbie as you can tell, and would prefer to
> play in a sandbox for some time before I would attempt it. Of more concern
> to me now is a failed test :
>
> > * FAIL 12: apply diff between 3 and 2
> > git-apply <diff.3-2 && diff frotz.2 frotz
> > * failed 2 among 12 test(s)
> > make[1]: *** [t4101-apply-nonl.sh] Error 1
I have seen this test failing on FreeBSD 5.3, too. FreeBSD comes with a
version of "diff" which does not add the "\ No newline at end of file"
remark. Maybe your "diff" is simply too old. In that case, it's not a
serious problem because Git uses its own internal diff implementation.
The intention of this test is to test git-apply and not the system's
"diff", so perhaps it should bring along all its patches and not rely
on the system's "diff" to generate them...
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Yann Dirson @ 2006-06-17 12:21 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: GIT list, cvsps
[for original thread see
http://www.gelato.unsw.edu.au/archives/git/0511/11812.html]
Hi Chris,
I was looking at your patch and test script to decide whether to
include it in my cvsps patch collection, but it seems there are still
problems:
* when run with "-x" it gives the expected result, even with "-A"
* when run without "-x" and without "-A", the patchset introducing
file "b" and branch "stable" does not appear, without even a warning
* when run with "-A" cvsps notices the inconsistency:
invalid initial_branch for file a, probably from old cache, run with -x.
I have included the current version of your patch in branch "to-check"
in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
look at it closely yet - do you plan to work on this issue ?
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Jakub Narebski @ 2006-06-17 11:32 UTC (permalink / raw)
To: git; +Cc: Kay Sievers, Junio C Hamano
gitweb tries now to output correct Content-Type header for
'blob_plain' action; for now text/plain for text files,
appropriate image MIME type for *.png, *.gif and *.jpg/*.jpeg files,
and application/octet-stream for other binary files.
Introduced new configuration variables: $default_blob_plain_mimetype
and $default_text_plain_charset (only 'utf-8' is guaranteed to work
for the latter).
binmode changed to ':raw' in git_blob_plain for output of non-text files.
---
gitweb/gitweb.cgi | 43 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 9d902b7..b37ec50 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -39,12 +39,16 @@ # html text to include at home page
my $home_text = "indextext.html";
# URI of default stylesheet
-my $stylesheet = "gitweb.css";
+my $stylesheet = "gitweb.css";
# source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+# default blob_plain mimetype and default charset for text/plain blob
+my $default_blob_plain_mimetype = 'text/plain';
+my $default_text_plain_charset = 'utf-8'; # can be undefined
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1354,15 +1358,46 @@ sub git_blob {
git_footer_html();
}
+sub git_blob_plain_mimetype {
+ my $fd = shift;
+ my $filename = shift;
+
+ # just in case
+ return $default_blob_plain_mimetype unless $fd;
+
+ if (-T $fd) {
+ return 'text/plain' .
+ ($default_text_plain_charset ? '; charset='.$default_text_plain_charset : '');
+ } elsif (! $filename) {
+ return 'application/octet-stream';
+ } elsif ($filename =~ m/\.png$/i) {
+ return 'image/png';
+ } elsif ($filename =~ m/\.gif$/i) {
+ return 'image/gif';
+ } elsif ($filename =~ m/\.jpe?g$/i) {
+ return 'image/jpeg';
+ } else {
+ return 'application/octet-stream';
+ }
+}
+
sub git_blob_plain {
- my $save_as = "$hash.txt";
+ open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+ my $type = git_blob_plain_mimetype($fd, $file_name);
+
+ # save as filename, even when no $file_name is given
+ my $save_as = "$hash";
if (defined $file_name) {
$save_as = $file_name;
+ } elsif ($type =~ m/^text\//) {
+ $save_as .= '.txt';
}
- print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"$save_as\"");
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+
+ print $cgi->header(-type => "$type", '-content-disposition' => "inline; filename=\"$save_as\"");
undef $/;
+ binmode STDOUT, ':raw' unless $type =~ m/^text\//;
print <$fd>;
+ binmode STDOUT, ':utf8' unless $type =~ m/^text\//;
$/ = "\n";
close $fd;
}
--
1.3.0
^ permalink raw reply related
* Re: git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 10:16 UTC (permalink / raw)
To: rene.scharfe; +Cc: git
Rene Scharfe wrote :
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> You can ignore or delete that file. It is a pax extended global header,
Yes, I knew I could ignore the file right away. I figured it was due
to some new feature of GNU tar.
> was released on 2001-08-29, by the way. May I ask what operating system
> and version you are using?
Mandrake 8,1 for i586. I had not encountered problems with GNU tar 1.13.22
before. A quick google showed this was not a rare problem, but nothing in
the tarball for git-1.4.0 mentioned this problem. I understand that it may
be a rare or nonexistant problem for the target audience of "git", but just
a sentence or two would be enough clue to help out those who may need it.
> It took me a while to realize that your diffs are reversed. It's too
Yes, unfortunately, I did reverse it, but even patch can handle that.
> A good first exercise would be to fetch the git repository, edit Makefile
> and commit your change, and then send a patch to this list -- all using
A good suggestion, but I am a newbie as you can tell, and would prefer to
play in a sandbox for some time before I would attempt it. Of more concern
to me now is a failed test :
> * FAIL 12: apply diff between 3 and 2
> git-apply <diff.3-2 && diff frotz.2 frotz
> * failed 2 among 12 test(s)
> make[1]: *** [t4101-apply-nonl.sh] Error 1
All the other tests worked which is great. Thanks for your reply. Shalom,
Michael
^ permalink raw reply
* [PATCH] Move gitweb style to gitweb.css
From: Jakub Narebski @ 2006-06-17 9:23 UTC (permalink / raw)
To: git; +Cc: Kay Sievers
Move gitweb style from embedded <style> element in gitweb/gitweb.cgi
to external CSS file gitweb/gitweb.css.
---
External CSS file can be downloaded only once and cached.
gitweb/gitweb.cgi | 64 +++--------------------------------------------------
gitweb/gitweb.css | 54 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 60 deletions(-)
create mode 100644 gitweb/gitweb.css
a056a67d019c513754ae33e2b2c6b75da7323b38
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index ea21fbe..9d902b7 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -38,6 +38,9 @@ my $home_link = $my_uri;
# html text to include at home page
my $home_text = "indextext.html";
+# URI of default stylesheet
+my $stylesheet = "gitweb.css";
+
# source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
@@ -257,68 +260,9 @@ sub git_header_html {
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
+<link rel="stylesheet" href="$stylesheet"/>
<title>$title</title>
$rss_link
-<style type="text/css">
-body {
- font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
- margin:10px; background-color:#ffffff; color:#000000;
-}
-a { color:#0000cc; }
-a:hover, a:visited, a:active { color:#880000; }
-div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
-div.page_header a:visited, a.header { color:#0000cc; }
-div.page_header a:hover { color:#880000; }
-div.page_nav { padding:8px; }
-div.page_nav a:visited { color:#0000cc; }
-div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
-div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
-div.page_footer_text { float:left; color:#555555; font-style:italic; }
-div.page_body { padding:8px; }
-div.title, a.title {
- display:block; padding:6px 8px;
- font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
-}
-a.title:hover { background-color: #d9d8d1; }
-div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
-div.log_body { padding:8px 8px 8px 150px; }
-span.age { position:relative; float:left; width:142px; font-style:italic; }
-div.log_link {
- padding:0px 8px;
- font-size:10px; font-family:sans-serif; font-style:normal;
- position:relative; float:left; width:136px;
-}
-div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
-a.list { text-decoration:none; color:#000000; }
-a.list:hover { text-decoration:underline; color:#880000; }
-a.text { text-decoration:none; color:#0000cc; }
-a.text:visited { text-decoration:none; color:#880000; }
-a.text:hover { text-decoration:underline; color:#880000; }
-table { padding:8px 4px; }
-th { padding:2px 5px; font-size:12px; text-align:left; }
-tr.light:hover { background-color:#edece6; }
-tr.dark { background-color:#f6f6f0; }
-tr.dark:hover { background-color:#edece6; }
-td { padding:2px 5px; font-size:12px; vertical-align:top; }
-td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
-div.pre { font-family:monospace; font-size:12px; white-space:pre; }
-div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
-div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
-div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
-a.linenr { color:#999999; text-decoration:none }
-a.rss_logo {
- float:right; padding:3px 0px; width:35px; line-height:10px;
- border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
- color:#ffffff; background-color:#ff6600;
- font-weight:bold; font-family:sans-serif; font-size:10px;
- text-align:center; text-decoration:none;
-}
-a.rss_logo:hover { background-color:#ee5500; }
-span.tag {
- padding:0px 4px; font-size:10px; font-weight:normal;
- background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
-}
-</style>
</head>
<body>
EOF
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
new file mode 100644
index 0000000..6b1fd23
--- /dev/null
+++ b/gitweb/gitweb.css
@@ -0,0 +1,54 @@
+a { color:#0000cc; }
+a:hover, a:visited, a:active { color:#880000; }
+div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
+div.page_header a:visited, a.header { color:#0000cc; }
+div.page_header a:hover { color:#880000; }
+div.page_nav { padding:8px; }
+div.page_nav a:visited { color:#0000cc; }
+div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
+div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
+div.page_footer_text { float:left; color:#555555; font-style:italic; }
+div.page_body { padding:8px; }
+div.title, a.title {
+ display:block; padding:6px 8px;
+ font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
+}
+a.title:hover { background-color: #d9d8d1; }
+div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
+div.log_body { padding:8px 8px 8px 150px; }
+span.age { position:relative; float:left; width:142px; font-style:italic; }
+div.log_link {
+ padding:0px 8px;
+ font-size:10px; font-family:sans-serif; font-style:normal;
+ position:relative; float:left; width:136px;
+}
+div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
+a.list { text-decoration:none; color:#000000; }
+a.list:hover { text-decoration:underline; color:#880000; }
+a.text { text-decoration:none; color:#0000cc; }
+a.text:visited { text-decoration:none; color:#880000; }
+a.text:hover { text-decoration:underline; color:#880000; }
+table { padding:8px 4px; }
+th { padding:2px 5px; font-size:12px; text-align:left; }
+tr.light:hover { background-color:#edece6; }
+tr.dark { background-color:#f6f6f0; }
+tr.dark:hover { background-color:#edece6; }
+td { padding:2px 5px; font-size:12px; vertical-align:top; }
+td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
+div.pre { font-family:monospace; font-size:12px; white-space:pre; }
+div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
+div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
+div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
+a.linenr { color:#999999; text-decoration:none }
+a.rss_logo {
+ float:right; padding:3px 0px; width:35px; line-height:10px;
+ border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
+ color:#ffffff; background-color:#ff6600;
+ font-weight:bold; font-family:sans-serif; font-size:10px;
+ text-align:center; text-decoration:none;
+}
+a.rss_logo:hover { background-color:#ee5500; }
+span.tag {
+ padding:0px 4px; font-size:10px; font-weight:normal;
+ background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
+}
--
1.3.0
^ permalink raw reply related
* Just added Now you could grant your wish Relax with
From: Joanne @ 2006-06-17 7:37 UTC (permalink / raw)
To: git
Good day to you Sir!
Make your girlfriend or wife speechless with increased hardness, richer orgsms and more power in bed
Order our magical stuff now for the amazing prices, and we will dispatch it right away
These brands keep thousands and thousands of their customers pleased worldwide
Check up here: http://www.unpraiselk.com
We offer reliable service and 5 years expirience on the marcket!
^ permalink raw reply
* Re: [PATCH] Update gitweb README: gitweb is now included with git
From: Jakub Narebski @ 2006-06-17 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <200606170857.02111.jnareb@gmail.com>
I'm sorry for doubled email; sending via GMane NNTP (Usenet) interface
produced error, but I haven't noticed that it was sent successfully
regardless.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Rene Scharfe @ 2006-06-17 6:58 UTC (permalink / raw)
To: Michael Somos; +Cc: git
In-Reply-To: <200606170218.k5H2I0o0003192@grail.cba.csuohio.edu>
| I downloaded the git-1.4.0.tar.bz2 recently and encountered a few
| problems.
|
| 1) The untar process creates a stray file "pax_global_header".
| I am using GNU tar v1.13.22 and I get this message :
|
| ======================================================================
| > tar jxf ~/u/source/git-1.4.0.tar.bz2
| tar: pax_global_header: Unknown file type 'g', extracted as normal
| file
| ======================================================================
You can ignore or delete that file. It is a pax extended global header,
containing the git commit ID as a comment. GNU tar started supporting
pax headers with version 1.13.93 (released 2004-02-23). Version 1.13.22
was released on 2001-08-29, by the way. May I ask what operating system
and version you are using?
| 2) The make install process ignores the "prefix=..." argument. I have
| to comment out one line for this :
|
| ======================================================================
| > diff Makefile git-1.4.0/
| 94c94
| < #prefix = $(HOME)
| ---
| > prefix = $(HOME)
| ======================================================================
It took me a while to realize that your diffs are reversed. It's too
early for me, I think I'll go to bed again. :)
Anyway, prefix handling is currently being worked on. Yakov Lerner sent
a patch which seems to make make do what you need.
| 3) The make has a problem with "expat" include and libararies.
| I have to add more lines to the Makefile to handle this like some
| of the other include and libraries :
|
| ======================================================================
| 351,358c351
| < endif
| <
| < ifndef NO_EXPAT
| < ifdef EXPATDIR
| < # This is still problematic -- gcc does not always want -R.
| < ALL_CFLAGS += -I$(EXPATDIR)/include
| < EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
|
| < else
| ---
| > ifndef NO_EXPAT
| 360c353
| < endif
| ---
| > endif
| ======================================================================
Looks sensible, except for the formatting.
| Other than that, it installed okay. I will have to read the docs and
| use it to see how it goes otherwise.
A good first exercise would be to fetch the git repository, edit Makefile
and commit your change, and then send a patch to this list -- all using
git (except the editing part). :-) Care to try that? Please let us know
of any difficulties you may encounter.
Thanks,
René
^ permalink raw reply
* [PATCH] Update gitweb README: gitweb is now included with git
From: Jakub Narebski @ 2006-06-17 6:57 UTC (permalink / raw)
To: git
---
ftp://ftp.kernel.org/pub/software/scm/gitweb/ and
http://www.kernel.org/pub/software/scm/gitweb/ are empty.
http://www.kernel.org/git/?p=git/gitweb.git;a=summary
does not exist.
gitweb/README | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
52fffe22be5fc02045ee630c755dab5713afb4fb
diff --git a/gitweb/README b/gitweb/README
index 3014d73..8d67276 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -3,14 +3,7 @@ GIT web Interface
The one working on:
http://www.kernel.org/git/
-Get the gitweb.cgi by ftp:
- ftp://ftp.kernel.org/pub/software/scm/gitweb/
-
-It reqires the git-core binaries installed on the system:
- http://www.kernel.org/git/?p=git/git.git;a=summary
-
-The gitweb repository is here:
- http://www.kernel.org/git/?p=git/gitweb.git;a=summary
+From the git version 1.4.0 gitweb is bundled with git.
Any comment/question/concern to:
Kay Sievers <kay.sievers@vrfy.org>
--
1.3.0
^ permalink raw reply
* [PATCH] Update gitweb README: gitweb is now included with git
From: Jakub Narebski @ 2006-06-17 6:53 UTC (permalink / raw)
To: git
---
ftp://ftp.kernel.org/pub/software/scm/gitweb/ and
http://www.kernel.org/pub/software/scm/gitweb/ are empty.
http://www.kernel.org/git/?p=git/gitweb.git;a=summary
does not exist.
gitweb/README | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
52fffe22be5fc02045ee630c755dab5713afb4fb
diff --git a/gitweb/README b/gitweb/README
index 3014d73..8d67276 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -3,14 +3,7 @@ GIT web Interface
The one working on:
http://www.kernel.org/git/
-Get the gitweb.cgi by ftp:
- ftp://ftp.kernel.org/pub/software/scm/gitweb/
-
-It reqires the git-core binaries installed on the system:
- http://www.kernel.org/git/?p=git/git.git;a=summary
-
-The gitweb repository is here:
- http://www.kernel.org/git/?p=git/gitweb.git;a=summary
+From the git version 1.4.0 gitweb is bundled with git.
Any comment/question/concern to:
Kay Sievers <kay.sievers@vrfy.org>
--
1.3.0
^ permalink raw reply related
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 5:51 UTC (permalink / raw)
To: Keith Packard; +Cc: Pavel Roskin, git
In-Reply-To: <1150522246.6983.52.camel@neko.keithp.com>
On 6/17/06, Keith Packard <keithp@keithp.com> wrote:
> On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
>
> > >>But the real problem is why does it think the branches are in a loop?
>
> I haven't figured it out yet either; mine didn't detect the loop though,
> it just ended up spinning in the tsort code, unable to compute a valid
> order to execute branches in. Something funky must be up with the
> mozilla branches.
Have you checked parsecvs on the 38 test repositories in the cvs2svn source?
> What this code does is find an order that will 'work' when computing
> branch contents. The requirement is that the 'parent' branch be computed
> before any 'child' branches.
>
> It does this with a nice quadratic algorithm, building a list of 'ready'
> branches who have no 'unready' dependencies in any of the incoming file
> objects. If there are conflicts where one incoming file shows branch 'B'
> as the parent of branch 'A' while another shows branch 'A' as the parent
> of branch 'B', the sorting cannot succeed.
>
> Ideally, I'd figure out a way to eliminate the parent/child relationship
> and just treat the branches as peers with a common ancestor. I haven't
> figure out how to manage that yet; attempting to find the precise
> divergence point where the child forks from the parent remains
> complicated, it seems like trying to do that without a strong
> parent/child relationship would be even more error prone.
>
> Better error messsages here would clearly help discover which branches
> were in conflict, and show the files causing problems.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEk5OGQp8BWwlsTdMRAuyZAKC3URBHR/SWgG7azMqKe3efGNxNZwCdFAVA
> GEIKF8z/MtdbBnKRMDneSH8=
> =ShEA
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Collecting cvsps patches
From: Junio C Hamano @ 2006-06-17 5:50 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060616212334.GN7766@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>
>> > http://ydirson.free.fr/soft/git/cvsps.git
>>
>> I think you need to chmod +x hooks/post-update
>>
>> and then run 'git-update-server-info'.
>
> Unfortunately, I only have FTP access to push to this site, so I have
> to run git-update-server-info myself, and occasionally forget. I'll
> have to bring up-to-date my old cg-ftppush script some day :)
When I only had "serving HTTP, published via FTP" ISP accounts,
I essentially ended up having a bare repository on my local
machine, update it with real git-push (with the post-update hook
there), and copied that to the ISP via lftp batch.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-17 5:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Pavel Roskin, git
In-Reply-To: <9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
> >>But the real problem is why does it think the branches are in a loop?
I haven't figured it out yet either; mine didn't detect the loop though,
it just ended up spinning in the tsort code, unable to compute a valid
order to execute branches in. Something funky must be up with the
mozilla branches.
What this code does is find an order that will 'work' when computing
branch contents. The requirement is that the 'parent' branch be computed
before any 'child' branches.
It does this with a nice quadratic algorithm, building a list of 'ready'
branches who have no 'unready' dependencies in any of the incoming file
objects. If there are conflicts where one incoming file shows branch 'B'
as the parent of branch 'A' while another shows branch 'A' as the parent
of branch 'B', the sorting cannot succeed.
Ideally, I'd figure out a way to eliminate the parent/child relationship
and just treat the branches as peers with a common ancestor. I haven't
figure out how to manage that yet; attempting to find the precise
divergence point where the child forks from the parent remains
complicated, it seems like trying to do that without a strong
parent/child relationship would be even more error prone.
Better error messsages here would clearly help discover which branches
were in conflict, and show the files causing problems.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-17 5:28 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606150440l544455c7r5c52609b360d0f74@mail.gmail.com>
"Yakov Lerner" <iler.ml@gmail.com> writes:
> BTW, is it possible to have git use argv[0] to automatically determine
> the executable_dir without compiled-in paths ?
It is possible and I think we did that some time ago.
We fixed it since then, so that you can migrate away from
assuming bindir==gitexecdir.
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-17 5:26 UTC (permalink / raw)
To: Santi; +Cc: git, Yakov Lerner
In-Reply-To: <8aa486160606150426q19b0a661s@mail.gmail.com>
Santi <sbejar@gmail.com> writes:
> Wed, 14 Jun 2006 22:26 +0300, Yakov Lerner <iler.ml@gmail.com>:
>> Many times, I mistakenly used 'make prefix=... install' where prefix value
>> was different from prefix value during build. This resulted in broken
>> install. This patch adds auto-detection of $prefix change to the Makefile.
>> This results in correct install whenever prefix is changed.
>
> I do this each time I install packages from source. I keep them with
> "stow" and the usual sequence is:
>
> make prefix=/home/santi/usr
> make install prefix=/home/santi/usr/stow/git
> cd /home/santi/usr/stow/
> stow -v git
>
> so with this auto-detection I'll compile some programs twice.
I do not know what "stow" is about, but if it is to allow you to
run make-install to install things in somewhere else, examine
the result, and then move the result to the real location
(implying that you should be able to nuke the "somewhere else"
after you have done so), with the patch, the above sequence
would install the binaries pointing at a wrong directory,
because the second compilation would make them point at the
temporary installation directory ~/usr/stow/git, not the final
location ~/usr/.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 4:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com>
On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
> I had already caught that one, the fix was a few mails back.
> git_dir is an atom and shouldn't be freed with free.
I see it now. My patch was wrong - there is another free(git_dir) in
the same function. Keith, please remove both.
> After five hours I hit this:
> fprintf (stderr, "Error: branch cycle\n");
This is more like a logical error. Maybe you actually have circling
branches due to causality violations or something :-)
Sure, Valgrind would be still useful to make sure it's not something
mundane.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 4:15 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Keith Packard, git
In-Reply-To: <1150517336.9144.8.camel@dv>
On 6/17/06, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:
>
> > Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
>
> Sorry, I was too quick to put blame on you. Maybe glibc can only list
> its own symbols.
>
> I could reproduce the problem trivially with a single file, and here's
> what Valgrind says:
>
> ==11154== Invalid free() / delete / delete[]
> ==11154== at 0x4905423: free (vg_replace_malloc.c:233)
> ==11154== by 0x40C136: git_pack_directory (git.c:620)
> ==11154== by 0x40C1B4: git_rev_list_pack (git.c:639)
> ==11154== by 0x4067DA: main (parsecvs.c:785)
>
>
> git_pack_directory() tries to free() the result of
> git_system_to_string(), which is in turn a result of atom(). My
> understanding is that atoms should not be freed. They are not freed in
> other cases.
>
> Patch:
>
> diff --git a/README b/README
> diff --git a/git.c b/git.c
> index 33b29c7..7312568 100644
> --- a/git.c
> +++ b/git.c
> @@ -617,7 +617,6 @@ git_pack_directory (void)
> }
> free (objects_dir);
> pack_dir = git_format_command ("%s/objects/pack", git_dir);
> - free (git_dir);
> if (!pack_dir)
> return NULL;
> if (access (pack_dir, F_OK) == -1 &&
I had already caught that one, the fix was a few mails back.
git_dir is an atom and shouldn't be freed with free.
After five hours I hit this:
fprintf (stderr, "Error: branch cycle\n");
static rev_ref *
rev_ref_tsort (rev_ref *refs, rev_list *head)
{
rev_ref *done = NULL;
rev_ref **done_tail = &done;
rev_ref *r, **prev;
// fprintf (stderr, "Tsort refs:\n");
while (refs) {
for (prev = &refs; (r = *prev); prev = &(*prev)->next) {
if (rev_ref_is_ready (r->name, head, done)) {
break;
}
}
if (!r) {
fprintf (stderr, "Error: branch cycle\n");
>> hit this test
return NULL;
}
*prev = r->next;
*done_tail = r;
// fprintf (stderr, "\t%s\n", r->name);
r->next = NULL;
done_tail = &r->next;
}
return done;
}
which returned null up to here
if (rev_mode == ExecuteGit && pack_objcount && autopack)
git_rev_list_pack (pack_start, strip);
load_status_next ();
rl = rev_list_merge (head);
>> null to here
if (rl) {
switch (rev_mode) {
case ExecuteGraph:
dump_rev_graph (rl, NULL);
break;
case ExecuteSplits:
dump_splits (rl);
break;
case ExecuteGit:
git_rev_list_commit (rl, strip);
break;
}
}
if (rl)
rev_list_free (rl, 0);
while (head) {
rl = head;
head = head->next;
rev_list_free (rl, 1);
>> tries to free the list, but the list is a loop.
>> after it wraps it will mangle memory
}
discard_atoms ();
rev_free_dirs ();
rev_commit_cleanup ();
git_free_author_map ();
return err;
>>But the real problem is why does it think the branches are in a loop?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 4:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162031o69df27fdje50c88949ed990b5@mail.gmail.com>
On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:
> Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
Sorry, I was too quick to put blame on you. Maybe glibc can only list
its own symbols.
I could reproduce the problem trivially with a single file, and here's
what Valgrind says:
==11154== Invalid free() / delete / delete[]
==11154== at 0x4905423: free (vg_replace_malloc.c:233)
==11154== by 0x40C136: git_pack_directory (git.c:620)
==11154== by 0x40C1B4: git_rev_list_pack (git.c:639)
==11154== by 0x4067DA: main (parsecvs.c:785)
git_pack_directory() tries to free() the result of
git_system_to_string(), which is in turn a result of atom(). My
understanding is that atoms should not be freed. They are not freed in
other cases.
Patch:
diff --git a/README b/README
diff --git a/git.c b/git.c
index 33b29c7..7312568 100644
--- a/git.c
+++ b/git.c
@@ -617,7 +617,6 @@ git_pack_directory (void)
}
free (objects_dir);
pack_dir = git_format_command ("%s/objects/pack", git_dir);
- free (git_dir);
if (!pack_dir)
return NULL;
if (access (pack_dir, F_OK) == -1 &&
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 3:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Keith Packard, git
In-Reply-To: <1150513943.29738.15.camel@dv>
On 6/16/06, Pavel Roskin <proski@gnu.org> wrote:
> Hi, Jon!
>
> On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> > My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
> >
> > Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
> >
> > Error: branch cycle
> > *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> > *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
>
> Obviously, memory corruption. Valgrind is likely to help, but it may
> take 50 hours rather than 5. It may still be worth it. Make sure to
> use the latest version of Valgrind and compile parsecvs without
> optimization with full debug information. If you can get debug info for
> libc, install it (on Fedora: "yum install glibc-debuginfo").
>
> > /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> > parsecvs[0x804dec8]
>
> You see, even some libc symbols can be found, but parsecvs is opaque.
> That's why debug information is useful. Make sure to keep the sources
> around for debugging.
Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
The 'Error: branch cycle' message was critical, the app was in the
process of doing exit clean up with the link list error was found. If
the list is linked in a circle it is likely that the routine freeing
it corrupted memory. So the real error is why did I get 'Error: branch
cycle'.
> --
> Regards,
> Pavel Roskin
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 3:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162002x508ec6ccjbc36e4220ca44fd6@mail.gmail.com>
Hi, Jon!
On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
>
> Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
>
> Error: branch cycle
> *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
Obviously, memory corruption. Valgrind is likely to help, but it may
take 50 hours rather than 5. It may still be worth it. Make sure to
use the latest version of Valgrind and compile parsecvs without
optimization with full debug information. If you can get debug info for
libc, install it (on Fedora: "yum install glibc-debuginfo").
> /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> parsecvs[0x804dec8]
You see, even some libc symbols can be found, but parsecvs is opaque.
That's why debug information is useful. Make sure to keep the sources
around for debugging.
--
Regards,
Pavel Roskin
^ 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