* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Rokos, git
In-Reply-To: <7v4pxqfri7.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:
> Michal Rokos <michal.rokos@nextsoft.cz> writes:
> > On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> >> Michal, is there a reason you do not want to have the version of
> >> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
> >
> > I have no problem with that. I can set $PATH.
> > But then I'd suggest to change magic #!
> > from #!/usr/bin/perl
> > to #!/usr/bin/env perl
> > for *.perl
> >
> > It that what you meant?
>
> No, that is not what I meant.
Though I think you actually should :-)
> Invocation of perl _in_ scripts can be controlled by user's
> PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
> but we configure the scripts we install to have #! pointing at
> the right interpreter as a more cleaner (than using 'env', that
> is) workaround anyway, so #! pointing at PERL_PATH and scripts
> relying on user's $PATH would be the right thing to do.
It's just a question of the target system, so: What is our target? If
we target a fairly recent Unix box, we'd put whatever a user asked for
into the shellbang, and hope that he properly sets $PATH.
If we try to aim at POSIX systems, then first of all, `env' isn't a
hack. It's specified i the POSIX documents, even argument passing is
given. (So if `#!/usr/bin/env perl -w' doesn't work on a HP-UX system,
that's simply broken wrt. POSIX.)
At the maximum, we'd allow the user to supply the location of `env' if
it's not /usr/bin/env, but I guess you'll find a hard time finding a
system where there's no /usr/bin/env... The final killer would be to
explicitely mention the interpreter and install all scripts a-x to
force that :-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Junio C Hamano @ 2006-07-09 20:43 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8rbuk$je5$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> [...] I think you are better off making a list of
>> supported and yet to be supported ones in the comment in
>> configure.ac, and when you want to see if the list got stale
>> over time, grep for '^# Define' from the Makefile and match them
>> up.
>
> This is kind of such a list. Also let me point out that this was in _first_
> patch of the series, as a kind of TODO list.
Yes, you are right -- I spoke too early without realizing what
was going on. The others build on this TODO list to fill the
gap rather nicely.
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Junio C Hamano @ 2006-07-09 20:33 UTC (permalink / raw)
To: Michal Rokos; +Cc: git
In-Reply-To: <200607091441.16161.michal.rokos@nextsoft.cz>
Michal Rokos <michal.rokos@nextsoft.cz> writes:
> Hello,
>
> On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
>> Michal, is there a reason you do not want to have the version of
>> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
>
> I have no problem with that. I can set $PATH.
> But then I'd suggest to change magic #!
> from #!/usr/bin/perl
> to #!/usr/bin/env perl
> for *.perl
>
> It that what you meant?
No, that is not what I meant.
Invocation of perl _in_ scripts can be controlled by user's
PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
but we configure the scripts we install to have #! pointing at
the right interpreter as a more cleaner (than using 'env', that
is) workaround anyway, so #! pointing at PERL_PATH and scripts
relying on user's $PATH would be the right thing to do.
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 19:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8rcu5$je5$2@sea.gmane.org>
Hi,
On Sun, 9 Jul 2006, Jakub Narebski wrote:
> By the way, did this series of patches (adding support for branch and
> remotes configuretion to config file) made into 'next', 'master' or even
> 'pu', or after some discussion it stalled?
The latter. Some parts are there (the remote configuration made it in
AFAIK) but things like the default remote(s) to fetch / push are not.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Jakub Narebski @ 2006-07-09 17:04 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607090011000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sat, 8 Jul 2006, Jakub Narebski wrote:
>
>> moreau francis wrote:
>>
>>> Would it be possible to let the user stick a short explanation
>>> on what a branch is supposed to implement during its creation.
>>
>> It would be possible when/if branch and remotes config would migrate
>> to .git/config. Currently too many I think relies on refs/heads being
>> simple sha1 of "top" commit.
>
> But it does not need a change of existing practice at all! Just add the
> information provided by --topic as branch."pathname".description to the
> config. And make format-patch aware of that.
And make tools remove stale descriptions. I sometimes rename branches "by
hand", as currently there is I think no tool for this...
By the way, did this series of patches (adding support for branch and
remotes configuretion to config file) made into 'next', 'master' or even
'pu', or after some discussion it stalled?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Jakub Narebski @ 2006-07-09 16:47 UTC (permalink / raw)
To: git
In-Reply-To: <7virm7nq7h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Copy description of build configuration variables from the commentary
>> in the top Makefile (from 'next' branch) to configure.ac, splitting
>> them into "autoconf" sections.
>
> I do not see much point in this -- they will become out of sync.
> [...] I think you are better off making a list of
> supported and yet to be supported ones in the comment in
> configure.ac, and when you want to see if the list got stale
> over time, grep for '^# Define' from the Makefile and match them
> up.
This is kind of such a list. Also let me point out that this was in _first_
patch of the series, as a kind of TODO list.
Perhaps those which are done, and those which are not implemented should be
marked differently...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 16:24 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Michal Rokos, Junio C Hamano, Alex Riesen, git
In-Reply-To: <86ejwuuba2.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
>
> Michal> I have no problem with that. I can set $PATH.
> Michal> But then I'd suggest to change magic #!
> Michal> from #!/usr/bin/perl
> Michal> to #!/usr/bin/env perl
> Michal> for *.perl
>
> Michal> It that what you meant?
>
> No, don't do that. Use the path to Perl that they chose during
> configuration because
>
> (a) it might not be the first one in PATH
If you want to execute some binary that's not first in path, you'd
better *always* call that explicit.
> (b) even if it's the first one in *my* path, it might not be the
> first one in *everyone's* path
Communication problem. Machine's administrator should offer a working
git installation. If a user chooses to build his own git, he'd better
make sure that all the environment is properly set-up, too.
> (c) env requires an *extra* fork/exec
Only an extra exec.
> (d) some systems don't have env
Huh? Show me a system that has no /usr/bin/env, but a working POSIX
shell in /bin/sh .
> The env hack is a nice hack, but it's just a hack. Don't
> rely on it when the right thing is nearby.
What's the right thing? The right thing is to explicitely call the
interpreter, not using the shellbang at all.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Linus Torvalds @ 2006-07-09 15:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0607091630110.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 9 Jul 2006, Johannes Schindelin wrote:
>
> On Sun, 9 Jul 2006, Alex Riesen wrote:
>
> > Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> > > The basic idea is that "branch1" should be your current branch, and it
> > > obviously is also expected to match (more or less) the current index. So
> > > you can do a merge by
> > >
> > > - reading in "branch1" into the index:
> > >
> > > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
> >
> > what is "-m" here for?
>
> It means that git-read-tree tries to merge the current index with branch1.
Well, the current index always "merges" by just taking the timestamps from
it. The actual _content_ doesn't matter for the single-tree case.
For the two- and three-tree case, "git-read-tree -m" will verify that the
parts that got changed still _match_ in the index, but for a single-tree
"git-read-tree", there's nothing to match against, just the target, so
the only thing it does is that for matching index/target-tree entries it
will re-use the index timestamps (and other stat info).
Linus
^ permalink raw reply
* [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Alp Toker @ 2006-07-09 14:55 UTC (permalink / raw)
To: git
"The 'text/html' media type [RFC2854] is primarily for HTML, not for
XHTML. In general, this media type is NOT suitable for XHTML."
This patch makes gitweb use content negotiation to conservatively send
pages as Content-Type 'application/xhtml+xml' when the user agent
explicitly claims to support it.
It falls back to 'text/html' even if the user agent appears to
implicitly support 'application/xhtml+xml' due to a '*/*' glob, working
around an insidious bug in Internet Explorer where sending the correct
media type prevents the page from being displayed.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 3e2790c..beb8061 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -290,7 +290,17 @@ sub git_header_html {
}
}
}
- print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
+ my $content_type;
+ # require explicit support from the UA if we are to send the page as
+ # 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
+ # we have to do this because MSIE sometimes globs '*/*', pretending to
+ # support xhtml+xml but choking when it gets what it asked for.
+ if ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) {
+ $content_type = 'application/xhtml+xml';
+ } else {
+ $content_type = 'text/html';
+ }
+ print $cgi->header(-type=>$content_type, -charset => 'utf-8', -status=> $status, -expires => $expires);
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -298,7 +308,7 @@ sub git_header_html {
<!-- git web interface v$version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
<!-- git core binaries version $git_version -->
<head>
-<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
+<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
<link rel="stylesheet" type="text/css" href="$stylesheet"/>
--
1.4.1.gbe4c7
^ permalink raw reply related
* Re: RFH: refactor read-tree
From: Johannes Schindelin @ 2006-07-09 14:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607082011060.5623@g5.osdl.org>
Hi,
On Sat, 8 Jul 2006, Linus Torvalds wrote:
> On Sun, 9 Jul 2006, Johannes Schindelin wrote:
> >
> > I also played a little with git-merge-tree, because it seems so much
> > simpler and easier to refactor. But there is a problem: Either I call it
> > the wrong way, or it does not yet work correctly: I tried
> >
> > git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2
> >
> > with what is in 'next'. But it only showed the _new_ files, not the
> > modified ones.
>
> What git-merge-tree does is to show the _difference_ to "branch1".
I see my problem: branch1 is not the "upstream" branch, but my own. Tsk.
Too easy.
Now, if only merge-tree knew about renames. *sigh*.
> And yes, I agree 100% that "git-read-tree" has become an unholy mess. I
> looked at it, and I think it's unfixable. I considered re-writing it from
> scratch, at least for some specific cases, but I couldn't bring myself to
> do it.
Well, I think that at least the unpack_tree() thing should be relatively
easy to extract. And the rest _should_ be relatively easy to clean up,
provided we introduce a read_tree_options struct, which gets passed around
a la "this" in Java/C++.
Ciao,
Dscho
^ permalink raw reply
* Re: [WIP] Status update on merge-recursive in C
From: Johannes Schindelin @ 2006-07-09 14:41 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1152421230.2103.31.camel@dv>
Hi,
On Sun, 9 Jul 2006, Pavel Roskin wrote:
> Hello, Dscho!
>
> On Sat, 2006-07-08 at 18:42 +0200, Johannes Schindelin wrote:
> > This is just an update for people being interested. Alex and me were
> > busy with that project for a few days now. While it has progressed nicely,
> > there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
>
> That's great. Just a few notes regarding the patch.
>
> Why do you list "recur" twice in all_strategies in the git-merge.sh?
> The second "recur" should probably be "recursive".
This is just make really, really sure that recursive is not tested, but
recur. I would be laughed at if I sent a patch for recur and tested in on
recursive, claiming the patch was fine, right?
Besides, when recur is fixed (for the TODOs as well as for obscure test
cases), there will be no change to git-merge.sh and git-rebase.sh, because
recur will be the new recursive.
> Test for Python in the git-rebase.sh is probably wrong. "recur" doesn't
> need Python - that's the whole point. In fact, if I build git with
> NO_PYTHON, TEST fails in t3401-rebase-partial.sh
Again, I am not concerned about simple bugs as this right now. I want to
fix the big things first. Biggest thing right now: reimplement the
whee^H^H^H^Hread-tree with -i, -m, and no option.
> - variable declarations in the middle of the code (allowed by c99 but
> not by ANSI C) and incomplete function declarations (no "void"). It's
> not C++, let's stick to the C standards.
>From my experience with Java, I know that this declaration in the middle
of the code can make debugging much easier. That is why they are still
there. Like Junio said, once the thing is close to finished, we can fix
these.
> I'm attaching a patch that fixes everything except variable
> declarations.
May I ask you a favour? Can you redo the patch in, say, two weeks? Thank
you!
> It would be great to have a patch that actually removes the old
> "recursive" and makes the new strategy "recursive". I understand it's
> the plan, right?
Yes, sir.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 14:33 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550607082354g62e99216gc72b07055762de3a@mail.gmail.com>
Hi,
On Sun, 9 Jul 2006, Marco Costalba wrote:
> It is possible to add a message (and more) to a tag creating a tag
> object. FWIK this is not allowed for the other refs.
>
> Why there is this (artifical?) difference between tags and the other
> kind of refs?
The tag message is nothing else than a commit message. The
(artificial-but-on-purpose) difference is that you are not supposed to
change a tag ref, whereas a regular ref pointing to a commit is _expected_
to point to some other commit in the future.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Johannes Schindelin @ 2006-07-09 14:31 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com>
Hi,
On Sun, 9 Jul 2006, Ryan Anderson wrote:
> If we can deprecate "run from the source tree", this can go away.
You would make yours truly very sad. Besides, for the tests we need the
functionality anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Johannes Schindelin @ 2006-07-09 14:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <20060709124324.GE5919@steel.home>
Hi,
On Sun, 9 Jul 2006, Alex Riesen wrote:
> Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> > The basic idea is that "branch1" should be your current branch, and it
> > obviously is also expected to match (more or less) the current index. So
> > you can do a merge by
> >
> > - reading in "branch1" into the index:
> >
> > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
>
> what is "-m" here for?
It means that git-read-tree tries to merge the current index with branch1.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] change ent to tree in git-diff documentation
From: Johannes Schindelin @ 2006-07-09 14:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7v1wsvnkj8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 9 Jul 2006, Junio C Hamano wrote:
> Whoever coined <ent> (I do not remember anymore) do you mind
> this in addition to Matthias's patch?
AFAIR it was me. It was meant as a geek's joke from the beginning, and I
even had the pleasure of Linus calling me a total geek.
I do not have any objections against removing it. (AKA Ack.)
Ciao,
Dscho
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Randal L. Schwartz @ 2006-07-09 14:02 UTC (permalink / raw)
To: Michal Rokos; +Cc: Junio C Hamano, Jan-Benedict Glaw, Alex Riesen, git
In-Reply-To: <200607091441.16161.michal.rokos@nextsoft.cz>
>>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
Michal> I have no problem with that. I can set $PATH.
Michal> But then I'd suggest to change magic #!
Michal> from #!/usr/bin/perl
Michal> to #!/usr/bin/env perl
Michal> for *.perl
Michal> It that what you meant?
No, don't do that. Use the path to Perl that they chose during
configuration because
(a) it might not be the first one in PATH
(b) even if it's the first one in *my* path, it might not be the
first one in *everyone's* path
(c) env requires an *extra* fork/exec
(d) some systems don't have env
The env hack is a nice hack, but it's just a hack. Don't
rely on it when the right thing is nearby.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Alex Riesen @ 2006-07-09 12:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607082011060.5623@g5.osdl.org>
Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> The basic idea is that "branch1" should be your current branch, and it
> obviously is also expected to match (more or less) the current index. So
> you can do a merge by
>
> - reading in "branch1" into the index:
>
> GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
what is "-m" here for?
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Michal Rokos @ 2006-07-09 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan-Benedict Glaw, Alex Riesen, git
In-Reply-To: <7vd5cfnkz4.fsf@assigned-by-dhcp.cox.net>
Hello,
On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> Michal, is there a reason you do not want to have the version of
> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
I have no problem with that. I can set $PATH.
But then I'd suggest to change magic #!
from #!/usr/bin/perl
to #!/usr/bin/env perl
for *.perl
It that what you meant?
M.
PS: Please note that
#!/usr/bin/env perl -w
will not work on some platforms (at least on HP-UX)...
--
Michal Rokos
NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone: +420 267 224 311
fax: +420 267 224 307
mobile: +420 736 646 591
e-mail: michal.rokos@nextsoft.cz
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Alex Riesen @ 2006-07-09 12:17 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Junio C Hamano, Michal Rokos, git
In-Reply-To: <f36b08ee0607090309l3cc05b19t44781bbe26013a0b@mail.gmail.com>
Yakov Lerner, Sun, Jul 09, 2006 12:09:30 +0200:
> >Now imagine a non-posix system where an upgrade was made. Amongst
> >other things perl was moved, i.e. from /opt/perl-5.8.8 to
> >/usr/local/{bin,lib}. Suddenly git breaks.
>
> Building new perl for sources never removed,
> by itself, older perls on the system. Did it ever for you ?
No. But a strange package management program will remove the old perl.
^ permalink raw reply
* Re: [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Alp Toker @ 2006-07-09 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtanm5eb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>> It falls back to 'text/html' even if the user agent claims to support
>> 'application/xhtml+xml' by means of a glob in order to work around an
>> insidious Internet Explorer bug.
>
> I do not care much about IE, but...
That makes the two of us. Still, it's probably worth not blocking out IE
in case the need arises to check up on repositories from internet cafes
when on holiday or the like.
>> + my $content_type = ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') ne 0) ? 'application/xhtml+xml' : 'text/html';
>
> 1. I would prefer something like this to be written with if-else,
> not with a conditional expression;
Indeed, this line is a bit unwieldy. Will break it out.
> 2. The "by means of a glob" hack needs to be left as a comment
> in the code to say why;
Good plan.
> 3. Did you really mean to say "ne 0"?
Well spotted. String comparison works, but != would be more sensible.
A revised patch is in the works.
^ permalink raw reply
* Re: [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Junio C Hamano @ 2006-07-09 10:36 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11524381182709-git-send-email-alp@atoker.com>
Alp Toker <alp@atoker.com> writes:
> "The 'text/html' media type [RFC2854] is primarily for HTML, not for
> XHTML. In general, this media type is NOT suitable for XHTML."
>
> This patch makes gitweb use content negotiation to conservatively send
> pages as Content-Type 'application/xhtml+xml' when the user agent
> explicitly claims to support it.
Ok.
> It falls back to 'text/html' even if the user agent claims to support
> 'application/xhtml+xml' by means of a glob in order to work around an
> insidious Internet Explorer bug.
I do not care much about IE, but...
> + my $content_type = ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') ne 0) ? 'application/xhtml+xml' : 'text/html';
1. I would prefer something like this to be written with if-else,
not with a conditional expression;
2. The "by means of a glob" hack needs to be left as a comment
in the code to say why;
3. Did you really mean to say "ne 0"?
^ permalink raw reply
* Re: [PATCH] change ent to tree in git-diff documentation
From: Junio C Hamano @ 2006-07-09 10:24 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FzW4h-00058M-3u@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> This is quite confusing for someone new to git who is not familiar
> with the vocabulary used with git. I don't think a man page is the
> right place for riddles :)
> Additionaly I changed two times 'is' to 'are', I hope this is correct.
I am not attached to <ent> at all, but I do not know if this is
worth it. I suspect there are many other places you need to fix
to make things consistent, and I think the first thing that
should be touched is glossary.txt.
... goes "git grep -w ent", gets quite surprised and comes back ...
Oops. I think you are right and I was wrong saying the above
four lines. It is only git-diff.txt and glossay entry that
talks about <ent>.
Whoever coined <ent> (I do not remember anymore) do you mind
this in addition to Matthias's patch?
-- >8 --
Eradicate <ent>
Technical documentation is not a place for riddles.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 116ddb7..14449ca 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -86,7 +86,7 @@ directory::
ent::
Favorite synonym to "tree-ish" by some total geeks. See
`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
- explanation.
+ explanation. Avoid this term, not to confuse people.
fast forward::
A fast-forward is a special type of merge where you have
^ permalink raw reply related
* Re: Re : [RFC] just an (stupid) idea when creating a new branch
From: Junio C Hamano @ 2006-07-09 10:16 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060709094808.74906.qmail@web25811.mail.ukl.yahoo.com>
moreau francis <francis_moreau2000@yahoo.fr> writes:
> I don't know how it works, but see the set of
> patchs like:
>
> [PATCH 0/3] Summary of the set
> |
> + [PATCH 1/4] blababla
> + [PATCH 2/4] another useful commit
> + [PATCH 3/4] ...
>
> would be great !
Doing the cover letter is primarily a job of the patch
submitter, and I think git-send-email has some support for that.
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Junio C Hamano @ 2006-07-09 10:14 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Alex Riesen, Michal Rokos, git
In-Reply-To: <20060709095114.GQ22573@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> My personal oppinion is to call perl scripts as `perl foo.pl' and thus
> let the user decide (by means of setting $PATH) which perl incarnation
> she wants to use.
Sounds sane, and I was wrong.
We should be able to do that for perl (we cannot in general do
that for GNU tools since some people seem to like renaming them
from foo to gfoo).
Michal, is there a reason you do not want to have the version of
perl you teach git tools via #! lines with PERL_PATH on your $PATH?
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Yakov Lerner @ 2006-07-09 10:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Michal Rokos, git
In-Reply-To: <20060709094630.GB5919@steel.home>
On 7/9/06, Alex Riesen <fork0@t-online.de> wrote:
> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
> > >
> > > some GIT's shell script are using bare 'perl' for perl invocation. It's
> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to
> > > use it everywhere.
> > >
> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> > >
> > > What do you think?
> >
> > Absolutely.
>
> Now imagine a non-posix system where an upgrade was made. Amongst
> other things perl was moved, i.e. from /opt/perl-5.8.8 to
> /usr/local/{bin,lib}. Suddenly git breaks.
Building new perl for sources never removed,
by itself, older perls on the system. Did it ever for you ?
How would installing new perl into new location
break git ? It would only break if you *remove*
old perl, not if you install new perl into new
location, no ?
Yakov
^ 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