* Re: Shrink "struct object" a bit
From: Linus Torvalds @ 2006-06-17 19:13 UTC (permalink / raw)
To: Philip Pokorny; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <44942176.1070107@mindspring.com>
On Sat, 17 Jun 2006, Philip Pokorny wrote:
>
> A minor thing, but doesn't this mean the "report_missing" message would change
> from:
>
> > Cannot obtain needed object ab12cdef1234567890abcd
> > while processing commit fedcbadeadbeefdeadbe
>
> to
>
> > Cannot obtain needed none ab12cdef1234567890abcd
> > while processing commit fedcbadeadbeefdeadbe
Yeah. I guess you could either just keep the old conditional, or just
change the object type-name for the unspecified mode 0 to something like
"untyped object" which would cause a much more readable errors.
Linus
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Yann Dirson @ 2006-06-17 18:51 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: GIT list, cvsps
In-Reply-To: <20060617143443.GA29602@pe.Belkin>
On Sat, Jun 17, 2006 at 10:34:43AM -0400, Chris Shoemaker wrote:
> Are you saying there was no pre-existing cache file when the patched
> version was first run?
It was the sample script you provided to demonstrate the problem which
showed the new issue: it does a "cvsps -x" first, then runs
git-cvsimport, which runs "cvsps -u". That one does fails. I'm
pretty sure the cache does not exist beforehand, since your script
creates the repo in a temporary directory.
BTW, I'll see about adding a testsuite to cvsps, based on the
framework used by git. All these scriptlets used to exhibit the
various problems have to be kept somewhere.
> Did you delete it? If so, then there's a bug somewhere.
I do think there is a bug somewhere :)
> 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.
OK, thanks for the clarification.
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] git-cvsexportcommit.perl: fix typo
From: Sven Verdoolaege @ 2006-06-17 17:46 UTC (permalink / raw)
To: Yann Dirson; +Cc: junkio, git
In-Reply-To: <20060527163935.474.22794.stgit@gandelf.nowhere.earth>
---
git-cvsexportcommit.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 57088c3..d1051d0 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -134,7 +134,7 @@ foreach my $f (@afiles) {
and $status[0] !~ m/^File: no file /) {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge.\n";
- warn "Status was: $status\n";
+ warn "Status was: $status[0]\n";
}
}
foreach my $f (@mfiles, @dfiles) {
--
1.4.0-dirty
^ permalink raw reply related
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-17 17:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Pavel Roskin, git
In-Reply-To: <9e4733910606162251i65021336m4388d4da715befc9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
On Sat, 2006-06-17 at 01:51 -0400, Jon Smirl wrote:
> Have you checked parsecvs on the 38 test repositories in the cvs2svn source?
Those all run to completion without significant error (there are a
couple of tests with invalid symbol names that currently elicit errors).
I haven't validated that the imports are correct though; spot checks
seem to indicate that the problems encountered during the cvs2svn
development aren't the same as the problems we're finding.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] gitweb: text files for 'blob_plain' action without charset by default
From: Jakub Narebski @ 2006-06-17 16:07 UTC (permalink / raw)
To: git
In-Reply-To: <20060617153540.GI2609@pasky.or.cz>
$default_text_plain_charset is undefined (no specified charset) by
default. Additionally ':raw' layer for binmode is used for outputting file
content.
---
This patch depends on the previous patch in the thread:
"gitweb: safely output binary files for 'blob_plain' action"
Contrary to the previous patch it is not based on other unrelated gitweb.cgi
patches (this changes only line numbers in patch).
gitweb/gitweb.cgi | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
53209981db06a5dde7c59caada279bf63d329da8
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index acac1f4..f082e5d 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -44,7 +44,7 @@ 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
+my $default_text_plain_charset = undef; # was: 'utf-8'
# input validation and dispatch
my $action = $cgi->param('a');
@@ -1451,9 +1451,9 @@ sub git_blob_plain {
print $cgi->header(-type => "$type", '-content-disposition' => "inline; filename=\"$save_as\"");
undef $/;
- binmode STDOUT, ':raw' unless $type =~ m/^text\//;
+ binmode STDOUT, ':raw';
print <$fd>;
- binmode STDOUT, ':utf8' unless $type =~ m/^text\//;
+ binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
$/ = "\n";
close $fd;
}
--
1.3.0
^ permalink raw reply related
* Re: Shrink "struct object" a bit
From: Philip Pokorny @ 2006-06-17 15:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606141630570.5498@g5.osdl.org>
Linus Torvalds wrote:
>This shrinks "struct object" by a small amount, by getting rid of the
>"struct type *" pointer and replacing it with a 3-bit bitfield instead.
>
>@@ -179,9 +179,7 @@ static int loop(void)
> */
> if (! (obj->flags & TO_SCAN)) {
> if (fetch(obj->sha1)) {
>- report_missing(obj->type
>- ? obj->type
>- : "object", obj->sha1);
>+ report_missing(typename(obj->type), obj->sha1);
> return -1;
> }
> }
>
>
>diff --git a/object.c b/object.c
>index 9adc874..0f70890 100644
>--- a/object.c
>+++ b/object.c
>@@ -9,6 +9,10 @@ struct object **objs;
> static int nr_objs;
> int obj_allocs;
>
>+const char *type_names[] = {
>+ "none", "blob", "tree", "commit", "bad"
>+};
>+
>
>
A minor thing, but doesn't this mean the "report_missing" message would
change from:
> Cannot obtain needed object ab12cdef1234567890abcd
> while processing commit fedcbadeadbeefdeadbe
to
> Cannot obtain needed none ab12cdef1234567890abcd
> while processing commit fedcbadeadbeefdeadbe
in some cases? I'm not sure that it's possible for the type value to be
unspecified at this point in the code, but it seemed like the output
from report_missing would be confusing if this ever happened.
:v)
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Petr Baudis @ 2006-06-17 15:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Kay Sievers, Junio C Hamano
In-Reply-To: <200606171332.15591.jnareb@gmail.com>
Dear diary, on Sat, Jun 17, 2006 at 01:32:15PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Introduced new configuration variables: $default_blob_plain_mimetype
> and $default_text_plain_charset (only 'utf-8' is guaranteed to work
> for the latter).
Nah, defaulting to 'utf-8' is horrible - usually, you just don't have a
clue and should refrain from sending any charset information at all, so
I think undef is a much saner default.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [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
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