* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-26 12:31 UTC (permalink / raw)
To: Dill; +Cc: git
In-Reply-To: <60646ee10901250941s34f7accem1b74fc201e895a41@mail.gmail.com>
Dill <sarpulhu@gmail.com> writes:
> Is there a plan to include translations of the Documentation within
> Git or should they exist outside of the project?
First, you should have mention that you are talking about translating
_Documentation_, because there are at least three areas which can be
translated:
* GUI (gtik and git-gui), which is being done
* Documentation, which leads to translated manpages and HTML docs
* git command messages (but only porcelain, as scripts parse
git command output)
Second, the problem with translating Documentation is twofold. There
is fundamental problem with translated documentation becoming out of
sync (stale) unless you have people ready to follow changes to main
documentation. This is less of a problem with GUI messages, as they
change less frequently, there are shorter, and there is less volume of
them.
And there is technical problem of how to organize translations. With
GUI translations we just use gettext conventions. I don't know any
such convention for docs: there is suffix convention used by Apache to
serve var language files (filename.txt.de, filename.txt.ja.euc-jp),
and there is gettext-like convention of separate directories used by
manpages (en/filename.txt, ja/filename.txt). And there is question
where to put untranslated original... And to enhance Makefile to put
translations in correct place. And possibly alter RPM .spec file to
put translations in separate packages.
So I am not sure if translated documentation should be not maintained
out of tree...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Bruce Stephens @ 2009-01-26 12:15 UTC (permalink / raw)
To: Peter Simons; +Cc: git
In-Reply-To: <87tz7mth3g.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
[...]
> Other modes, such as message-mode, do support that kind of thing
> correctly, so apparently it is possible to configure what the editor
> considers as a paragraph. Is there some Emacs wizard out there who'd
> be kind enough to improve git-mode accordingly?
I suspect this doesn't directly relate to git-mode. What mode does
emacs say you're in at this point? I'm guessing the buffer name is
COMMIT_EDITMSG and the mode is fundamental-mode?
In that case you could stick this in your .emacs if you wanted to use
message-mode:
(setq auto-mode-alist (cons '("COMMIT_EDITMSG" . message-mode) auto-mode-alist))
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 11:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901261220300.14855@racer>
On Mon, Jan 26, 2009 at 12:28:55PM +0100, Johannes Schindelin wrote:
> > Are you aware that gitweb no longer calls "git diff", exactly because
> > of problems caused by calling a porcelain from a script?
>
> As I said: do you really expect people not to forget to upgrade gitweb
> manually when they do "sudo make install" with a new Git version?
Yes.
But my point is that gitweb was _already_ broken, because it was calling
a porcelain, and there were _already_ features that could cause serious
breakage.
So yes, adding a new feature that a user can trigger causes one more
opportunity for breakage. But the solution isn't to never ever add more
features to "git diff". It's to close the avenue by which the new _and_
old breakages are triggered.
> > I don't want to break existing setups, either. But at some point you
> > have to say "this is porcelain, so don't rely on there not being any
> > user-triggered effects in its behavior". If porcelain is cast in stone,
> > then what is the point in differentiating plumbing from porcelain?
>
> Two points there:
>
> - with gitweb, we were the offenders ourselves. So we should give the
> users of gitweb at least _some_ slack.
I'm not sure I agree. I always assumed that since gitweb, git-gui, and
gitk are bundled with git during release that we have _more_ leeway in
making matching changes between them.
Are you sure that you can run random versions of gitweb with random
versions of git in the first place?
> - Concretely for the "porcelain" git diff: This workflow
>
> git diff > my-patch
> <attach and send to somebody>
>
> is probably pretty wide spread. And it is okay, a user is not a script,
> they are very much allowed to use porcelain. And we _would_ break
> expectations there.
Sorry, but what in the world are we supposed to do? Never ever allow the
user to specify diff options to a porcelain because they might impact
the output? A user who sets a config option or a command line option to
impact the output of "git diff" is responsible for how they use "git
diff".
There are already options like this in "git diff". I don't see how one
more changes anything.
> Now, I have another two, fundamental problems with the diff options
> defaults: you are restricting the thing to _one_ set of options, and when
> somebody wants to run without those options, she has to actively _undo_
> them.
Yep, that's what defaults are. And guess what: we _already_ have the
same thing. I have diff.renames set in my ~/.gitconfig. That does
_exactly_ what
git config --global diff.primer -M
would do. It's just a syntax that saves us from having to introduce a
boatload of new variables, one per command line option.
> Remember, sometimes you need another set of options. Like, when I send
> mail to a Git user, I want "-M -C -C", when I send mail to a non-Git user,
> I do not want any additional options (and try to undo "-M -C -C" on the
> command line, good luck), and sometimes it is much easier to see what
> happened with a word diff.
This is a strawman. You have described a scenario where an alias or a
wrapper script is a better fit. Great, then use that mechanism in this
scenario. But that doesn't mean there aren't other scenarios where a
different setup makes more sense (I think Keith's original goal was to
use "-w").
> So what I need are three different sets of diff options.
>
> Guess how well that works with aliases -- we are talking command line
> here after all, right?
Personally, I have always found the suggestion that users simply put
their preferences into an alias like "mydiff" to be a silly one: git has
already taken the obvious good names, so now I am stuck using "git
mydiff" forever and forgetting that "git diff" even exists.
But then, I don't have your "three sets of options" scenario. I just
want one set of defaults. So I don't have a need to name each one, and
having to choose a different name becomes a detriment rather than an
advantage.
However, there are two other drawbacks of aliases that I can think of:
1. They are tied to a specific command, whereas diff options are tied
to the concept of diffing. So now I have to write an alias (with a
new name) for each command:
git config alias.mylog 'log -w'
git config alias.mydiff 'diff -w'
git config alias.myshow 'show -w'
2. They can't change defaults based on the file to be diffed. One of
the things Keith mentioned (and I don't remember if this was
implemented in his patch series) was supporting this for
gitattributes diff drivers. How do I do
git config diff.tex.primer -w
using aliases?
But now you have me defending Keith's proposal, which he should be doing
himself ;P I actually am not that excited about it, and will probably
not use it for anything myself. But I think:
- it lets the user accomplish useful things that would not
otherwise be possible
- supporting it in "git diff" does not create any danger that was not
already there
which means that I have no objection to a clean version being applied.
-Peff
^ permalink raw reply
* Emacs git-mode feature request: support fill-paragraph correctly
From: Peter Simons @ 2009-01-26 11:57 UTC (permalink / raw)
To: git
Hi,
when I choose to commit in Emacs' git mode, I'm prompted to enter a
commit message in a buffer that looks something like this:
Author: Joe Doe <joe.doe@example.org>
--- log message follows this line ---
foo.txt: lots of important changes
Now, when I hit M-q (fill-paragraph), Emacs doesn't recognize that
the "--- log message ..." line ought to be considered a paragraph
separator. As a result, the re-filled buffer is messed up:
Author: Joe Doe <joe.doe@example.org> --- log message follows
this line --- foo.txt: lots of important changes
Other modes, such as message-mode, do support that kind of thing
correctly, so apparently it is possible to configure what the editor
considers as a paragraph. Is there some Emacs wizard out there who'd
be kind enough to improve git-mode accordingly?
Take care,
Peter
^ permalink raw reply
* [PATCHv2 6/6] gitweb: check if-modified-since for feeds
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-6-git-send-email-giuseppe.bilotta@gmail.com>
Offering Last-modified header for feeds is only half the work, even if
we bail out early on HEAD requests. We should also check that same date
against If-modified-since, and bail out early with 304 Not Modified if
that's the case.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8c49c75..f4defb0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6015,7 +6015,25 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- %latest_date = parse_date($latest_commit{'committer_epoch'});
+ my $latest_epoch = $latest_commit{'committer_epoch'};
+ %latest_date = parse_date($latest_epoch);
+ my $if_modified = $cgi->http('IF_MODIFIED_SINCE');
+ if (defined $if_modified) {
+ my $since;
+ if (eval { require HTTP::Date; 1; }) {
+ $since = HTTP::Date::str2time($if_modified);
+ } elsif (eval { require Time::ParseDate; 1; }) {
+ $since = Time::ParseDate::parsedate($if_modified, GMT => 1);
+ }
+ if (defined $since && $latest_epoch <= $since) {
+ print $cgi->header(
+ -type => $content_type,
+ -charset => 'utf-8',
+ -last_modified => $latest_date{'rfc2822'},
+ -status => '304 Not Modified');
+ return;
+ }
+ }
print $cgi->header(
-type => $content_type,
-charset => 'utf-8',
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 5/6] gitweb: last-modified time should be commiter, not author
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-5-git-send-email-giuseppe.bilotta@gmail.com>
The last-modified time header added by RSS to increase cache hits from
readers should be set to the date the repository was last modified. The
author time in this respect is not a good guess because the last commit
might come from a oldish patch.
Use the committer time for the last-modified header to ensure a more
correct guess of the last time the repository was modified.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 756868a..8c49c75 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6015,7 +6015,7 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- %latest_date = parse_date($latest_commit{'author_epoch'});
+ %latest_date = parse_date($latest_commit{'committer_epoch'});
print $cgi->header(
-type => $content_type,
-charset => 'utf-8',
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 4/6] gitweb: rss channel date
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-4-git-send-email-giuseppe.bilotta@gmail.com>
The RSS 2.0 specifications defines not one but _two_ dates for its
channel element! Woohoo! Luckily, it seems that consensus seems to be
that if both are present they should be equal, except for some very
obscure and discouraged cases. Since lastBuildDate would make more sense
for us and pubDate seems to be the most commonly used, we defined both
and make them equal.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6d0fb..756868a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6087,6 +6087,10 @@ XML
"<link>$alt_url</link>\n" .
"</image>\n";
}
+ if (%latest_date) {
+ print "<pubDate>$latest_date{'rfc2822'}</pubDate>\n";
+ print "<lastBuildDate>$latest_date{'rfc2822'}</lastBuildDate>\n";
+ }
print "<generator>gitweb v.$version/$git_version</generator>\n";
} elsif ($format eq 'atom') {
print <<XML;
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 3/6] gitweb: rss feed managingEditor
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-3-git-send-email-giuseppe.bilotta@gmail.com>
The RSS 2.0 specification allows an optional managingEditor tag for the
channel, containing the "email address for person responsible for editorial
content", which is basically the project owner.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d94f50..cc6d0fb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6074,7 +6074,9 @@ XML
print "<title>$title</title>\n" .
"<link>$alt_url</link>\n" .
"<description>$descr</description>\n" .
- "<language>en</language>\n";
+ "<language>en</language>\n" .
+ # project owner is responsible for 'editorial' content
+ "<managingEditor>$owner</managingEditor>\n";
if (defined $logo || defined $favicon) {
# prefer the logo to the favicon, since RSS
# doesn't allow both
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 2/6] gitweb: feed generator metadata
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-2-git-send-email-giuseppe.bilotta@gmail.com>
Add <generator> tag to RSS and Atom feed. Versioning info (gitweb/git
core versions, separated by a literal slash) is stored in the
appropriate attribute for the Atom feed, and in the tag content for the
RSS feed.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f8a5d2e..3d94f50 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6085,6 +6085,7 @@ XML
"<link>$alt_url</link>\n" .
"</image>\n";
}
+ print "<generator>gitweb v.$version/$git_version</generator>\n";
} elsif ($format eq 'atom') {
print <<XML;
<feed xmlns="http://www.w3.org/2005/Atom">
@@ -6111,6 +6112,7 @@ XML
} else {
print "<updated>$latest_date{'iso-8601'}</updated>\n";
}
+ print "<generator version='$version/$git_version'>gitweb</generator>\n";
}
# contents
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 0/6] gitweb: feed metadata enhancements
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
This second revision adds two patches to improve client-side rss
caching: the last-modified header we output is based on commit rather
than creation time, and we now act on if-modified-since request headers.
The last patch requires either HTTP::Date (from libwww-perl) or
Time::ParseDate
Giuseppe Bilotta (6):
gitweb: channel image in rss feed
gitweb: feed generator metadata
gitweb: rss feed managingEditor
gitweb: rss channel date
gitweb: last-modified time should be commiter, not author
gitweb: check if-modified-since for feeds
gitweb/gitweb.perl | 40 ++++++++++++++++++++++++++++++++++++++--
1 files changed, 38 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCHv2 1/6] gitweb: channel image in rss feed
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-1-git-send-email-giuseppe.bilotta@gmail.com>
Define the channel image for the rss feed when the logo or favicon are
defined, preferring the former to the latter. As suggested in the RSS
2.0 specifications, the image's title and link as set to the same as the
channel's.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..f8a5d2e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6075,6 +6075,16 @@ XML
"<link>$alt_url</link>\n" .
"<description>$descr</description>\n" .
"<language>en</language>\n";
+ if (defined $logo || defined $favicon) {
+ # prefer the logo to the favicon, since RSS
+ # doesn't allow both
+ my $img = esc_url($logo || $favicon);
+ print "<image>\n" .
+ "<url>$img</url>\n" .
+ "<title>$title</title>\n" .
+ "<link>$alt_url</link>\n" .
+ "</image>\n";
+ }
} elsif ($format eq 'atom') {
print <<XML;
<feed xmlns="http://www.w3.org/2005/Atom">
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: last-modified time should be commiter, not author
From: Giuseppe Bilotta @ 2009-01-26 11:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901260254.49919.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 2:54 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 25 Jan 2009, Giuseppe Bilotta wrote:
>
>> Subject: [PATCH] gitweb: last-modified time should be commiter, not author
>
> Should be really either "[PATCH 1/2]" or "[PATCH 5/4]" or "[PATCH 5/6]"
> just in case for the next patch, because next patch _depends_ on this
> one, and just in case of threading problem it should be marked as it;
> it also makes easier to apply patches from emails saved as individual
> files each.
I'll resend the whole 6-patch series cc'ing Junio too
>> Use the committer time for the last-modified header to ensure a more
>> correct guess of the last time the repository was modified.
>
> Good catch, good thinking IMHO. Committer date has much better chance
> to be monotonic than author date, and is more close related to
> _publishing_ date (author date is more of _creation_ date).
BTW, it is still not good enough. Consider a remote repo to which you
just pushed some changes you commited last week. The last-modified
date would be last-week, even if you just pushed those changes.
This used to be a problem for us on ruby-rbot because even when
watching the feed we would get no updates on the irc channel (the bot
thought the feed could still be cached). the if-modified thing seems
to have fixed this though.
> Lack signoff; if Junio forges it (or you reply that it should be
> signed off), you can add from me
>
> Acked-by: Jakub Narebski <jnareb@gmail.com>
>
>
> P.S. I wonder what other web interfaces do, for example cgit. I guess
> that web interfaces for other SCMs like SVN::Web, ViewVC etc. do not
> have this problem because they have only one, single date.
HEAD'ing a cgit atom url gives a last-modified date one hour from the
request, it seems. This is actually a typical (and not nice) behaviour
of many CGI scripts.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] gitweb: ensure the default stylesheet is accessible
From: Giuseppe Bilotta @ 2009-01-26 11:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <200901260248.22120.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 2:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
>
>> On some installations the CSS fails to be linked correctly when
>> path_info is enabled, since the link refers to "gitweb.css", whereas it
>> should be "${my_uri}/gitweb.css". Fix by setting the appropriate default
>> in the Makefile.
>
> Why "on some installations"? What does "some" mean? I don't think it
> is something indeterministic: please spell when one can have problems
> with linking CSS file.
The truth is, I haven't the slightest idea. It works fine on my
machine, it doesn't without the patch on ruby-rbot.org, but I really
don't know why.
> Wouldn't it be simpler to deal with problem of base URL when using
> path_info gitweb URLs to add BASE element to HTML head if we use
> path_info? Something like:
>
> if ($ENV{'PATH_INFO'}) { # $path_info is unfortunately stripped
> print qq(<base href="$my_uri">\n);
> }
>
> somewhere in git_header_html() subroutine?
Ah, this might work. I'll test it.
> It is not the same case for git-logo.png and git-favicon.png as for
> gitweb.css? If it is not, please explain why in commit message.
> If it is, then your patch is only partial solution to path_info
> problem.
Oh, interesting, true, I hadn't noticed.
I'll look into the base thing.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Johannes Schindelin @ 2009-01-26 11:28 UTC (permalink / raw)
To: Jeff King; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126111605.GB19993@coredump.intra.peff.net>
Hi,
On Mon, 26 Jan 2009, Jeff King wrote:
> On Mon, Jan 26, 2009 at 11:59:46AM +0100, Johannes Schindelin wrote:
>
> > Just a reminder: we are very conservative when it comes to breaking
> > backwards compatibility. For example, people running (but not upgrading)
> > gitweb who want to upgrade Git may rightfully expect their setups not to
> > be broken for a long time, if ever.
>
> Are you aware that gitweb no longer calls "git diff", exactly because
> of problems caused by calling a porcelain from a script?
As I said: do you really expect people not to forget to upgrade gitweb
manually when they do "sudo make install" with a new Git version?
> I don't want to break existing setups, either. But at some point you
> have to say "this is porcelain, so don't rely on there not being any
> user-triggered effects in its behavior". If porcelain is cast in stone,
> then what is the point in differentiating plumbing from porcelain?
Two points there:
- with gitweb, we were the offenders ourselves. So we should give the
users of gitweb at least _some_ slack.
- Concretely for the "porcelain" git diff: This workflow
git diff > my-patch
<attach and send to somebody>
is probably pretty wide spread. And it is okay, a user is not a script,
they are very much allowed to use porcelain. And we _would_ break
expectations there.
Now, I have another two, fundamental problems with the diff options
defaults: you are restricting the thing to _one_ set of options, and when
somebody wants to run without those options, she has to actively _undo_
them.
Remember, sometimes you need another set of options. Like, when I send
mail to a Git user, I want "-M -C -C", when I send mail to a non-Git user,
I do not want any additional options (and try to undo "-M -C -C" on the
command line, good luck), and sometimes it is much easier to see what
happened with a word diff.
So what I need are three different sets of diff options.
Guess how well that works with aliases -- we are talking command line
here after all, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: check if-modified-since for feeds
From: Giuseppe Bilotta @ 2009-01-26 11:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901260318.05301.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 3:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Should be "[PATCH 2/2]" or similar, just in case.
Yeah, but I was just hacking up ideas as they came. I'm planning a
resend of the whole series, properly numbered and all.
> On Sun, 25 Jun 2009, Giuseppe Bilotta wrote:
>
>> Offering Last-modified header
>
> And skipping generating the body if client uses 'HEAD' request to
> get only Last-Modified header.
>
>> for feeds is only half the work: we should
>> also check that same date against If-modified-since, and bail out early
>> with 304 Not Modified.
>
> Lacks signoff.
Oh yeah.
>> - %latest_date = parse_date($latest_commit{'committer_epoch'});
>> + my $latest_epoch = $latest_commit{'committer_epoch'};
>> + %latest_date = parse_date($latest_epoch);
>> + my $if_modified = $cgi->http('IF_MODIFIED_SINCE');
>> + if (defined $if_modified) {
>> + my $since;
>> + if (eval { require HTTP::Date; 1; }) {
>> + $since = HTTP::Date::str2time($if_modified);
>> + } elsif (eval { require Time::ParseDate; 1; }) {
>> + $since = Time::ParseDate::parsedate($if_modified, GMT => 1);
>> + }
>
> I'd really like to fallback on hand-parsing, as we have to parse date
> in well defined HTTP-date format (RFC-1123, update to RFC-822), which
> I think is what we send in Last-Modified header (or is it RFC-2822?).
>
> But that might be too much work. I like the checking for modules,
> and the fallback cascade, but could you explain why in this order?
Of course, if we have our own parsing code, we don't need the other
modules. I'm way too lazy to write the parsing code myself, although a
copypaste from existing GPL code would do it.
(BTW, I asked on #perl and they think gitweb non-reliance on CPAN
makes for some very horrible code. Of course, IMO the real problem is
that perl's stdlib is way too limited, but that is likely to causes a
language war so I refrained from discussing the thing.)
The order is almost casual, but I suspect that HTTP::Date, from
libwww-perl, is more likely to be available on a webserver than the
other.
>> + if (defined $since && $latest_epoch <= $since) {
>> + print $cgi->header(
>> + -type => $content_type,
>> + -charset => 'utf-8',
>> + -last_modified => $latest_date{'rfc2822'},
>> + -status => 304);
>
> I think we spell HTTP status messages in full (even if it is hidden
> in die_error subroutine), i.e.
>
> + -status => '304 Not Modified');
Can do that.
> P.S. It would be nice to have this mechanism (responding to
> cache-control headers such as If-Modified-Since) for all of gitweb,
> but I guess it is most critical for feeds, which are _polled_.
I thought so too, but then again I couldn't see where last-modified
was used. (Its usage could be added, of course.)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] Reintegrate script
From: Johannes Schindelin @ 2009-01-26 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4ea8mnf.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 26 Jan 2009, Junio C Hamano wrote:
> In a workflow that uses topic branches heavily, you would need to keep
> updating test integration branch(es) all the time. If they are managed
> like my 'next' by merging the tips of topics that have grown since the
> last integration, it is not so difficult. You only need to review
> output from "git branch --no-merged next" to see if there are topics
> that can and needs to be merged to 'next'.
>
> But sometimes it is easier to rebuild a test integration branch from
> scratch all the time, especially if you do not publish it for others to
> build on.
FWIW that is exactly what I am aiming at with my rebase -i -p work.
Ciao,
Dscho
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 11:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901261154330.14855@racer>
On Mon, Jan 26, 2009 at 11:59:46AM +0100, Johannes Schindelin wrote:
> Just a reminder: we are very conservative when it comes to breaking
> backwards compatibility. For example, people running (but not upgrading)
> gitweb who want to upgrade Git may rightfully expect their setups not to
> be broken for a long time, if ever.
>
> So your mentioning gitweb using "git diff" precludes all kind of cute
> games, methinks.
Are you aware that gitweb no longer calls "git diff", exactly because
of problems caused by calling a porcelain from a script?
I don't want to break existing setups, either. But at some point you
have to say "this is porcelain, so don't rely on there not being any
user-triggered effects in its behavior". If porcelain is cast in stone,
then what is the point in differentiating plumbing from porcelain?
And when the line is blurred (as I think it is in several places), then
it has to be dealt with on a case-by-case basis. What is the benefit,
and what is the likelihood and extent of harm?
> And please no "anybody who would do this and that would be nuts" excuses:
> if you want to change something fundamental like this, _you_ have to
> defend it.
>
> It is not acceptable to just shout out what you want and expect those
> affected negatively to do the impact analysis for you.
This message is addressed to me, but I don't know exactly what you think
I'm proposing, failing to defend, or failing to do an impact analysis
for. Or are you speaking generally of the "you" who submit patches?
-Peff
^ permalink raw reply
* Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 11:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901261152320.14855@racer>
On Mon, Jan 26, 2009 at 11:54:26AM +0100, Johannes Schindelin wrote:
> > So if you just want this from the command line, then I think it is safe
> > to have "git diff" always respect "diff.primer", and scripts shouldn't
> > be impacted.
>
> But as Keith made clear, he wanted to use it from _git-gui_. Which
> -- naturally -- _has_ to use plumbing, to guarantee a stable interface.
>
> So "fixing" this in "git diff" is the wrong place; anything else than
> teaching "git gui" to remember user-defined diff options and to use them
> would be a complicator's glove.
I think what you are missing here is that he specifically mentioned the
command line, and I was responding to those comments. There are two
separate problems: default options for command line usage and the
mechanism by which one can set options for things like git-gui.
In this case he was asking specifically about "git diff" from the
command line, so fixing it in there _is_ the place to fix it (the only
other alternative being to make a wrapper or alias).
For the other problem, it _may_ benefit from tool support that would
help porcelains respect a "diff.primer" variable like Keith proposed.
But that has already been discussed elsewhere in the thread, so I'm not
going to repeat it here.
-Peff
^ permalink raw reply
* Re: [PATCH 08/10] run test suite without dashed git-commands in PATH
From: Johannes Schindelin @ 2009-01-26 11:06 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <20090126064004.GA3004@comcast.net>
Hi,
On Sun, 25 Jan 2009, Matthew Ogilvie wrote:
> On Sun, Jan 25, 2009 at 02:59:53AM +0100, Johannes Schindelin wrote:
>
> > On Sat, 24 Jan 2009, Matthew Ogilvie wrote:
> >
> > > .gitignore | 1 +
> > > Makefile | 42 +++++++++++++++++++++++++++++++-----------
> > > t/test-lib.sh | 14 +++++++++++++-
> > > test-bin-wrapper.sh | 12 ++++++++++++
> > > 4 files changed, 57 insertions(+), 12 deletions(-)
> > > create mode 100644 test-bin-wrapper.sh
> >
> > I am strongly opposed to a patch this big, just for something as 3rd
> > class as CVS server faking. We already have a big fallout from all
> > that bending over for Windows support, and I do not like it at all.
> >
> > Note: I do not even have to look further than the diffstat to see that
> > it is wrong.
> >
> > The point is: if cvsserver wants to pretend that it is in a fake bin
> > where almost none of the other Git programs are, fine, let's do that
> > _in the test for cvsserver_.
>
> Since by default git is installed such that most of the dashed-form
> commands are not in a user's default PATH, my thought was that it would
> make sense for the test suite to mimick that environment as much as
> possible.
This sounds very generic, but you hid it in cvsserver-specific patch
series.
So maybe I was wrong to assume that this is cvsserver specific, but then,
you made that mistake rather easy to make.
> This could detect regressions in any installed/tested git script that
> erroneously assumes the dashed form commands are in the PATH, not just
> git-cvsserver.
The major point is that these scripts _will_ run if you call _them_ using
the dash-less form, as GIT_EXEC_PATH will be added to the PATH by the Git
wrapper.
> 3. Perhaps just use symlinks or hardlinks instead of a wrapper
> script. This might have some promise, except that links are more
> likely to fail on windows, and the wrappers generally give you
> more flexibility for testing odd scenarios.
Not likely. Sure as hell.
> 4. The test-bin-wrapper.sh script does not actually need to set
> environment variables (GIT_EXEC_DIT and templates) for purposes
> of this patch. But my thought was that in this form you could
> run things straight out of the test-bin directory to manually try
> out new code without needing to actually install a build or mess
> with the environment variables yourself. It could also be
> extended to handle other global wrapper needs relatively easily,
> such as valgrind.
Umm.
You missed the valgrind patch series.
Ciao,
Dscho
^ permalink raw reply
* backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Johannes Schindelin @ 2009-01-26 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126031206.GB14277@sigill.intra.peff.net>
Hi,
On Sun, 25 Jan 2009, Jeff King wrote:
> 1. Sometimes we blur the line of plumbing and porcelain, where
> functionality is available only through plumbing. For example,
> gitweb until recently called "git diff" because there is no other
> way to diff two arbitrary blobs. But the solution there is, I
> think, to make that functionality available through plumbing. Not
> to disallow enhancements to porcelain.
Just a reminder: we are very conservative when it comes to breaking
backwards compatibility. For example, people running (but not upgrading)
gitweb who want to upgrade Git may rightfully expect their setups not to
be broken for a long time, if ever.
So your mentioning gitweb using "git diff" precludes all kind of cute
games, methinks.
And please no "anybody who would do this and that would be nuts" excuses:
if you want to change something fundamental like this, _you_ have to
defend it.
It is not acceptable to just shout out what you want and expect those
affected negatively to do the impact analysis for you.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Johannes Schindelin @ 2009-01-26 10:54 UTC (permalink / raw)
To: Jeff King; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126031206.GB14277@sigill.intra.peff.net>
Hi,
On Sun, 25 Jan 2009, Jeff King wrote:
> So if you just want this from the command line, then I think it is safe
> to have "git diff" always respect "diff.primer", and scripts shouldn't
> be impacted.
But as Keith made clear, he wanted to use it from _git-gui_. Which
-- naturally -- _has_ to use plumbing, to guarantee a stable interface.
So "fixing" this in "git diff" is the wrong place; anything else than
teaching "git gui" to remember user-defined diff options and to use them
would be a complicator's glove.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-26 10:41 UTC (permalink / raw)
To: Ray Chuan; +Cc: Junio C Hamano, git
In-Reply-To: <be6fef0d0901251752p5b34c053pb24dce8a35b06fce@mail.gmail.com>
Hi,
On Mon, 26 Jan 2009, Ray Chuan wrote:
> On Mon, Jan 26, 2009 at 4:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >> @@ -304,17 +312,7 @@ static void start_fetch_loose(struct
> >> transfer_request *request)
> >>
> >> git_SHA1_Init(&request->c);
> >>
> >> - url = xmalloc(strlen(remote->url) + 50);
> >> ...
> >> - strcpy(request->url, url);
> >> + request->url = get_remote_object_url(remote->url, hex, 0);
> >> ...
> >> - curl_easy_setopt(slot->curl, CURLOPT_URL, url);
> >> + curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
> >
> > The original code gave a separate "url" to setop() but this gives the same
> > string. Does curl_easy_setop() copies the given string away? IOW is this
> > change safe?
> >
>
> curl strdup's it, so this is safe.
I might have mentioned that things like this _need_ to go into the commit
message.
Ciao,
Dscho
^ permalink raw reply
* Re: Translations in Git release?
From: Peter Krefting @ 2009-01-26 10:07 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git
In-Reply-To: <glk19g$2f5$1@ger.gmane.org>
Johannes Gilger:
> My oppinion on localization of software (and its documentation) is
> generally a negative one.
That's the normal response from tech-savvy people. They usually dislike
translations because they think it cannot convey the same ideas as the
original.
However, for a lot of less techy people, having to use software and
read documentation in a non-native language *is* a big hurdle for using
computers. That is especially true when it comes to complex software,
such as Git.
I would very much like to see the core git commands translated. The
command-line svn client already talks Swedish to me (cvs does not,
though), and I would be very happy to teach git the same. I already did
translate git-gui and gitk, which was as much for my own benefit as
others.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] cygwin: Convert paths for html help from posix to windows
From: Steffen Jaeckel @ 2009-01-26 10:05 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Björn Steinbrink, Junio C Hamano, git
In-Reply-To: <497B632B.1060801@ramsay1.demon.co.uk>
-----Original Message-----
From: Ramsay Jones [mailto:ramsay@ramsay1.demon.co.uk]
> Hi Björn,
> I had the same problem. However, rather than modifying git, I created a
> firefox wrapper script (in ~/bin) which used the cygpath command line
> tool to do the path conversion. Also, if you use "git instaweb", you
> also need to filter out http URLs and pass them through un-molested
> by cygpath (it turns http://localhost into http:\localhost).
> My script is clearly a "quick hack" just to get something working for
> me, but you may find it useful as a starting point for your own
> ("proper" ;-) script, so I've included it below.
> HTH,
> Ramsay Jones
Hi Ramsay,
thanks for this idea. I solved the problem by using the bash script
included below.
Cheerz,
Steffen
>sj
#!/bin/sh
#
ff="/cygdrive/c/Programme/Mozilla Firefox/firefox.exe"
while test $# != 0
do
case "$1" in
-version)
echo $("$ff" "-version")
exit 0
;;
-new-tab)
p=
case "$2" in
http*)
p="$2"
;;
*)
# check if file exists
if [ -e "$2" ]
then
p="$(cygpath -w "$2")"
fi
;;
esac
# check if $p has been set, otherwise exit with error
if [ "$p" ]
then
$("$ff" "$p")
exit 0
else
exit 1
fi
;;
esac
shift
done
exit 1
--
Steffen Jaeckel
Steinbeis-Transferzentrum/Steinbeis-Innovationszentrum
Embedded Design und Networking
an der Berufsakademie Lörrach
Poststraße 35, 79423 Heitersheim
Leiter: Prof. Dr.-Ing. Axel Sikora
Phone: +49 7634 6949341
Mob : +49 170 2328968
Fax : +49 7634 5049886
www.stzedn.de
HINWEIS
Das Steinbeis Transferzentrum Embedded Design und Networking (stzedn)
an der Dualen Hochschule Baden-Württemberg/Berufsakademie Lörrach wird
vom 3.-5.3.2009 auf der Embedded World 2009 in Nürnberg mit einem Stand
vertreten sein. Bitte besuchen Sie uns in Halle 12 Stand 322h.
Zentrale:
Steinbeis GmbH & Co. KG für Technologietransfer
Willi-Bleicher-Straße 19, 70174 Stuttgart
Registergericht Stuttgart HRA 12 480
Komplementär: Steinbeis-Verwaltung-GmbH, Registergericht Stuttgart HRB 18715
Geschäftsführer: Prof. Dr. Heinz Trasch, Prof. Dr. Michael Auer
Der Inhalt dieser E-Mail einschließlich aller Anhänge ist vertraulich und
ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der
vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so
beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist.
Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung
zu setzen, sowie die Originalnachricht zu löschen und alle Kopien hiervon zu
vernichten.
This e-mail message including any attachments is for the sole use of the
intended recipient(s) and may contain privileged or confidential information.
Any unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please immediately contact the sender by reply
e-mail and delete the original message and destroy all copies thereof.
^ permalink raw reply
* Re: Translations in Git release?
From: Johannes Gilger @ 2009-01-26 9:54 UTC (permalink / raw)
To: git
In-Reply-To: <60646ee10901250941s34f7accem1b74fc201e895a41@mail.gmail.com>
On 2009-01-25, Dill <sarpulhu@gmail.com> wrote:
> Is there a plan to include translations of the Documentation within
> Git or should they exist outside of the project?
My oppinion on localization of software (and its documentation) is
generally a negative one.
- People who use software like git are (in my experience) people who
have a solid foundation of english, especially when it comes to
computer-topics.
- The effort that goes into translating the vast git documentation and
keeping it up-to-date isn't small, energy better spent in other areas.
- Translating a lot of technical terms into a language like german is
really ugly and not fun to read. I always prefer reading english
documentation and using non-localized versions of programs as it enables
me to easier partake in discussions about it and also enables me to
google for error messages without trying every different language the
message could be in ;)
But thats just me, if you want to start a translation effort knock
yourself out
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ 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