* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Frans Klaver @ 2012-02-02 19:44 UTC (permalink / raw)
To: git, gitster, Ben Walton
In-Reply-To: <1328211135-25217-1-git-send-email-bwalton@artsci.utoronto.ca>
Wor_k_ around ...
On Thu, 02 Feb 2012 20:32:15 +0100, Ben Walton
<bwalton@artsci.utoronto.ca> wrote:
> Solaris' /bin/sh was making the IFS setting permanent instead of
> temporary when using it to slurp in credentials in the generated
> 'dump' script of the 'setup helper scripts' test in t0300-credentials.
>
> The stderr file that was being compared to expected-stderr contained the
> following stray line from the credential helper run:
>
> warning: invalid credential line: username foo
>
> To avoid this bug, capture the original IFS and force it to be reset
> after its use is no longer required. For now, this is lighter weight
> than altering which shell these scripts use as their shebang.
>
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
> t/t0300-credentials.sh | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
> index 885af8f..1be3fe2 100755
> --- a/t/t0300-credentials.sh
> +++ b/t/t0300-credentials.sh
> @@ -8,10 +8,12 @@ test_expect_success 'setup helper scripts' '
> cat >dump <<-\EOF &&
> whoami=`echo $0 | sed s/.*git-credential-//`
> echo >&2 "$whoami: $*"
> + OIFS=$IFS
> while IFS== read key value; do
> echo >&2 "$whoami: $key=$value"
> eval "$key=$value"
> done
> + IFS=$OIFS
> EOF
> cat >git-credential-useless <<-\EOF &&
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
^ permalink raw reply
* Re: [PATCH v3 0/4] completion: couple of cleanups
From: Junio C Hamano @ 2012-02-02 19:48 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, SZEDER Gábor, Jonathan Nieder
In-Reply-To: <1328145320-14071-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Felipe Contreras (4):
> completion: be nicer with zsh
> completion: simplify __git_remotes
> completion: remove unused code
> completion: simplify __gitcomp*
My understanding is that the two patches relayed by Jonathan cover the
first three entries, so here is my attempt to reconstruct the last one
without seeing a single bit from the v3 series ;-)
-- >8 --
From: Felipe Contreras <felipe.contreras@gmail.com>
Subject: [PATCH] completion: simplify __gitcomp and __gitcomp_nl implementations
These shell functions are written in an unnecessarily verbose way;
simplify their "conditionally use $<number> after checking $# against
<number>" logic by using shell's built-in conditional substitution
facilities.
Also remove the first of the two assignments to IFS in __gitcomp_nl
that does not have any effect.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
contrib/completion/git-completion.bash | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8dd4e44..1ce1d6e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -495,11 +495,8 @@ fi
# 4: A suffix to be appended to each possible completion word (optional).
__gitcomp ()
{
- local cur_="$cur"
+ local cur_="${3-$cur}"
- if [ $# -gt 2 ]; then
- cur_="$3"
- fi
case "$cur_" in
--*=)
COMPREPLY=()
@@ -524,18 +521,8 @@ __gitcomp ()
# appended.
__gitcomp_nl ()
{
- local s=$'\n' IFS=' '$'\t'$'\n'
- local cur_="$cur" suffix=" "
-
- if [ $# -gt 2 ]; then
- cur_="$3"
- if [ $# -gt 3 ]; then
- suffix="$4"
- fi
- fi
-
- IFS=$s
- COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
+ local IFS=$'\n'
+ COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
__git_heads ()
--
1.7.9.172.ge26ae
^ permalink raw reply related
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Ben Walton @ 2012-02-02 19:48 UTC (permalink / raw)
To: Frans Klaver, gitster; +Cc: git
In-Reply-To: <op.v82g3ura0aolir@keputer>
Excerpts from Frans Klaver's message of Thu Feb 02 14:44:08 -0500 2012:
> Wor_k_ around ...
*face*palm*
Thanks for catching that.
Junio, can you make that tweak if the patch is ok or would you prefer
a new mail?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: how to determine oldest supported version of git
From: Jeff King @ 2012-02-02 19:49 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Neal Kreitzinger, git
In-Reply-To: <20120202192124.GA19873@burratino>
On Thu, Feb 02, 2012 at 01:23:40PM -0600, Jonathan Nieder wrote:
> However, in my experience people interested in product lifetimes more
> often mean "versions the vendor will respond to bug reports about"
> rather than "versions getting updates". If you have discovered a bug
> in an old version of git, even if it is only a couple of major
> releases ago, a good debugging strategy is almost always to try with
> the newest release and see if it still exhibits the bug. If you don't
> try that, people on this list might just try it themselves. If it
> doesn't affect recent releases, I would not be surprised if people on
> this list do not necessarily care much. One can more easily interest
> me at least by pointing out which regression is making it hard to
> upgrade instead.
Agreed. It is very annoying to have somebody report a bug, I (or another
dev) spends time trying to reproduce, and then we find out that it was
actually fixed a year ago.
However, I am much happier if a submitter does that leg-work themselves,
and posts to the list something like:
I am using version a.b.c. It has bug $FOO, which was fixed by $COMMIT
and released in d.e.f [or even "I tried d.e.f and it does not exhibit
the bug"]. This bug fix should get cherry-picked back to a.b.c,
because {it is more important than usual for reason X, upgrading past
a.b.c is not feasible for reason Y, etc}.
Nobody wastes time tracking down the already-fixed bug, and it's
relatively easy to decide whether the cherry-pick is worth the effort
based on the reasoning given.
I know not everybody is capable of complex bisection or writing a
succinct test case. But they can at least try to reproduce with the
latest version and convert "there's a bug in git" to "there's a bug in
this old version of git".
-Peff
^ permalink raw reply
* Re: How best to handle multiple-authorship commits in GIT?
From: Jakub Narebski @ 2012-02-02 19:57 UTC (permalink / raw)
To: Valerie Aurora; +Cc: David Howells, git@vger.kernel.org
In-Reply-To: <9B990DDC-858D-43BA-BF9E-E0C3435354AF@gmail.com>
Valerie Aurora <valerie.aurora@gmail.com> writes:
> [...] I had the same trouble with my set: while I entirely
> rewrote some patches, I still felt Jan Blunck deserved primary
> credit. I don't recall my solution, but I'm fine with mentioning my
> name in the commit message (and I think Jan should get credit too).
That's what various *-by headers are for. Signed-off-by is for
provenance.
Nb. you can search the whole commit message in gitweb, not only author
or committer.
> In general, this is a big problem for motivating contributors in
> other cases. Some maintainers have a habit of trivially rewriting
> patches so that, technically, no line is the same, then taking
> authorship and giving the actual author an ambiguous Signed-off-by.
Maybe it was cause by tools accidentally stealing authorship? With
"git commit --amend --author=..." it is now easy to add authorship
back.
> David hasn't done this here, of course - these are major rewrites -
> but when someone does all the hard work of finding and fixing a
> problem, the credit shouldn't go to the person who prettied it up.
> There is a line in the kernel doc saying how this should be handled,
> suggested by Rusty, but it's not being followed.
Link?
> First class support for multiple authorship would be a big way to
> motivate contributors.
Well, multi-line commit headers were only recently added to git (when
adding signed pull / singed commit stuff), but I think in many places
git assumes single authorship, and it would be hard to change...
There was some workaround that people doing pair programming invented,
IIRC...
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC PATCH] gitweb: use CGI with -utf8
From: Jakub Narebski @ 2012-02-02 20:01 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git, Jakub Narebski
In-Reply-To: <1328136653-20559-1-git-send-email-michal.kiedrowicz@gmail.com>
Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> I noticed that gitweb tries a lot to properly process UTF-8 data, for
> example it prints my name correctly in log and commit information, but
> it echos junk in the search field. It looks like:
>
> Michał Kiedrowicz
>
> I don't know CGI well and I never touched gitewb code, but I found this
> on http://www.lemoda.net/cgi/perl-unicode/index.html:
>
> use CGI '-utf8';
> my $value = params ('input');
>
> I tried it and that fixed my problem. I'm not sure about the
> consequences, maybe someone more experienced in CGI might help?
I have reworded this to form a proper commit message (see
Documentation/SubmittingPatches) and I'll resend this as a reply to
this email.
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index abb5a79..74d45b1 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -10,7 +10,7 @@
> use 5.008;
> use strict;
> use warnings;
> -use CGI qw(:standard :escapeHTML -nosticky);
> +use CGI qw(:standard :escapeHTML -nosticky -utf8);
> use CGI::Util qw(unescape);
> use CGI::Carp qw(fatalsToBrowser set_message);
> use Encode;
> --
Does this actually work for you? Because it doesn't work for me
(perhaps I have too old CGI module: what CGI.pm and what Perl version
do you use?).
See other solution to this in other reply to this email.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Junio C Hamano @ 2012-02-02 20:02 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: git, Andi Kleen, Clemens Buchacher
In-Reply-To: <1328209417-8206-1-git-send-email-tytso@mit.edu>
Theodore Ts'o <tytso@mit.edu> writes:
> diff --git a/INSTALL b/INSTALL
> index 6fa83fe..978ed09 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -28,8 +28,8 @@ set up install paths (via config.mak.autogen), so you can write instead
> If you're willing to trade off (much) longer build time for a later
> faster git you can also do a profile feedback build with
>
> - $ make profile-all
> - # make prefix=... install
> + $ make prefix=... profile-all
> + # make prefix=... PROFILE_USE=t install
Thanks for a patch. How does this compare with what was discussed in the
other thread?
http://thread.gmane.org/gmane.comp.version-control.git/188992/focus=189172
I would wish a solution ideally would support
make PROFILE_BUILD=YesPlease
make PROFILE_BUILD=YesPlease install
or even
echo >>config.mak PROFILE_BUILD
make
su make install
and I think your patch takes us in the right direction.
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Jeff King @ 2012-02-02 20:02 UTC (permalink / raw)
To: Ben Walton; +Cc: git, gitster
In-Reply-To: <1328211135-25217-1-git-send-email-bwalton@artsci.utoronto.ca>
On Thu, Feb 02, 2012 at 02:32:15PM -0500, Ben Walton wrote:
> Solaris' /bin/sh was making the IFS setting permanent instead of
> temporary when using it to slurp in credentials in the generated
> 'dump' script of the 'setup helper scripts' test in t0300-credentials.
Hmm. Presumably you are setting SHELL_PATH, as Solaris /bin/sh would be
useless for running the rest of the tests. Usually scripts inside the
tests use #!$SHELL_PATH, but I often don't bother if it's a simple "even
Solaris /bin/sh could run this" script. But in this case I either
underestimated the complexity of my script or overestimated the quality
of the Solaris /bin/sh.
I wonder if a better solution is to use a known-good shell instead of
trying to work around problems in a bogus shell. Does the patch below
fix it for you?
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 885af8f..edf6547 100755
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
@@ -14,15 +14,15 @@ test_expect_success 'setup helper scripts' '
done
EOF
- cat >git-credential-useless <<-\EOF &&
- #!/bin/sh
+ cat >git-credential-useless <<-EOF &&
+ #!$SHELL_PATH
. ./dump
exit 0
EOF
chmod +x git-credential-useless &&
- cat >git-credential-verbatim <<-\EOF &&
- #!/bin/sh
+ echo "#!$SHELL_PATH" >git-credential-verbatim &&
+ cat >>git-credential-verbatim <<-\EOF &&
user=$1; shift
pass=$1; shift
. ./dump
^ permalink raw reply related
* Re: gitweb showing slash r at the end of line
From: Jakub Narebski @ 2012-02-02 20:04 UTC (permalink / raw)
To: Ondra Medek; +Cc: git
In-Reply-To: <1327939743099-7237025.post@n2.nabble.com>
Ondra Medek <xmedeko@gmail.com> writes:
> Thanks for pointing out the [gitweb] section of the config. Should I try to
> make the patch or someone else more skilled would pick this up?
I'll try to pick it up, if you wouldn't be able to...
...subject to finding time for this, of course.
--
Jakub Narebski
^ permalink raw reply
* [PATCH/RFC (version A)] gitweb: use CGI with -utf8 to process Unicode query parameters correctly
From: Jakub Narebski @ 2012-02-02 20:08 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <m37h05c8c1.fsf@localhost.localdomain>
Gitweb tries hard to properly process UTF-8 data, by marking output
from git commands and contents of files as UTF-8 with to_utf8()
subroutine. This ensures that gitweb would print correctly UTF-8
e.g. in 'log' and 'commit' views.
Unfortunately it misses another source of potentially Unicode input,
namely query parameters. The result is that one cannot search for a
string containing characters outside US-ASCII. For example searching
for "Michał Kiedrowicz" (containing letter 'ł' - LATIN SMALL LETTER L
WITH STROKE, with Unicode codepoint U+0142, represented with 0xc5 0x82
bytes in UTF-8 and percent-encoded as %C5%81) result in the following
incorrect data in search field
Michał Kiedrowicz
This is caused by CGI by default treating '0xc5 0x82' bytes as two
characters in Perl legacy encoding latin-1 (iso-8859-1), because 's'
query parameter is not processed explicitly as UTF-8 encoded string.
According to "Using Unicode in a Perl CGI script" article on
http://www.lemoda.net/cgi/perl-unicode/index.html the simplest
solution is to just import '-utf8' pragma for CGI module:
use CGI '-utf8';
my $value = params('input');
According to CGI module documentation, the '-utf8' pragma may cause
problems with POST requests containing binary files... but gitweb
currently do not use POST requests at all, so this should be not a
problem now.
Alternate solution would be to explicity decode query parameters when
storing them in %input_params (and perhaps also path_info).
[jn: reworded / rewritten commit message]
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..a7441ef 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -10,7 +10,7 @@
use 5.008;
use strict;
use warnings;
-use CGI qw(:standard :escapeHTML -nosticky);
+use CGI qw(:standard :escapeHTML -nosticky -utf8);
use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser set_message);
use Encode;
--
1.7.6
^ permalink raw reply related
* Re: How to find and analyze bad merges?
From: Junio C Hamano @ 2012-02-02 20:09 UTC (permalink / raw)
To: norbert.nemec; +Cc: git
In-Reply-To: <jgdjd1$5mn$1@dough.gmane.org>
"norbert.nemec" <norbert.nemec@native-instruments.de> writes:
>> Bisect?
>
> This is not the point: My colleague knew exactly which commit
> contained the bugfix. The trouble was finding out why this bugfix
> disappeared even though everything indicated that it was cleanly
> merged into the current branch.
Then again "Bisect?"
I wasn't and I am not suggesting to use Bisect to find the original fix. I
was suggesting to use Bisect to find the _merge_ you were looking for.
^ permalink raw reply
* [PATCH/RFC (version B)] gitweb: Allow UTF-8 encoded CGI query parameters and path_info
From: Jakub Narebski @ 2012-02-02 20:10 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <m37h05c8c1.fsf@localhost.localdomain>
Gitweb tries hard to properly process UTF-8 data, by marking output
from git commands and contents of files as UTF-8 with to_utf8()
subroutine. This ensures that gitweb would print correctly UTF-8
e.g. in 'log' and 'commit' views.
Unfortunately it misses another source of potentially Unicode input,
namely query parameters. The result is that one cannot search for a
string containing characters outside US-ASCII. For example searching
for "Michał Kiedrowicz" (containing letter 'ł' - LATIN SMALL LETTER L
WITH STROKE, with Unicode codepoint U+0142, represented with 0xc5 0x82
bytes in UTF-8 and percent-encoded as %C5%81) result in the following
incorrect data in search field
Michał Kiedrowicz
This is caused by CGI by default treating '0xc5 0x82' bytes as two
characters in Perl legacy encoding latin-1 (iso-8859-1), because 's'
query parameter is not processed explicitly as UTF-8 encoded string.
The solution used here follows "Using Unicode in a Perl CGI script"
article on http://www.lemoda.net/cgi/perl-unicode/index.html:
use CGI;
use Encode 'decode_utf8;
my $value = params('input');
$value = decode_utf8($value);
This is done when filling %input_params hash; this required to move
from explicit $cgi->param(<label>) to $input_params{<name>} in a few
places.
Alternate solution would be to simply use the '-utf8' pragma (via
"use CGI '-utf8';"), but according to CGI.pm documentation it may
cause problems with POST requests containing binary files... and
it doesn't work with old CGI.pm version 3.10 from Perl v5.8.6.
Noticed-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..55b2c24 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -52,7 +52,7 @@ sub evaluate_uri {
# as base URL.
# Therefore, if we needed to strip PATH_INFO, then we know that we have
# to build the base URL ourselves:
- our $path_info = $ENV{"PATH_INFO"};
+ our $path_info = decode_utf8($ENV{"PATH_INFO"});
if ($path_info) {
if ($my_url =~ s,\Q$path_info\E$,, &&
$my_uri =~ s,\Q$path_info\E$,, &&
@@ -816,9 +816,9 @@ sub evaluate_query_params {
while (my ($name, $symbol) = each %cgi_param_mapping) {
if ($symbol eq 'opt') {
- $input_params{$name} = [ $cgi->param($symbol) ];
+ $input_params{$name} = [ map { decode_utf8($_) } $cgi->param($symbol) ];
} else {
- $input_params{$name} = $cgi->param($symbol);
+ $input_params{$name} = decode_utf8($cgi->param($symbol));
}
}
}
@@ -2767,7 +2767,7 @@ sub git_populate_project_tagcloud {
}
my $cloud;
- my $matched = $cgi->param('by_tag');
+ my $matched = $input_params{'ctag'};
if (eval { require HTML::TagCloud; 1; }) {
$cloud = HTML::TagCloud->new;
foreach my $ctag (sort keys %ctags_lc) {
@@ -5282,7 +5282,7 @@ sub git_project_list_body {
my $check_forks = gitweb_check_feature('forks');
my $show_ctags = gitweb_check_feature('ctags');
- my $tagfilter = $show_ctags ? $cgi->param('by_tag') : undef;
+ my $tagfilter = $show_ctags ? $input_params{'ctag'} : undef;
$check_forks = undef
if ($tagfilter || $searchtext);
@@ -6197,7 +6197,7 @@ sub git_tag {
sub git_blame_common {
my $format = shift || 'porcelain';
- if ($format eq 'porcelain' && $cgi->param('js')) {
+ if ($format eq 'porcelain' && $input_params{'javascript'}) {
$format = 'incremental';
$action = 'blame_incremental'; # for page title etc
}
--
1.7.6
^ permalink raw reply related
* Re: [PATCH/RFC (version A)] gitweb: use CGI with -utf8 to process Unicode query parameters correctly
From: Jakub Narebski @ 2012-02-02 20:11 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <201202022108.51353.jnareb@gmail.com>
> According to "Using Unicode in a Perl CGI script" article on
> http://www.lemoda.net/cgi/perl-unicode/index.html the simplest
> solution is to just import '-utf8' pragma for CGI module:
>
> use CGI '-utf8';
> my $value = params('input');
[...]
> ---
Except it doesn't work for me...
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 9cf7e71..a7441ef 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -10,7 +10,7 @@
> use 5.008;
> use strict;
> use warnings;
> -use CGI qw(:standard :escapeHTML -nosticky);
> +use CGI qw(:standard :escapeHTML -nosticky -utf8);
> use CGI::Util qw(unescape);
> use CGI::Carp qw(fatalsToBrowser set_message);
> use Encode;
> --
> 1.7.6
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Ted Ts'o @ 2012-02-02 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andi Kleen, Clemens Buchacher
In-Reply-To: <7vvcnpuhpo.fsf@alter.siamese.dyndns.org>
On Thu, Feb 02, 2012 at 12:02:27PM -0800, Junio C Hamano wrote:
>
> Thanks for a patch. How does this compare with what was discussed in the
> other thread?
>
> http://thread.gmane.org/gmane.comp.version-control.git/188992/focus=189172
I wasn't aware of this other approach when I created this patch (I
must have missed the e-mail thread, sorry).
One of the reasons why I did it this way was for more flexibility. I
wanted to be able to do:
$ make PROFILE_GEN=YesPlease PROFILE_DIR=/var/cache/FDO all
# make PROFILE_GEN=YesPlease PROFILE_DIR=/var/cache/FDO install
run a bunch of git commands on various git repositories to get
real-life usage...
Then do...
$ make PROFILE_USE=YesPlease PROFILE_DIR=/var/cache/FDO all
# make PROFILE_GEN=YesPlease PROFILE_DIR=/var/cache/FDO install
But for many people they would probably be satisfied with something
that builds git using a single magic recipe, even if they give up some
fractional performance improvement (keep in mind that the feedback
directed optimization seems to buy you only a single digit percentage
improvement according according to Andi's original experiment; I just
got interested in this more for amusement value than any thought that
it would save me serious amounts of time).
> I would wish a solution ideally would support
>
> make PROFILE_BUILD=YesPlease
> make PROFILE_BUILD=YesPlease install
At least in theory, it should be possible to have something which
supports both PROFILE_GEN/PROFILE_USE as well as a combined
PROFILE_BUILD.
The hard part is that PROFILE_BUILD requires a multi-pass process; you
need to build with one set of CFLAGS, then run the sample workload to
get the data for your feedback directed optimizations, and then re-run
the build with another set of CFLAGS. I think what we could to check
for PROFILE_BUILD, and if it is set, do the first PROFILE_GEN / make
test commands as part of the top-level Makefile's all: rule, and then
do the normal build after that.
It's a little kludgy, but does that sound acceptable to you?
- Ted
^ permalink raw reply
* Re: [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Ted Ts'o @ 2012-02-02 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andi Kleen, Clemens Buchacher
In-Reply-To: <20120202201226.GA1032@thunk.org>
On Thu, Feb 02, 2012 at 03:12:26PM -0500, Ted Ts'o wrote:
> Then do...
>
> $ make PROFILE_USE=YesPlease PROFILE_DIR=/var/cache/FDO all
> # make PROFILE_GEN=YesPlease PROFILE_DIR=/var/cache/FDO install
Err, that last line should have been:
# make PROFILE_USE=YesPlease PROFILE_DIR=/var/cache/FDO install
of course...
- Ted
^ permalink raw reply
* Re: [msysGit] Breakage in master?
From: Torsten Bögershausen @ 2012-02-02 20:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Git Mailing List, msysGit,
Ævar Arnfjörð Bjarmason
In-Reply-To: <alpine.DEB.1.00.1202021956370.1249@s15462909.onlinehome-server.info>
On 02.02.12 19:57, Johannes Schindelin wrote:
> Hi Erik,
>
> On Thu, 2 Feb 2012, Erik Faye-Lund wrote:
>
>> Something strange is going on in Junio's current 'master' branch
>> (f3fb075). "git show" has started to error out on Windows with a
>> complaint about our vsnprintf:
>> ---8<---
>>
>> $ git show
>> commit f3fb07509c2e0b21b12a598fcd0a19a92fc38a9d
>> Author: Junio C Hamano <gitster@pobox.com>
>> Date: Tue Jan 31 22:31:35 2012 -0800
>>
>> Update draft release notes to 1.7.10
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>>
>> fatal: BUG: your vsnprintf is broken (returned -1)
>> ---8<---
>>
>> [...]
>>
>> I'm at a loss here. Does anyone have a hunch about what's going on?
>
> It very much reminds me of 6ef404095bc1162031fc3cb43430b512e975bc6a...
>
> Is it possible that NO_GETTEXT is either not set, or ignored?
>
> Ciao,
> Dscho
Hi,
same problem here, tested on Win XP.
Good news (?):
Setting
NO_GETTEXT=YesPlease
in the Makefile makes the problem go away for me.
/Torsten
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Jonathan Nieder @ 2012-02-02 20:16 UTC (permalink / raw)
To: Ben Walton; +Cc: git, gitster, Jeff King
In-Reply-To: <1328211135-25217-1-git-send-email-bwalton@artsci.utoronto.ca>
Ben Walton wrote:
> --- a/t/t0300-credentials.sh
> +++ b/t/t0300-credentials.sh
> @@ -8,10 +8,12 @@ test_expect_success 'setup helper scripts' '
> cat >dump <<-\EOF &&
> whoami=`echo $0 | sed s/.*git-credential-//`
> echo >&2 "$whoami: $*"
> + OIFS=$IFS
> while IFS== read key value; do
> echo >&2 "$whoami: $key=$value"
> eval "$key=$value"
> done
> + IFS=$OIFS
Oh, good catch. Technically "read" is not a special builtin so POSIX shells
are not supposed to do this (and Jeff's patch definitely looks right), but in
any case temporary variable settings while running a builtin are close
enough to the assignment-during-special-builtin-or-function case to
make me shiver a little. ;-)
Would something like
(
IFS==
while read key value
do
...
done
)
make sense?
^ permalink raw reply
* [PATCH v4 0/4] completion: couple of cleanups
From: Felipe Contreras @ 2012-02-02 20:30 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, SZEDER Gábor, Jonathan Nieder, Thomas Rast,
Felipe Contreras
And an improvement for zsh.
v4:
Same as v3, but with an improved commit message with input from Thomas Rast and sending directly to Junio.
v3:
Junio: I see you already picked most of them for 'pu', but I've made further changes based on the feedback:
* completion: be nicer with zsh
Improved the code-style
* completion: simplify __gitcomp*
Fix
Improved commit message
Felipe Contreras (4):
completion: work around zsh option propagation bug
completion: simplify __git_remotes
completion: remove unused code
completion: simplify __gitcomp*
contrib/completion/git-completion.bash | 66 +++++---------------------------
1 files changed, 10 insertions(+), 56 deletions(-)
--
1.7.9
^ permalink raw reply
* Re: How best to handle multiple-authorship commits in GIT?
From: David Howells @ 2012-02-02 20:33 UTC (permalink / raw)
To: Frans Klaver; +Cc: dhowells, git, valerie.aurora
In-Reply-To: <CAH6sp9P8ehXoC075dcK9ni5rJBV9iCZmLHTBr-UR+-jbD3c6Ww@mail.gmail.com>
Frans Klaver <fransklaver@gmail.com> wrote:
> I always thought of the author field as being an indication of who is
> ultimately responsible for its implementation (the one in the
> pestering spot).
Define 'ultimate responsibility for an implementation'. I'm further developing
patches that Val has (at least partially) implemented. By Val's admission some
of the patches she further developed beyond what Jan Blunck had implemented.
The chain may extend further. To that end all three of us are authors of some
of the patches.
However, if you meant 'maintenance' rather than 'implementation', then, yes,
that would be me (for the moment at least). But if that's the case, then
shouldn't it be 'Maintainer' and not 'Author'? And, besides, that's what the
MAINTAINERS file is for.
> (1) may seem desirous, but doesn't (2) seem like a cleaner and more
> maintainable solution?
No. I would say that properly supporting multiple authors in the commit object
is the cleaner solution. It's not the *easier* solution, however, and would
require an upgrade to the version of GIT used to parse these commits. That
I'll grant you.
> Gitweb will show the entire log message if people are interested in the
> exact change, right?
But if I say to Gitweb "show me the patches authored by Val" it will *not* turn
up these patches, and in that way will deny Val credit. Yes, you can see that
Val altered that patch if you look at that patch directly - but you have to
know where to go and look, in which case you already know or suspect that Val
is credited with patches in that area.
So to make (2) work, Gitweb needs to search for the additional authoring fields
when asked to credit people with the patches they've worked on.
Similarly gitk and possibly other tools would need to do the same.
*That* would be fine by me, I suppose. I don't think it's the correct way to
do it, but it might be the logical way since this wasn't build in from the
beginning - and the main thing would be to turn up the prior or joint
authorship to author-based searches.
David
^ permalink raw reply
* Re: [RFC PATCH] gitweb: use CGI with -utf8
From: Michał Kiedrowicz @ 2012-02-02 20:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m37h05c8c1.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
>
> > I noticed that gitweb tries a lot to properly process UTF-8 data, for
> > example it prints my name correctly in log and commit information, but
> > it echos junk in the search field. It looks like:
> >
> > Michał Kiedrowicz
> >
> > I don't know CGI well and I never touched gitewb code, but I found this
> > on http://www.lemoda.net/cgi/perl-unicode/index.html:
> >
> > use CGI '-utf8';
> > my $value = params ('input');
> >
> > I tried it and that fixed my problem. I'm not sure about the
> > consequences, maybe someone more experienced in CGI might help?
>
> I have reworded this to form a proper commit message (see
> Documentation/SubmittingPatches) and I'll resend this as a reply to
> this email.
Thanks, your message is much better.
>
> > ---
> > gitweb/gitweb.perl | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index abb5a79..74d45b1 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -10,7 +10,7 @@
> > use 5.008;
> > use strict;
> > use warnings;
> > -use CGI qw(:standard :escapeHTML -nosticky);
> > +use CGI qw(:standard :escapeHTML -nosticky -utf8);
> > use CGI::Util qw(unescape);
> > use CGI::Carp qw(fatalsToBrowser set_message);
> > use Encode;
> > --
>
> Does this actually work for you?
Yes. It correctly displays "ł" in the search form.
> Because it doesn't work for me
> (perhaps I have too old CGI module: what CGI.pm and what Perl version
> do you use?).
>
$ perl --version
This is perl 5, version 12, subversion 4 (v5.12.4) built for x86_64-linux
(with 12 registered patches, see perl -V for more detail)
$ eix -e CGI -c
[I] perl-core/CGI (3.510@01.02.2012): Simple Common Gateway Interface Class
> See other solution to this in other reply to this email.
>
^ permalink raw reply
* Re: [PATCH/RFC (version A)] gitweb: use CGI with -utf8 to process Unicode query parameters correctly
From: Michał Kiedrowicz @ 2012-02-02 20:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202022108.51353.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Gitweb tries hard to properly process UTF-8 data, by marking output
> from git commands and contents of files as UTF-8 with to_utf8()
> subroutine. This ensures that gitweb would print correctly UTF-8
> e.g. in 'log' and 'commit' views.
>
> Unfortunately it misses another source of potentially Unicode input,
> namely query parameters. The result is that one cannot search for a
> string containing characters outside US-ASCII. For example searching
> for "Michał Kiedrowicz" (containing letter 'ł' - LATIN SMALL LETTER L
> WITH STROKE, with Unicode codepoint U+0142, represented with 0xc5 0x82
> bytes in UTF-8 and percent-encoded as %C5%81) result in the following
> incorrect data in search field
>
> Michał Kiedrowicz
>
> This is caused by CGI by default treating '0xc5 0x82' bytes as two
> characters in Perl legacy encoding latin-1 (iso-8859-1), because 's'
> query parameter is not processed explicitly as UTF-8 encoded string.
>
> According to "Using Unicode in a Perl CGI script" article on
> http://www.lemoda.net/cgi/perl-unicode/index.html the simplest
> solution is to just import '-utf8' pragma for CGI module:
>
> use CGI '-utf8';
> my $value = params('input');
>
> According to CGI module documentation, the '-utf8' pragma may cause
> problems with POST requests containing binary files... but gitweb
> currently do not use POST requests at all, so this should be not a
> problem now.
This was exactly my feeling when I sent this patch :).
>
> Alternate solution would be to explicity decode query parameters when
> storing them in %input_params (and perhaps also path_info).
>
> [jn: reworded / rewritten commit message]
>
> Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Thanks, I forgot about that.
> Signed-off-by: Jakub Narębski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 9cf7e71..a7441ef 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -10,7 +10,7 @@
> use 5.008;
> use strict;
> use warnings;
> -use CGI qw(:standard :escapeHTML -nosticky);
> +use CGI qw(:standard :escapeHTML -nosticky -utf8);
> use CGI::Util qw(unescape);
> use CGI::Carp qw(fatalsToBrowser set_message);
> use Encode;
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Matthieu Moy @ 2012-02-02 20:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ben Walton, git, gitster, Jeff King
In-Reply-To: <20120202201629.GA20200@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Would something like
>
> (
> IFS==
> while read key value
> do
> ...
> done
> )
>
> make sense?
I don't think so since the "..." contains
eval "$key=$value"
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [msysGit] Breakage in master?
From: Johannes Sixt @ 2012-02-02 20:45 UTC (permalink / raw)
To: kusmabite
Cc: Git Mailing List, msysGit, Ævar Arnfjörð Bjarmason
In-Reply-To: <CABPQNSbWu0r_gKGvCHk567pUtQiyDOCO8vFfrzPMFW1eUaj1nw@mail.gmail.com>
Am 02.02.2012 13:14, schrieb Erik Faye-Lund:
> Something strange is going on in Junio's current 'master' branch
> (f3fb075). "git show" has started to error out on Windows with a
> complaint about our vsnprintf:
> ---8<---
>
> $ git show
> commit f3fb07509c2e0b21b12a598fcd0a19a92fc38a9d
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Tue Jan 31 22:31:35 2012 -0800
>
> Update draft release notes to 1.7.10
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> fatal: BUG: your vsnprintf is broken (returned -1)
FWIW, I run a version of master on Windows with almost no additional
patches that touch compat/ (the few changes I do have are unsuspicious).
But I do not observe this behavior. I build with NO_GETTEXT and -O0.
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 1/4] completion: be nicer with zsh
From: Felipe Contreras @ 2012-02-02 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, SZEDER Gábor
In-Reply-To: <7v8vklvxwh.fsf@alter.siamese.dyndns.org>
On Thu, Feb 2, 2012 at 9:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> However, clearly I did not say it clearly enough. :) I guess it's
>> better to take a cue from storytellers and show rather than tell.
>
> Very big thanks for this ;-)
Not a single comment regarding what I said? I don't see what's not
sensible about a commit message with this order:
1) short description of the *purpose* of the patch
2) Summary of the problem.
3) Proposed solution
4) Extra information, useful for future references, etc.
This ensures the most relevant information for most people is at the top.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH/RFC (version B)] gitweb: Allow UTF-8 encoded CGI query parameters and path_info
From: Michał Kiedrowicz @ 2012-02-02 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202022110.07127.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Gitweb tries hard to properly process UTF-8 data, by marking output
> from git commands and contents of files as UTF-8 with to_utf8()
> subroutine. This ensures that gitweb would print correctly UTF-8
> e.g. in 'log' and 'commit' views.
>
> Unfortunately it misses another source of potentially Unicode input,
> namely query parameters. The result is that one cannot search for a
> string containing characters outside US-ASCII. For example searching
> for "Michał Kiedrowicz" (containing letter 'ł' - LATIN SMALL LETTER L
> WITH STROKE, with Unicode codepoint U+0142, represented with 0xc5 0x82
> bytes in UTF-8 and percent-encoded as %C5%81) result in the following
> incorrect data in search field
>
> Michał Kiedrowicz
>
> This is caused by CGI by default treating '0xc5 0x82' bytes as two
> characters in Perl legacy encoding latin-1 (iso-8859-1), because 's'
> query parameter is not processed explicitly as UTF-8 encoded string.
>
> The solution used here follows "Using Unicode in a Perl CGI script"
> article on http://www.lemoda.net/cgi/perl-unicode/index.html:
>
> use CGI;
> use Encode 'decode_utf8;
> my $value = params('input');
> $value = decode_utf8($value);
>
> This is done when filling %input_params hash; this required to move
> from explicit $cgi->param(<label>) to $input_params{<name>} in a few
> places.
I'm sorry but this doesn't work for me. I would be happy to help if you
have some questions about it.
>
> Alternate solution would be to simply use the '-utf8' pragma (via
> "use CGI '-utf8';"), but according to CGI.pm documentation it may
> cause problems with POST requests containing binary files... and
> it doesn't work with old CGI.pm version 3.10 from Perl v5.8.6.
>
> Noticed-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
> Signed-off-by: Jakub Narębski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 9cf7e71..55b2c24 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -52,7 +52,7 @@ sub evaluate_uri {
> # as base URL.
> # Therefore, if we needed to strip PATH_INFO, then we know that we have
> # to build the base URL ourselves:
> - our $path_info = $ENV{"PATH_INFO"};
> + our $path_info = decode_utf8($ENV{"PATH_INFO"});
> if ($path_info) {
> if ($my_url =~ s,\Q$path_info\E$,, &&
> $my_uri =~ s,\Q$path_info\E$,, &&
> @@ -816,9 +816,9 @@ sub evaluate_query_params {
>
> while (my ($name, $symbol) = each %cgi_param_mapping) {
> if ($symbol eq 'opt') {
> - $input_params{$name} = [ $cgi->param($symbol) ];
> + $input_params{$name} = [ map { decode_utf8($_) } $cgi->param($symbol) ];
> } else {
> - $input_params{$name} = $cgi->param($symbol);
> + $input_params{$name} = decode_utf8($cgi->param($symbol));
> }
> }
> }
> @@ -2767,7 +2767,7 @@ sub git_populate_project_tagcloud {
> }
>
> my $cloud;
> - my $matched = $cgi->param('by_tag');
> + my $matched = $input_params{'ctag'};
> if (eval { require HTML::TagCloud; 1; }) {
> $cloud = HTML::TagCloud->new;
> foreach my $ctag (sort keys %ctags_lc) {
> @@ -5282,7 +5282,7 @@ sub git_project_list_body {
>
> my $check_forks = gitweb_check_feature('forks');
> my $show_ctags = gitweb_check_feature('ctags');
> - my $tagfilter = $show_ctags ? $cgi->param('by_tag') : undef;
> + my $tagfilter = $show_ctags ? $input_params{'ctag'} : undef;
> $check_forks = undef
> if ($tagfilter || $searchtext);
>
> @@ -6197,7 +6197,7 @@ sub git_tag {
>
> sub git_blame_common {
> my $format = shift || 'porcelain';
> - if ($format eq 'porcelain' && $cgi->param('js')) {
> + if ($format eq 'porcelain' && $input_params{'javascript'}) {
> $format = 'incremental';
> $action = 'blame_incremental'; # for page title etc
> }
^ 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