* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Martin Langhoff (CatalystIT) @ 2006-10-07 5:37 UTC (permalink / raw)
To: ltuikov
Cc: Johannes Schindelin, Junio C Hamano, git, Petr Baudis,
Jakub Narebski, Ryan Anderson, Martyn Smith, Fredrik Kuivinen,
Linus Torvalds
In-Reply-To: <20061006175234.41182.qmail@web31810.mail.mud.yahoo.com>
Luben Tuikov wrote:
>>>Do people have reason to favor annotate over blame? To keep
>>>existing people's scripts working I think we should add a small
>>>amount of code to blame.c to default to compatibility mode when
>>>the command is called as git-annotate at least for a while, but
>>>other than that I do not see much issue against scheduling for
>>>annotate's removal.
>>
>>+1. Although I would leave git-annotate in git, if only to meet
>>expectations of new git users.
>
>
> I agree with Junio's assessment of the situation.
+1 -- I need to test that the switch to git-blame for git-cvsserver
works well for Eclipse end users. Will try and fit that next week
somehow ;-)
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] gitweb: [commit view] Do not suppress commitdiff link in root commit
From: Junio C Hamano @ 2006-10-07 7:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061006165933.4127.72491.stgit@rover>
Petr Baudis <pasky@suse.cz> writes:
> There's no reason for that, the commitdiff view is meaningful for the
> root commit as well and we link to it everywhere else.
It probably is not any more useful than the blob view but I
agree there is no strong reason to supress it, as long as the
commitdiff page is prepared to show the root commit (which I
haven't checked -- if you have --root you should be Ok).
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Panagiotis Issaris @ 2006-10-07 8:30 UTC (permalink / raw)
To: git
In-Reply-To: <20061006220401.a4485d67.seanlkml@sympatico.ca>
Hi,
Thanks for your quick reply!
On Fri, Oct 06, 2006 at 10:04:01PM -0400 or thereabouts, Sean wrote:
> If a server is having problems delivering the Git repo over WEBDAV,
> timeout after two minutes so that a regular http transfer can
> be tried.
> [...]
> Maybe the real solution is just to figure out and fix whatever is
> going on with the WEBDAV server and forget this patch.
I had a quick glance at the Apache2 config on this server:
grep -i dav /etc/apache2/apache2.conf
# redirects for folders with DAV methods.
BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully
Google showed me some bugs occurring on other software where they said
the problems were happening because the redirect weren't handled
correctly. I haven't got a clue about this, but thought mentioning it
might ring someone's bell :)
With friendly regards,
Takis
--
OpenPGP key: http://lumumba.luc.ac.be/takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029
^ permalink raw reply
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Junio C Hamano @ 2006-10-07 8:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610061231.06017.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Rename $githelp_url and $githelp_label to $logo_url and $logo_label to
> be more obvious what they refer to; while at it add commented out
> previous contents (git documentation at kernel.org). Add comment about
> logo size.
>
> Use $cgi->a(...) to generate Git logo link; it automatically escapes
> attribute values when it is needed. Escape href attribute using
> esc_url instead of (incorrect!) esc_html.
In principle, I am not sure renaming the variables is a good
idea in general. Renaming them means you are burning people who
have custom help link defined in their gitweb_config.perl file,
so unless the new variable names are ten times better than the
current one I do not think it is worth doing.
These variables, however, have never been in any official
release nor -rc yet, and have only been there for exactly two
weeks, so if we are going to rename them, we'd better do so now.
And the variables are about the same thing described by $logo
variable, so the new names probably make more sense.
Having said that, I am wondering if it is worth doing something
like this:
sub img_button {
my $it = $_[0];
my @attr = ();
for my $attr (qw(src width height alt class id)) {
next unless exists $it->{$attr};
push @attr, "$attr=\"" . esc_attr($it->{$attr}) . '"';
}
my $img = '<img ' . join(' ', @attr) . ' />';
print $cgi->a({ -href => esc_url($it->{'url'}),
-title => esc_attr($it->{'title'}),
}, $img);
}
our %logo = (
# logo image button
src => '++GITWEB_LOGO++',
width => 72,
height => 27,
alt => 'git logo',
# where that link leads to
url => 'http:/git.or.cz/',
title => 'git homepage',
);
^ permalink raw reply
* Re: [PATCH] gitweb: start to generate PATH_INFO URLs
From: Junio C Hamano @ 2006-10-07 8:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Waitz, git
In-Reply-To: <20061006152925.GP20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> BTW, couple of notes for people who will want to try it: if gitweb.cgi
> serves as your indexfile, this will break; you need to override $my_uri
> in gitweb_config. Also, you need to change the default location of CSS,
> favicon and logo to an absolute URL.
A patch to gitweb/README is in order perhaps?
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Jakub Narebski @ 2006-10-07 9:05 UTC (permalink / raw)
To: git
In-Reply-To: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>
Luben Tuikov wrote:
> +# Convert a string (e.g. a filename) into qtext as defined
> +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
> +sub to_qtext {
> + my $str = shift;
> + $str =~ s/\\/\\\\/g;
> + $str =~ s/\"/\\\"/g;
> + $str =~ s/\r/\\r/g;
> + return $str;
> +}
I'd rather add \n too.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Support hiding of chosen repositories from project list
From: Junio C Hamano @ 2006-10-07 9:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061006182822.9194.78330.stgit@rover>
Petr Baudis <pasky@suse.cz> writes:
> @@ -125,6 +125,7 @@ GITWEB_HOME_LINK_STR = projects
> GITWEB_SITENAME =
> GITWEB_PROJECTROOT = /srv/git
What code base are you working on?
> GITWEB_EXPORT_OK =
> +GITWEB_HIDE_REPO = .hide
> GITWEB_STRICT_EXPORT =
> GITWEB_BASE_URL =
> GITWEB_LIST =
I see how this feature would be useful, but I am not happy to
add random new files under $GIT_DIR/.
^ permalink raw reply
* Re: [PATCH] gitweb: prepare for repositories with packed refs.
From: Junio C Hamano @ 2006-10-07 9:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061006154059.GQ20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> Running -e "$dir/HEAD" to guess if $dir is a git repository does
>> not give us the right answer anymore in such a case.
>
> I think this is a wrong answer to this problem - I guess Cogito's going
> to be confused by HEAD a dangling symlink as well and I'll bet there's
> more places where this will give us trouble. Having HEAD a dangling
> symlink is just wrong and git-pack-refs --prune is buggy if it causes
> that.
I disagree.
When we introduced symref, "cat .git/HEAD" stopped being the way
to read the value of the tip of the current branch, "echo
$commit >.git/HEAD" stopped being the way to update it, and
"rev-parse --verify HEAD" and "update-ref HEAD $commit" were
introduced at the same time as the official alternatives to
support both old and new implementations of .git/HEAD.
The way to find out which branch we are currently on used to be
"readlink .git/HEAD"; that stopped to be true, and we introduced
"symbolic-ref HEAD" as the official alternative to support both
old and new implementation.
The way to see if a random symbolic link whose name happens to
be HEAD is a symref has been to see if it points at a path that
begins with "refs/".
The user has a repository that uses symbolic link HEAD, and is
asking to use pack-refs and is also asking to prune loose refs
that no longer are needed, but definitely is NOT asking to
convert the repository to use symref HEAD. The repository after
"pack-refs --prune" works perfectly well with symbolic link
HEAD, so doing that unasked-for conversion is unnecessary.
And the thing is, if the repository is actively being used, it
is a non issue -- recent-enough git would create a symref by
default. The only place where it matters in practice are public
git repositories initialized using git before mid November last
year, and has never switched the "current branch" ever since
using git of newer vintage.
^ permalink raw reply
* Re: [PATCH] add commit count options to git-shortlog
From: Junio C Hamano @ 2006-10-07 9:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610061520020.2435@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> This patch does 3 things:
>...
> Signed-off-by: Nicolas Pitre <nico@cam.org>
>
> ---
>
> I'm far from a Perl expert. I just hope that Perl gurus out there won't
> throw up too badly.
>
> With this it is possible to have nice statistics quickly, and
> demonstrate that Junio is really our King. ;-)
I only talk passable Perl but I did not find much objectionable
stuff there. But I am not sure how this is useful aside from
stroking your own ego.
Also I get the following.
$ git log --pretty=short v1.4.2..abd6970 |
perl ./git-shortlog.perl -n -s >/dev/null
parse error: input records != output records
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Junio C Hamano @ 2006-10-07 9:46 UTC (permalink / raw)
To: ltuikov; +Cc: git, Petr Baudis
In-Reply-To: <20061006193059.21334.qmail@web31807.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> > +# Convert a string (e.g. a filename) into qtext as defined
>> > +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
>> > +sub to_qtext {
>> > + my $str = shift;
>> > + $str =~ s/\\/\\\\/g;
>> > + $str =~ s/\"/\\\"/g;
>> > + $str =~ s/\r/\\r/g;
>>
>> \r? Not \n?
>
> Yes, \r, not \n.
\r to \\r? Not to \\\r?
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Jakub Narebski @ 2006-10-07 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6xkzpak.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I'd rather add (and use) separate subroutine for quoting/escaping
>> values in HTTP headers, or to be more exact for the filename part
>> of HTTP header "Content-Disposition:". This way if we decide to
>> not replace all characters outside US-ASCII in suggested filename
>> to save with '?', but only qoublequote '"' and linefeed '\n' characters,
>> or even implement RFC 2047 to do the encoding (of course if browsers
>> can read it), we could do this in one place.
>
> Sounds sane. quote_filename?
Luben Tuikov used to_qtext in
"[PATCH] gitweb: Convert Content-Disposition filenames into qtext"
Msg-ID: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>
http://permalink.gmane.org/gmane.comp.version-control.git/28437
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Jakub Narebski @ 2006-10-07 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viriwwmid.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Having said that, I am wondering if it is worth doing something
> like this:
>
>
> sub img_button {
> my $it = $_[0];
> my @attr = ();
> for my $attr (qw(src width height alt class id)) {
> next unless exists $it->{$attr};
> push @attr, "$attr=\"" . esc_attr($it->{$attr}) . '"';
> }
> my $img = '<img ' . join(' ', @attr) . ' />';
> print $cgi->a({ -href => esc_url($it->{'url'}),
> -title => esc_attr($it->{'title'}),
> }, $img);
> }
>
> our %logo = (
> # logo image button
> src => '++GITWEB_LOGO++',
> width => 72,
> height => 27,
> alt => 'git logo',
>
> # where that link leads to
> url => 'http:/git.or.cz/',
> title => 'git homepage',
> );
You forgot to add style, i.e. either id => 'logo' or class => 'logo'.
I'm not sure if it is worth complication. We have similar situation
(although without image) with $home_link and $home_link_str (as with
$logo, $logo_url, $logo_label).
I wonder how many people use non-standard logo image, or non standard
favicon...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: [commit view] Do not suppress commitdiff link in root commit
From: Jakub Narebski @ 2006-10-07 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz88ziwv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> There's no reason for that, the commitdiff view is meaningful for the
>> root commit as well and we link to it everywhere else.
>
> It probably is not any more useful than the blob view but I
> agree there is no strong reason to supress it, as long as the
> commitdiff page is prepared to show the root commit (which I
> haven't checked -- if you have --root you should be Ok).
The commitdiff for root commit is much less useful, I think, and not having
commitdiff link serves as indicator of root (parentless) commit, important
in non-commit views.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Jakub Narebski @ 2006-10-07 10:06 UTC (permalink / raw)
To: git
In-Reply-To: <7vk63ctq47.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>>>> +# Convert a string (e.g. a filename) into qtext as defined
>>>> +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
>>>> +sub to_qtext {
>>>> + my $str = shift;
>>>> + $str =~ s/\\/\\\\/g;
>>>> + $str =~ s/\"/\\\"/g;
Here probably it could be
$str =~ s/"/\\"/g;
>>>> + $str =~ s/\r/\\r/g;
>>>
>>> \r? Not \n?
>>
>> Yes, \r, not \n.
>
> \r to \\r? Not to \\\r?
We want "\r" in suggested filename, not "\
" I think, so it is "\\r".
Otherwise we could use simplier
$str =~ s/([\\"\r])/\\\1/g;
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Make git-send-email detect mbox-style patches more readily
From: Junio C Hamano @ 2006-10-07 10:09 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: git
In-Reply-To: <20061006202414.GR2563@parisc-linux.org>
Matthew Wilcox <matthew@wil.cx> writes:
> Earlier today, I embarrassed myself by trying to construct a patch that
> git-send-email would send, and I missed out the putting
>
> From garbage
>
> line on the front, which led it to send the patches with a
> Subject: From: Matthew Wilcox <matthew@wil.cx>
> line. Bad.
I do not mind this patch per-se, but what do you prepare your
patch with? Straight "diff -pu" between two directories?
quilt?
Since the command deals with two formats (mbox and "send lots of
email"), I am wondering if it would be bettern to loosen the
regexp you used further to catch something like this:
/^[-A-Za-z]+:\s/
The reason why I suspect it would be better to do this loosening
is because I've queued the patch I did yesterday for Len to
allow the prepared patch file to contain custom header fields,
not just the set of headers hardcoded in the send-email script.
The second line in the "send lots of email" format is e-mail
subject, and it is conceivable that would match the above
pattern, so this may not be workable, though.
Maybe something like this?
diff --git a/git-send-email.perl b/git-send-email.perl
index 3f50aba..ed8652c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -472,15 +472,21 @@ foreach my $t (@files) {
my $author_not_sender = undef;
@cc = @initial_cc;
- my $found_mbox = 0;
+ my $input_format = undef;
my $header_done = 0;
$message = "";
while(<F>) {
if (!$header_done) {
- $found_mbox = 1, next if (/^From /);
+ if (/^From /) {
+ $input_format = 'mbox';
+ next;
+ }
chomp;
+ if (!defined $input_format && /^[-A-Za-z]+:\s/) {
+ $input_format = 'mbox';
+ }
- if ($found_mbox) {
+ if (defined $input_format && $input_format eq 'mbox') {
if (/^Subject:\s+(.*)$/) {
$subject = $1;
@@ -502,6 +508,7 @@ foreach my $t (@files) {
# line 1 = cc
# line 2 = subject
# So let's support that, too.
+ $input_format = 'lots';
if (@cc == 0) {
printf("(non-mbox) Adding cc: %s from line '%s'\n",
$_, $_) unless $quiet;
^ permalink raw reply related
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Junio C Hamano @ 2006-10-07 10:15 UTC (permalink / raw)
To: Sean; +Cc: git, Panagiotis Issaris, Nick Hengeveld
In-Reply-To: <BAYC1-PASMTP11CF83A008B0B3BA5F6B15AE100@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> If a server is having problems delivering the Git repo over WEBDAV,
> timeout after two minutes so that a regular http transfer can
> be tried.
>
> ---
>
> http-fetch.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> Not sure if this is the correct fix, but it should improve the situation
> for cloning and fetching from servers like Takis's. When connecting to
> his server WEBDAV doesn't respond after the initial connection. Nothing
> proceeds until the OS connection times out many minutes later.
>
> This patch sets the CURL timeout to two minutes so that things proceed
> sooner. Even with this patch it takes two extra minutes of "dead time"
> to complete all operations; obivously this still sucks.
>
> However, I don't know if the two minute timeout is long enough for
> all cases with a server where WEBDAV is functioning properly.
> Hopefully someone who knows more about Curl can comment and perhaps
> offer another solution.
>
> Maybe the real solution is just to figure out and fix whatever is
> going on with the WEBDAV server and forget this patch.
I think it is prudent to protect the client from a broken server
and it is independent from "fixing" the server side. It would
perhaps make sense to make this overridable somehow but I am not
sure how -- .git/config is too global (the problem would be per
remote site), and having the user to set environment variable
only when going to specific server is too cumbersome to be
useful. This ideally should be a per-remote configuration
item.
> diff --git a/http-fetch.c b/http-fetch.c
> index bc74f30..046245a 100644
> --- a/http-fetch.c
> +++ b/http-fetch.c
> @@ -861,6 +861,7 @@ static int remote_ls(struct alt_base *re
> curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
> curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
> curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
> + curl_easy_setopt(slot->curl, CURLOPT_TIMEOUT, 120);
>
> if (start_active_slot(slot)) {
> run_active_slot(slot);
> --
> 1.4.2.3.gabd697
^ permalink raw reply
* Re: [PATCH] gitweb: prepare for repositories with packed refs.
From: Junio C Hamano @ 2006-10-07 10:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061006154059.GQ20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Having HEAD a dangling
> symlink is just wrong...
While I still disagree with this statement, as a practical
issue, I think it might make sense to have an option to
pack-refs to pack only tags, which are supposed to be mostly
immutable. Or even introduce --all option and make the default
pack only tags. Your branches point at commits waiting to be
updated, and if you have remote tracking branches they are meant
to be updated every time you fetch from that remote; otherwise
you would not be using tracking branches but merging straight
into your branch.
Also you are likely to do pack-refs (or whatever repository-wide
git operations) while on an active branch (be it "master" or
some non-master branch similar to my "next" or "pu"), and for
that reason I suspect packing the current branch is almost
always not very useful. Active branches are by definition
expected to frequently change.
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Junio C Hamano @ 2006-10-07 10:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, ltuikov
In-Reply-To: <eg7u5n$mt9$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>>
>>>>> +# Convert a string (e.g. a filename) into qtext as defined
>>>>> +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
>>>>> +sub to_qtext {
>>>>> + my $str = shift;
>>>>> + $str =~ s/\\/\\\\/g;
>>>>> + $str =~ s/\"/\\\"/g;
>
> Here probably it could be
> $str =~ s/"/\\"/g;
>
>>>>> + $str =~ s/\r/\\r/g;
>>>>
>>>> \r? Not \n?
>>>
>>> Yes, \r, not \n.
>>
>> \r to \\r? Not to \\\r?
>
> We want "\r" in suggested filename, not "\
> " I think, so it is "\\r".
Is that what you guys are attempting to achieve?
If we are trying to suggest a filename that is safe by avoiding
certain characters, I suspect leaving a backslash and dq as-is
is just as bad as leaving a CR in. So if that is the goal here,
I think it might be better and a lot simpler to just replace
each run of bytes not in Portable Filename Character Set with an
underscore '_'.
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Jakub Narebski @ 2006-10-07 11:27 UTC (permalink / raw)
To: git
In-Reply-To: <7viriwsa75.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I think it is prudent to protect the client from a broken server
> and it is independent from "fixing" the server side. It would
> perhaps make sense to make this overridable somehow but I am not
> sure how -- .git/config is too global (the problem would be per
> remote site), and having the user to set environment variable
> only when going to specific server is too cumbersome to be
> useful. This ideally should be a per-remote configuration
> item.
Perhaps use undocumented (hint, hint! for whoever did code this)
per-user ~/.gitconfig?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: prepare for repositories with packed refs.
From: Jakub Narebski @ 2006-10-07 11:31 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wpks9qf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Having HEAD a dangling
>> symlink is just wrong...
>
> While I still disagree with this statement, as a practical
> issue, I think it might make sense to have an option to
> pack-refs to pack only tags, which are supposed to be mostly
> immutable. Or even introduce --all option and make the default
> pack only tags.
+1. I was actually to asck if there is a way to pack only tags,
or perhaps even only true tags (i.e. using tag objects).
It's usually the number of tags that limits performance by being
I/O bound (for example for gitweb), and tags change rather rarely
so modyfying/adding/deleting packed ref need not to be over-optimized
for speed.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Petr Baudis @ 2006-10-07 11:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg7u5n$mt9$1@sea.gmane.org>
Dear diary, on Sat, Oct 07, 2006 at 12:06:31PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> >>>> + $str =~ s/\r/\\r/g;
> >>>
> >>> \r? Not \n?
> >>
> >> Yes, \r, not \n.
> >
> > \r to \\r? Not to \\\r?
>
> We want "\r" in suggested filename, not "\
> " I think, so it is "\\r".
Oh, yes. Lubin wants. It looked sane until I've read it as you
explicitly wrote it. ;-)
That's "obviously" wrong. In qtext, \r means just r, no special
interpretation is done. So we indeed _would_ want "\
". Which is of course a nice trap for buggy browsers so in fact we
obviously do not want that. I think it's not wort the potential problems
to try to carry newlines in the header, so I would just replace that
line with
$str =~ s/[\n\r]/_/g;
as per Junio's suggestion.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Jakub Narebski @ 2006-10-07 12:11 UTC (permalink / raw)
To: git
In-Reply-To: <20061007114602.GX20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sat, Oct 07, 2006 at 12:06:31PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> >>>> + $str =~ s/\r/\\r/g;
>> >>>
>> >>> \r? Not \n?
>> >>
>> >> Yes, \r, not \n.
>> >
>> > \r to \\r? Not to \\\r?
>>
>> We want "\r" in suggested filename, not "\
>> " I think, so it is "\\r".
>
> Oh, yes. Lubin wants. It looked sane until I've read it as you
> explicitly wrote it. ;-)
>
> That's "obviously" wrong. In qtext, \r means just r, no special
> interpretation is done. So we indeed _would_ want "\
> ". Which is of course a nice trap for buggy browsers so in fact we
> obviously do not want that. I think it's not wort the potential problems
> to try to carry newlines in the header, so I would just replace that
> line with
>
> $str =~ s/[\n\r]/_/g;
>
> as per Junio's suggestion.
Bu the way, using the following script:
-- >8 --
#!/usr/bin/perl
use strict;
use warnings;
use CGI qw(:standard :escapeHTML -nosticky);
binmode STDOUT, ':utf8';
our $cgi = new CGI;
print $cgi->header(
-type => 'text/plain',
-charset => 'utf-8',
-content_disposition => 'inline; filename="test\".\\"test\\n.\\\n"');
print "TEST\n";
-- >8 --
I've checked that at least Mozilla 1.7.12 wants to using "\n"
in file name instead of literal eoln.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Support hiding of chosen repositories from project list
From: Petr Baudis @ 2006-10-07 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu02gtqqd.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Oct 07, 2006 at 11:33:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > @@ -125,6 +125,7 @@ GITWEB_HOME_LINK_STR = projects
> > GITWEB_SITENAME =
> > GITWEB_PROJECTROOT = /srv/git
>
> What code base are you working on?
Oops. This is the only custom Makefile change I use at repo.or.cz, it
kind of slipped through. Yes, I should throw it to Makefile.config or
something.
(BTW, I privately consider /pub/git as completely specific to kernel.org
setup and pure evil to have as default; I would much prefer to have the
default something more standard and LHS-compliant like /srv/git (almost)
is. Though I can see the possible pitfalls of changing the default at
this point (though Google says that only tipc.cslab.ericsson.net uses
the same path), this default leads to people inventing own random paths
and chaos reigns: /var/git in Gentoo, /srv/git in SUSE, abomination like
/var/cache/git (!) in Debian, others don't seem to bother with gitweb.)
> > GITWEB_EXPORT_OK =
> > +GITWEB_HIDE_REPO = .hide
> > GITWEB_STRICT_EXPORT =
> > GITWEB_BASE_URL =
> > GITWEB_LIST =
>
> I see how this feature would be useful, but I am not happy to
> add random new files under $GIT_DIR/.
Ok, so it's another thing in the conffile-parser queue.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: [commit view] Do not suppress commitdiff link in root commit
From: Petr Baudis @ 2006-10-07 12:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg7tqd$lie$1@sea.gmane.org>
Dear diary, on Sat, Oct 07, 2006 at 12:00:29PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Junio C Hamano wrote:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> >> There's no reason for that, the commitdiff view is meaningful for the
> >> root commit as well and we link to it everywhere else.
> >
> > It probably is not any more useful than the blob view but I
> > agree there is no strong reason to supress it, as long as the
> > commitdiff page is prepared to show the root commit (which I
> > haven't checked -- if you have --root you should be Ok).
>
> The commitdiff for root commit is much less useful, I think, and not having
> commitdiff link serves as indicator of root (parentless) commit, important
> in non-commit views.
But we don't shor commitdiff _only_ (afaics) in the commit view. ;-)
So it doesn't indicate anything anyway.
I personally don't mind looking at mass-addition patches (something
looking at Debian package diffs teaches you), and it's a quick way to
see all the files being added to the tree, not browse them blob-by-blob.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: prepare for repositories with packed refs.
From: Petr Baudis @ 2006-10-07 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmc8tqqe.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Oct 07, 2006 at 11:33:29AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When we introduced symref, "cat .git/HEAD" stopped being the way
> to read the value of the tip of the current branch, "echo
> $commit >.git/HEAD" stopped being the way to update it, and
> "rev-parse --verify HEAD" and "update-ref HEAD $commit" were
> introduced at the same time as the official alternatives to
> support both old and new implementations of .git/HEAD.
>
> The way to find out which branch we are currently on used to be
> "readlink .git/HEAD"; that stopped to be true, and we introduced
> "symbolic-ref HEAD" as the official alternative to support both
> old and new implementation.
>
> The way to see if a random symbolic link whose name happens to
> be HEAD is a symref has been to see if it points at a path that
> begins with "refs/".
Cogito does
[ ! -s "$_git/HEAD" ] || { _git_head="$(git-symbolic-ref HEAD)"; _git_head="${_git_head#refs/heads/}"; }
in the common initialization code, so that cg-reset works even on
repositories with broken HEAD. It hasn't been an issue in the past since
HEAD as a dangling symlink indeed _has_ been broken HEAD in the past.
That said, at least cg-reset will indeed repair it:
if ! [ -s "$_git/HEAD" ]; then
rm -f "$_git/HEAD"
# XXX: git-symbolic-ref is a weenie and won't do the job at this point.
echo "ref: refs/heads/$_git_head" >"$_git/HEAD"
fi
But it's still not nice.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ 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