* Re: [PATCH] git-completion: workaround zsh COMPREPLY bug
From: Felipe Contreras @ 2012-01-28 17:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <vpqr4ynzbj7.fsf@bauges.imag.fr>
On Thu, Jan 26, 2012 at 12:02 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> I still have a minor comment: maybe part of your commit message could go
> to a comment in the code as well, in particular the "Once zsh is fixed"
> part, to help future contributors to actually disable the workaround
> when possible in the future.
FTR, I've fixed all the issues in zsh's bash completion:
http://thread.gmane.org/gmane.comp.shells.zsh.devel/24290
Now I don't need the workaround and it works just like in bash :)
However, zsh devs seem very quiet.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #06; Fri, 27)
From: Felipe Contreras @ 2012-01-28 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vfwf0xu8a.fsf@alter.siamese.dyndns.org>
On Sat, Jan 28, 2012 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * mm/zsh-completion-regression-fix (2012-01-17) 1 commit
>> (merged to 'next' on 2012-01-23 at 7bc2e0a)
>> + bash-completion: don't add quoted space for ZSH (fix regression)
>>
>> Will merge early in the next cycle and deal with any fallout in 'master'.
>
> This topic has been superseded by Felipe's f15026b (git-completion:
> workaround zsh COMPREPLY bug, 2012-01-25) to use "typeset -h IFS", so I
> should drop this.
>
> Am I mistaken?
That's correct.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Revert "gitweb: Time::HiRes is in core for Perl 5.8"
From: Jakub Narebski @ 2012-01-28 17:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Hallvard Breien Furuseth,
git
In-Reply-To: <7vty3gzxhs.fsf@alter.siamese.dyndns.org>
On Fri, 27 Jan 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Though Time::HiRes is a core Perl module, it doesn't necessarily mean
> > that it is included in 'perl' package, and that it is installed if
> > Perl is installed.
>
> I do not think we have seen the end of Redhat/Fedora Perl saga. I am
> hoping that either one of the two things to happen:
>
> (1) Redhat/Fedora distrubution reconsiders the situation and fix their
> packages so that by default when its users ask for "Perl" they get
> what the upstream distributes as "Perl" in full, while still allowing
> people who know what they are doing to install a minimum subset
> "perl-base"; or
>
> (2) Many applications that use and rely on Perl like we do are hit by
> this issue, and Redhat/Fedora users are trained to install the
> perl-full (or whatever it is called) package when applications want
> "Perl".
>
> In other words, I am hoping that "it doesn't necessarily mean" will not
> stay true for a long time. So please hold onto this patch until the dust
> settles, and resend it if (1) does not look to be happening in say 3
> months.
So for the time being (those "3 months") you would apply instead your
change to INSTALL (or equivalent to gitweb/INSTALL) mentioning Time::HiRes
issue, and perhaps also original patch by Hallvard skipping gitweb tests
if Time::HiRes is not available, isn't it?
> > For example RedHat has split it out to a separate RPM perl-Time-HiRes.
[...]
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index abb5a79..c86224a 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -17,10 +17,12 @@ use Encode;
> > use Fcntl ':mode';
> > use File::Find qw();
> > use File::Basename qw(basename);
> > -use Time::HiRes qw(gettimeofday tv_interval);
> > binmode STDOUT, ':utf8';
> >
> > -our $t0 = [ gettimeofday() ];
> > +our $t0;
> > +if (eval { require Time::HiRes; 1; }) {
> > + $t0 = [Time::HiRes::gettimeofday()];
> > +}
> > our $number_of_git_cmds = 0;
>
> Why should these even be initialized here? Doesn't reset_timer gets
> called at the beginning of run_request()?
I think it predates adding reset_timer() to gitweb. Anyway $t0 has
to be set to something defined anyway to denote that Time::HiRes is
available... though if Time::HiRes is required unconditionally it would
not be really needed, and we can always check $INC{'Time/HiRes.pm'}
if it was loaded or not.
> > BEGIN {
> > @@ -1142,7 +1144,7 @@ sub dispatch {
> > }
> >
> > sub reset_timer {
> > - our $t0 = [ gettimeofday() ]
> > + our $t0 = [Time::HiRes::gettimeofday()]
> > if defined $t0;
> > our $number_of_git_cmds = 0;
>
> The statement modifier look ugly.
>
> More importantly, if you are not profiling, i.e. if we didn't initialize
> $t0 at the beginning, do you need to reset $number_of_git_cmds at all?
>
> I also think this should take gitweb_check_feature('timed') into
> account, perhaps like this:
>
> sub reset_timer {
> return unless gitweb_check_feature('timed');
> our $t0 = ...
> our $number_of_git_cmds = 0;
> }
>
> Then all the other
>
> if (defined $t0 && gitweb_check_feature('timed'))
>
> can become
>
> if (defined $t0)
I think this is a good idea... though it would complicate applying revert
a bit ;-(
> If you go this route, even though tee-zero, the beginning of the time, is
> a good name for the variable, you may want to rename it to avoid confusing
> readers who might take it as a temporary variable #0.
Good idea. $request_start_time perhaps? Or $time_start?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bisecting through the middle of a big merge?
From: walt @ 2012-01-28 18:15 UTC (permalink / raw)
To: git
In-Reply-To: <m239b0fbpb.fsf@igel.home>
On 01/28/2012 12:55 AM, Andreas Schwab wrote:
> walt <w41ter@gmail.com> writes:
>
>> There are many individual commits from Tejun Heo et al included
>> in that one big commit from Linus. Unfortunately for me, some of
>> those commits cause other problems that I'm not trying to bisect;
>> other problems that evidently get fixed by other commits in the
>> same big merge.
>>
>> So I do 'git bisect skip' six or eight times until the 'false' bug
>> goes away, and that leaves me at the end of the bisect without finding
>> the individual commit that's causing my 'real' bug.
>>
>> How do you experts handle this kind of problem?
>
> If you can identify the commit that fixes the unrelated problem you can
> try to cherry-pick it during the bisect.
Thanks Andreas. With an eye to doing that, is there an easy way to
get a list of all the commits included in Linus's merge? (I mean a
more accurate list than Linus casually mentions in his commit message.)
Trying to build that mental model I mentioned: All the commits from
Tejun Heo are dated mid-December but Linus didn't commit them until
mid-January. When I'm bisecting through that merge, git builds the
kernels with names like vmlinuz-3.2.0-rc5-foo, i.e. names a month
older than Linus's current kernel version. Where does git get those
older names during the bisect? And does my working tree exclude all
of Linus's commits made later than 3.2.0-rc5-foo?
Many thanks.
^ permalink raw reply
* Re: Bisecting through the middle of a big merge?
From: Andreas Schwab @ 2012-01-28 19:47 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <jg1e0t$5cs$1@dough.gmane.org>
walt <w41ter@gmail.com> writes:
> With an eye to doing that, is there an easy way to get a list of all
> the commits included in Linus's merge?
$ git log merge-commit^..merge-commit
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Bisecting through the middle of a big merge?
From: walt @ 2012-01-28 22:18 UTC (permalink / raw)
To: git
In-Reply-To: <m2ty3ffw2f.fsf@igel.home>
On 01/28/2012 11:47 AM, Andreas Schwab wrote:
> walt <w41ter@gmail.com> writes:
>
>> With an eye to doing that, is there an easy way to get a list of all
>> the commits included in Linus's merge?
>
> $ git log merge-commit^..merge-commit
Amazing. And obvious now that you've already told me the answer.
I'm not thinking like a developer yet, but I'm working on it :)
^ permalink raw reply
* Re: [PATCH v2 1/2] gitweb: add project_filter to limit project list to a subdirectory
From: Jakub Narebski @ 2012-01-28 22:45 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git, Jakub Narebski
In-Reply-To: <20120128165606.GA6770@server.brlink.eu>
"Bernhard R. Link" <brl+git@mail.brlink.eu> writes:
> This commit changes the project listings (project_list, project_index
> and opml) to limit the output to only projects in a subdirectory if the
> new optional parameter ?pf=directory name is used.
>
"project listings" to "projects listing views", isn't it?
> The change is quite minimal as git_get_projects_list already can limit
> itself to a subdirectory (though that was previously only used for
> 'forks').
>
Nice description, and more clear than before.
> If strict_export is enabled and there is no projects_list, it still
> traverses the full tree and only filters afterwards to avoid anything
> getting visible by this. Otherwise only the subtree needs to be
> traversed, significantly reducing load times.
>
I still don't understand interaction between project_filter ('pf'),
$strict_export and $projects_list being either directory or a file
with a list of projects.
Does it mean, that when $projects_list is a file with a list of projects,
and we use project_filter, then:
* if $strict_export is false, then $project_list is ignored, and the
filtered list of projects is created by scanning
"$projectroot/$project_filter"
* if $strict_export is true, then $project_list file is read in full,
and then filtered to project with $project_filter as prefix
Is it correct? Is it sane, stated this way?
> Reusing $project instead of adding a new parameter would have been
> nicer from a UI point-of-view (including PATH_INFO support) but
> would complicate the $project validating code that is currently being
> used to ensure nothing is exported that should not be viewable.
>
O.K.
Anyway PATH_INFO support can be added in the future, by special casing
situation where project list action is stated using PATH_INFO... I think.
A few nitpicks with respect to patch itself.
> @@ -2827,6 +2835,7 @@ sub git_get_project_url_list {
>
> sub git_get_projects_list {
> my $filter = shift || '';
> + my $paranoid = shift || 0;
> my @list;
>
First, undefined value is false in Perl, so there is no need for
" || 0" in setting $paranoid variable.
Second, why not use global variable $strict_export instead of adding
another parameter to git_get_projects_list()?
> @@ -5979,7 +5994,7 @@ sub git_project_list {
> die_error(400, "Unknown order parameter");
> }
>
> - my @list = git_get_projects_list();
> + my @list = git_get_projects_list($project_filter, $strict_export);
> if (!@list) {
> die_error(404, "No projects found");
> }
[...]
> @@ -3963,9 +3976,11 @@ sub git_footer_html {
> }
>
> } else {
> - print $cgi->a({-href => href(project=>undef, action=>"opml"),
> + print $cgi->a({-href => href(project=>undef, action=>"opml",
> + project_filter => $project_filter),
> -class => $feed_class}, "OPML") . " ";
> - print $cgi->a({-href => href(project=>undef, action=>"project_index"),
> + print $cgi->a({-href => href(project=>undef, action=>"project_index",
> + project_filter => $project_filter),
> -class => $feed_class}, "TXT") . "\n";
> }
O.K.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH v2 2/2] gitweb: place links to parent directories in page header
From: Jakub Narebski @ 2012-01-28 22:54 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git, Jakub Narebski
In-Reply-To: <20120128165753.GA6795@server.brlink.eu>
"Bernhard R. Link" <brl+git@mail.brlink.eu> writes:
Description?
> Signed-off-by: Bernhard R. Link <brlink@debian.org>
>
> ---
> This patch was not yet part of v1.
>
> I'm not sure this if having this as seperate patch or merged into 1/2
> makes more sense.
While adding links that lead to gitweb URLs with project_filter
parameter set, i.e. linking new feature in, could be postponed to a
later commit, I think some way of notifying client that project list
is filtered would be better to have in 1/2.
> gitweb/gitweb.perl | 23 ++++++++++++++++++++++-
> 1 files changed, 22 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index a114bd4..ddce27d 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3841,7 +3841,18 @@ sub print_nav_breadcrumbs {
>
> print $cgi->a({-href => esc_url($home_link)}, $home_link_str) . " / ";
> if (defined $project) {
> - print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
> + my @dirname = split '/', $project;
> + my $projectbasename = pop @dirname;
> + my $dirprefix = undef;
> + while (my $part = shift @dirname) {
> + $dirprefix .= "/" if defined $dirprefix;
> + $dirprefix .= $part;
> + print $cgi->a({-href => href(project => undef,
> + project_filter => $dirprefix,
> + action=>"project_list")},
> + esc_html($part)) . " / ";
> + }
> + print $cgi->a({-href => href(action=>"summary")}, esc_html($projectbasename));
> if (defined $action) {
> my $action_print = $action ;
> if (defined $opts{-action_extra}) {
Nice solution.
> @@ -3854,6 +3865,16 @@ sub print_nav_breadcrumbs {
> print " / $opts{-action_extra}";
> }
> print "\n";
> + } elsif (defined $project_filter) {
> + my @dirname = split '/', $project_filter;
> + my $dirprefix = undef;
> + while (my $part = shift @dirname) {
> + $dirprefix .= "/" if defined $dirprefix;
> + $dirprefix .= $part;
> + print $cgi->a({-href => href(project_filter => $dirprefix,
> + action=>"project_list")},
> + esc_html($part)) . " / ";
> + }
> }
> }
Hmmm... I'd have to check how it looks like, but seems like a good
idea... even if there is a little bit of code duplication.
--
Jakub Narebski
^ permalink raw reply
* Re: Fwd: Gitweb error
From: Jakub Narebski @ 2012-01-29 0:37 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <CA+EqV8w5qz+iwg_PPB4M5Q-LS48B=yncR9UdR-r58BLtAEPPrA@mail.gmail.com>
On Fri, 27 Jan 2012, rajesh boyapati wrote:
> On Fri, Jan 27, 2012 at 3:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > rajesh boyapati <boyapatisrajesh@gmail.com> writes:
> > > When I go to one of the projects in gerrit through gitweb and when I
> > > click "summary", I am getting the below error.
> > > If I click other tabs(log, shortlog, commit, tree,etc) after clicking
> > > "summary", I am getting following error in error-log.
> > > If I click other tabs(log, shortlog, commit, tree,etc) before clicking
> > > "summary", everything works fine.
It is strange that you get an intermittent error like this, and make
it even harder to debug - HTTP is stateless.
> > > Error:
> > > =================================================================
> > > [2012-01-25 18:50:32,334] ERROR
> > > com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
> > > 18:50:32 2012] gitweb.cgi: Use of uninitialized value $head in string
> > > eq at /usr/lib/cgi-bin/gitweb.cgi line 4720.
> >
> > Could you show this line and about 3 lines of context in your
> > gitweb.cgi?
> >
>
> my $alternate = 1;
> for (my $i = $from; $i <= $to; $i++) {
> my $entry = $headlist->[$i];
> my %ref = %$entry;
> my $curr = $ref{'id'} eq $head;
> if ($alternate) {
> print "<tr class=\"dark\">\n";
> } else {
> print "<tr class=\"light\">\n";
> }
> $alternate ^= 1;
Hmmmm... I see that we do not check if $head is defined here before using
it. This can happen legitimately if we are on yet to be born orphan branch
(so $head, which should be named $head_at, is undefined) but there exist
other branches (so $headlist is not empty).
But I don't think it is what happened in your case, is it?
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v3] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-29 1:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3wr8bcuon.fsf@localhost.localdomain>
This commit changes the project listing views (project_list,
project_index and opml) to limit the output to only projects in a
subdirectory if the new optional parameter ?pf=directory name is used.
The change is quite minimal as git_get_projects_list already can limit
itself to a subdirectory (though that was previously only used for
'forks').
If there is a GITWEB_LIST file, the contents are just filtered like
with the forks action.
Without a GITWEB_LIST file only the given subdirectory is searched
for projects (like with forks) unless GITWEB_STRICT_EXPORT is enabled.
In the later case GITWEB_PROJECTROOT is traversed normally (unlike
with forks) and projects not in the directory ignored.
(As there is no check if the filter_path would have been found in
the usual search as the project path is checked with forks).
Reusing $project instead of adding a new parameter would have been
nicer from a UI point-of-view (including PATH_INFO support) but
would complicate the $project validating code that is currently being
used to ensure nothing is exported that should not be viewable.
Additionally change html page headers to not only link the project
root and the currently selected project but also the directories in
between using project_filter.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
changes since v2:
improve description
remove || 0 for boolean argument
merge with patch using this feature
use user-visible configuration names instead of internal ones
* Jakub Narebski <jnareb@gmail.com> [120128 23:45]:
> "Bernhard R. Link" <brl+git@mail.brlink.eu> writes:
> > If strict_export is enabled and there is no projects_list, it still
> > traverses the full tree and only filters afterwards to avoid anything
> > getting visible by this. Otherwise only the subtree needs to be
> > traversed, significantly reducing load times.
> >
> I still don't understand interaction between project_filter ('pf'),
> $strict_export and $projects_list being either directory or a file
> with a list of projects.
>
> Does it mean, that when $projects_list is a file with a list of projects,
> and we use project_filter, then:
>
> * if $strict_export is false, then $project_list is ignored, and the
> filtered list of projects is created by scanning
> "$projectroot/$project_filter"
No. If project_list is set, i.e. a file, then this is always used.
If it is a directory (because it is not set thus set to projectroot),
then with forks it still traverses that directory (as that was checked
before to be a reachable project with a previous call to
git_get_projects_list). In the case of project_filter only the directory
is traversed without strict_export and the whole projectroot is
traversed with strict_export.
Is the new description better.
> A few nitpicks with respect to patch itself.
>
> > -2827,6 +2835,7 @@ sub git_get_project_url_list {
> >
> > sub git_get_projects_list {
> > my $filter = shift || '';
> > + my $paranoid = shift || 0;
> > my @list;
> >
>
> First, undefined value is false in Perl, so there is no need for
> " || 0" in setting $paranoid variable.
I thought it make it clearer that the argument might not be set and
what the default is. But that is personal taste.
> Second, why not use global variable $strict_export instead of adding
> another parameter to git_get_projects_list()?
That would change the action=forks behaviour to traverse the whole
projectroot two times. This way paranoia is only activated if
strict_mode is set _and_ the argument was not yet checked to be
reachable.
gitweb/gitweb.perl | 52 ++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index abb5a79..089d45d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -760,6 +760,7 @@ our @cgi_param_mapping = (
search_use_regexp => "sr",
ctag => "by_tag",
diff_style => "ds",
+ project_filter => "pf",
# this must be last entry (for manipulation from JavaScript)
javascript => "js"
);
@@ -976,7 +977,7 @@ sub evaluate_path_info {
our ($action, $project, $file_name, $file_parent, $hash, $hash_parent, $hash_base,
$hash_parent_base, @extra_options, $page, $searchtype, $search_use_regexp,
- $searchtext, $search_regexp);
+ $searchtext, $search_regexp, $project_filter);
sub evaluate_and_validate_params {
our $action = $input_params{'action'};
if (defined $action) {
@@ -994,6 +995,13 @@ sub evaluate_and_validate_params {
}
}
+ our $project_filter = $input_params{'project_filter'};
+ if (defined $project_filter) {
+ if (!validate_pathname($project_filter)) {
+ die_error(404, "Invalid project_filter parameter");
+ }
+ }
+
our $file_name = $input_params{'file_name'};
if (defined $file_name) {
if (!validate_pathname($file_name)) {
@@ -2827,6 +2835,7 @@ sub git_get_project_url_list {
sub git_get_projects_list {
my $filter = shift || '';
+ my $paranoid = shift;
my @list;
$filter =~ s/\.git$//;
@@ -2839,7 +2848,7 @@ sub git_get_projects_list {
my $pfxlen = length("$dir");
my $pfxdepth = ($dir =~ tr!/!!);
# when filtering, search only given subdirectory
- if ($filter) {
+ if ($filter and not $paranoid) {
$dir .= "/$filter";
$dir =~ s!/+$!!;
}
@@ -2864,6 +2873,10 @@ sub git_get_projects_list {
}
my $path = substr($File::Find::name, $pfxlen + 1);
+ # paranoidly only filter here
+ if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
+ next;
+ }
# we check related file in $projectroot
if (check_export_ok("$projectroot/$path")) {
push @list, { path => $path };
@@ -3828,7 +3841,18 @@ sub print_nav_breadcrumbs {
print $cgi->a({-href => esc_url($home_link)}, $home_link_str) . " / ";
if (defined $project) {
- print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
+ my @dirname = split '/', $project;
+ my $projectbasename = pop @dirname;
+ my $dirprefix = undef;
+ while (my $part = shift @dirname) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project => undef,
+ project_filter => $dirprefix,
+ action=>"project_list")},
+ esc_html($part)) . " / ";
+ }
+ print $cgi->a({-href => href(action=>"summary")}, esc_html($projectbasename));
if (defined $action) {
my $action_print = $action ;
if (defined $opts{-action_extra}) {
@@ -3841,6 +3865,16 @@ sub print_nav_breadcrumbs {
print " / $opts{-action_extra}";
}
print "\n";
+ } elsif (defined $project_filter) {
+ my @dirname = split '/', $project_filter;
+ my $dirprefix = undef;
+ while (my $part = shift @dirname) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project_filter => $dirprefix,
+ action=>"project_list")},
+ esc_html($part)) . " / ";
+ }
}
}
@@ -3963,9 +3997,11 @@ sub git_footer_html {
}
} else {
- print $cgi->a({-href => href(project=>undef, action=>"opml"),
+ print $cgi->a({-href => href(project=>undef, action=>"opml",
+ project_filter => $project_filter),
-class => $feed_class}, "OPML") . " ";
- print $cgi->a({-href => href(project=>undef, action=>"project_index"),
+ print $cgi->a({-href => href(project=>undef, action=>"project_index",
+ project_filter => $project_filter),
-class => $feed_class}, "TXT") . "\n";
}
print "</div>\n"; # class="page_footer"
@@ -5979,7 +6015,7 @@ sub git_project_list {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
@@ -6018,7 +6054,7 @@ sub git_forks {
}
sub git_project_index {
- my @projects = git_get_projects_list();
+ my @projects = git_get_projects_list($project_filter, $strict_export);
if (!@projects) {
die_error(404, "No projects found");
}
@@ -7855,7 +7891,7 @@ sub git_atom {
}
sub git_opml {
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
--
1.7.8.3
^ permalink raw reply related
* [PATCH] git-svn: un-break "git svn rebase" when log.abbrevCommit=true
From: Ævar Arnfjörð Bjarmason @ 2012-01-29 2:11 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Ævar Arnfjörð Bjarmason
Change git-svn to parse --no-abbrev-commit --no-decorate to git-log
since it's trying to parse the log output, and the parsing will fail
completely if log.abbrevCommit is set to true in the configuration,
also set --no-decorate so we won't fail if we're processing a commit
that has a tag pointing to it.
Without this patch the code will fail to parse a SHA1, and then just
spew a bunch of "Use of uninitialized value $hash in string eq"
warnings at "if ($c && $c eq $hash) { ..." and never do anything
useful.
A real fix would be to make git-svn not use any porcelain utilities,
but just work around it for now.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
git-svn.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eeb83d3..570fe9c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1879,7 +1879,8 @@ sub cmt_sha2rev_batch {
sub working_head_info {
my ($head, $refs) = @_;
my @args = qw/log --no-color --no-decorate --first-parent
- --pretty=medium/;
+ --pretty=medium --no-abbrev-commit --no-decorate/;
+
my ($fh, $ctx) = command_output_pipe(@args, $head);
my $hash;
my %max;
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH] Revert "gitweb: Time::HiRes is in core for Perl 5.8"
From: Ævar Arnfjörð Bjarmason @ 2012-01-29 2:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Hallvard Breien Furuseth, git
In-Reply-To: <201201271845.39576.jnareb@gmail.com>
On Fri, Jan 27, 2012 at 18:45, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 23 Jan 2012, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Jan 23, 2012 at 05:50, Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> wrote:
>> >
>> > t9500-gitweb-standalone-no-errors fails: Git 1.7.9.rc2/1.7.8.4, RHEL
>> > 6.2, Perl 5.10.1. Reverting 3962f1d756ab41c1d180e35483d1c8dffe51e0d1
>> > fixes it. The commit expects Time::HiRes to be present, but RedHat
>> > has split it out to a separate RPM perl-Time-HiRes. Better add a
>> > comment about that, so it doesn't get re-reverted.
>> >
>> > Or pacify the test and expect gitweb@RHEL-users to install the RPM:
> [...]
>
>> This doesn't actually fix the issue, it only sweeps it under the rug
>> by making the tests pass, gitweb will still fail to compile on Red
>> Hat once installed.
>
> I think you meant "fail to run" here.
I mean fail to compile, "use" statements are executed at compile time,
if it was a "require" outside of BEGIN-time it would fail at runtime.
I realize though that you probably thought I meant fail in Git's
Makefile-driven compilation phase, but no, it'll install just fine,
however the perl interpreter won't compile it.
>> I think the right solution is to partially revert
>> 3962f1d756ab41c1d180e35483d1c8dffe51e0d1, but add a comment in the
>> code indicating that it's to deal with RedHat's broken fork of Perl.
>
> I have added comment in commit message, but not in code. I wonder if
> it would be enough.
>
>> However even if it's required in an eval it might still fail at
>> runtime in the reset_timer() function, which'll need to deal with it
>> too.
>
> It shouldn't; everything else related to timer is protected with
> 'if defined $t0', which is false if Time::HiRes module is not available.
Correct, I didn't look carefully enough.
^ permalink raw reply
* Re: [PATCH] Revert "gitweb: Time::HiRes is in core for Perl 5.8"
From: Ævar Arnfjörð Bjarmason @ 2012-01-29 2:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Hallvard Breien Furuseth, git
In-Reply-To: <7vty3gzxhs.fsf@alter.siamese.dyndns.org>
On Fri, Jan 27, 2012 at 21:44, Junio C Hamano <gitster@pobox.com> wrote:
>
> if (defined $t0)
>
> If you go this route, even though tee-zero, the beginning of the
> time, is a good name for the variable, you may want to rename it to
> avoid confusing readers who might take it as a temporary variable
> #0.
<trivia>
Personally I'd have written it as $START_TIME, but as a bit of Perl
trivia you might not realize $t0 is a commonly used and undestood
variable for dealing with a start time in Perl in the same way that
`i` is common for dealing with array indexes in C.
I.e. someone used to Perl will immediately think "oh that's the start
time" having seen it hundreds of times before, but someone not used to
Perl will go "what's this t-zero thing?".
Meanwhile some Lisp programmer is wondering what the hell "i" means in
your C for-loops, iterator? :)
^ permalink raw reply
* Re: [PATCH] git-svn: un-break "git svn rebase" when log.abbrevCommit=true
From: Jonathan Nieder @ 2012-01-29 2:59 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, Eric Wong
In-Reply-To: <1327803073-7000-1-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1879,7 +1879,8 @@ sub cmt_sha2rev_batch {
> sub working_head_info {
> my ($head, $refs) = @_;
> my @args = qw/log --no-color --no-decorate --first-parent
> - --pretty=medium/;
> + --pretty=medium --no-abbrev-commit --no-decorate/;
> +
Oh, dear. Wouldn't
my @args = qw/rev-list --first-parent --pretty=medium/;
be simpler and more robust as a quick fix?
Of course something that takes plain rev-list --first-parent output
and pipes it through to cat-file --batch might be more intuitive, but
rev-list --pretty should at least work. ;-)
^ permalink raw reply
* Cloning bare repository always warns that its empty.
From: nmartin @ 2012-01-29 3:09 UTC (permalink / raw)
To: git
Hello..
I created a bare repository (empty) on my server which I making public over
http. I cloned this repository on another machine(A), committed changes, and
pushed the changes to the server. On the server when I run $ git log I can
see the commit that I pushed. However if I clone this repository on a 3rd
machine(B).. the repository is empty.
Can someone to me what I am doing wrong? I would expect the pushed changes
to have been brought down to machine B.
Thanks!
--
View this message in context: http://git.661346.n2.nabble.com/Cloning-bare-repository-always-warns-that-its-empty-tp7233455p7233455.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] git-svn: un-break "git svn rebase" when log.abbrevCommit=true
From: Ævar Arnfjörð Bjarmason @ 2012-01-29 3:12 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Wong
In-Reply-To: <20120129025914.GA5981@burratino>
On Sun, Jan 29, 2012 at 03:59, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -1879,7 +1879,8 @@ sub cmt_sha2rev_batch {
>> sub working_head_info {
>> my ($head, $refs) = @_;
>> my @args = qw/log --no-color --no-decorate --first-parent
>> - --pretty=medium/;
>> + --pretty=medium --no-abbrev-commit --no-decorate/;
>> +
>
> Oh, dear. Wouldn't
>
> my @args = qw/rev-list --first-parent --pretty=medium/;
>
> be simpler and more robust as a quick fix?
>
> Of course something that takes plain rev-list --first-parent output
> and pipes it through to cat-file --batch might be more intuitive, but
> rev-list --pretty should at least work. ;-)
That sounds like a better fix. I forgot that rev-list could emulate
git-log like that.
^ permalink raw reply
* Re: BUG 1.7.9: git branch fails to create new branch when --edit-description is used
From: Jeff King @ 2012-01-29 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, Mark Jason Dominus, git
In-Reply-To: <7vbopoxp5q.fsf@alter.siamese.dyndns.org>
On Fri, Jan 27, 2012 at 11:27:29PM -0800, Junio C Hamano wrote:
> > Given this design, shouldn't "git branch --edit-description" fail if the
> > branch doesn't already exist?
>
> The only use scenario in the original design was to have a way to store
> the description given a branch name, and giving a description to a branch
> that does not yet exist is outside the scope of the design. So it all
> boils down to what is the most convenient and the simplest to explain.
How do we define "branch exists"? That the ref exists? What about a HEAD
that points to a branch-to-be-born?
Specifically, I am wondering whether this:
$ git init
$ git branch --edit-description
should work. Right now it edits the description for "master", even
though you haven't yet committed to it.
-Peff
^ permalink raw reply
* Re: Cloning bare repository always warns that its empty.
From: Jeff King @ 2012-01-29 3:24 UTC (permalink / raw)
To: nmartin; +Cc: git
In-Reply-To: <1327806561158-7233455.post@n2.nabble.com>
On Sat, Jan 28, 2012 at 07:09:21PM -0800, nmartin wrote:
> I created a bare repository (empty) on my server which I making public over
> http. I cloned this repository on another machine(A), committed changes, and
> pushed the changes to the server. On the server when I run $ git log I can
> see the commit that I pushed. However if I clone this repository on a 3rd
> machine(B).. the repository is empty.
Is your http server git-aware (i.e., running the smart-git http-backend
CGI), or it is simply serving the repository files? If the latter, then
you need to arrange to run the "git update-server-info" when you push
into it, which will update the information that "dumb" http clients will
look at.
If the server is running git v1.6.6 or later, you can turn this on in
the server repository by running:
git config receive.updateserverinfo true
-Peff
^ permalink raw reply
* Bug: "git checkout -b" should be allowed in empty repo
From: Michael Haggerty @ 2012-01-29 6:09 UTC (permalink / raw)
To: git
When starting a new repo, git seems to insist that the first commit be
made on a branch named "master":
$ git --version
git version 1.7.9
$ git init git-test
Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/
$ cd git-test
$ git checkout -b foo
fatal: You are on a branch yet to be born
I would call this a bug; the last command should be allowed. The
plumbing allows it:
$ git symbolic-ref HEAD refs/heads/foo
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: BUG 1.7.9: git branch fails to create new branch when --edit-description is used
From: Michael Haggerty @ 2012-01-29 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Jason Dominus, git
In-Reply-To: <7vbopoxp5q.fsf@alter.siamese.dyndns.org>
On 01/28/2012 08:27 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>>>> Where is branch blarf?
>>>
>>> You haven't created one in that sequence yet.
>>>
>>> This is more of a documentation bug.
>>>
>>> As the SYNOPSIS section makes it clear, the '--edit-description' is a
>>> separate mode from showing (the first group), creating or repointing (the
>>> second), or renaming (the third).
>>>
>>> After that you should be able to say "git branch blarf" and view its
>>> description.
>>
>> Given this design, shouldn't "git branch --edit-description" fail if the
>> branch doesn't already exist?
>
> The only use scenario in the original design was to have a way to store
> the description given a branch name, and giving a description to a branch
> that does not yet exist is outside the scope of the design. So it all
> boils down to what is the most convenient and the simplest to explain.
>
> We could error it out (i.e. you cannot name a thing that does not yet
> exist), or we could consider it is a convenience feature that you can
> prepare a description even before you create one, or we could even tweak
> it more like "-t $name" that tries to work both on existing one (without
> changing any base) or non-existing one, creating it while at it. The last
> approach historically is the most error prone (we had numerous bugs in the
> create_branch() helper after it started allowing an existing branch when
> updating the "track" information) and I would rather not go that route if
> we can avoid it.
>
> Honestly speaking, I haven't formed an opinion.
I vote for an error. Otherwise a typo in the branch name would lead to
the description's apparent disappearance into Nirvana. An error would,
for example, have made it clear to the OP what was happening.
A more useful option might be
git branch --with-description <branchname> [<start-point>]
i.e., that a branch's description can be set at the same time as the
branch is created.
>> Shouldn't it also resolve ambiguous reference names?
>
> As this mode, just like other modes of "git branch" _always_ takes a
> branch name, I do not think there is any "ambiguous reference name".
>
> You give $name to it, and it should always mean refs/heads/$name, and
> there shouldn't be any DWIMming to something like refs/heads/mh/$name
>
> Or do you have other kinds of ambiguity in mind?
OK, I wasn't aware that only local branches can have descriptions
attached to them. Given that fact, you are correct that DWIMming
doesn't make sense.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: BUG 1.7.9: git branch fails to create new branch when --edit-description is used
From: Junio C Hamano @ 2012-01-29 6:42 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Mark Jason Dominus, git
In-Reply-To: <4F24E78A.7060502@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 01/28/2012 08:27 AM, Junio C Hamano wrote:
>>
>> We could error it out (i.e. you cannot name a thing that does not yet
>> exist), or we could consider it is a convenience feature that you can
>> prepare a description even before you create one, or we could even tweak
>> it more like "-t $name" that tries to work both on existing one (without
>> changing any base) or non-existing one, creating it while at it. The last
>> approach historically is the most error prone (we had numerous bugs in the
>> create_branch() helper after it started allowing an existing branch when
>> updating the "track" information) and I would rather not go that route if
>> we can avoid it.
>>
>> Honestly speaking, I haven't formed an opinion.
>
> I vote for an error. Otherwise a typo in the branch name would lead to
> the description's apparent disappearance into Nirvana. An error would,
> for example, have made it clear to the OP what was happening.
>
> A more useful option might be
>
> git branch --with-description <branchname> [<start-point>]
>
> i.e., that a branch's description can be set at the same time as the
> branch is created.
So you are saying either option 1 or 3 is preferrable, while I was saying
I would rather avoid 3 if we could avoid it. Is that the short version?
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Junio C Hamano @ 2012-01-29 6:56 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4F24E287.3040302@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> When starting a new repo, git seems to insist that the first commit be
> made on a branch named "master":
>
> $ git --version
> git version 1.7.9
> $ git init git-test
> Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/
> $ cd git-test
> $ git checkout -b foo
> fatal: You are on a branch yet to be born
>
> I would call this a bug; the last command should be allowed. The
> plumbing allows it:
>
> $ git symbolic-ref HEAD refs/heads/foo
Your last sentence is nonsense. The plumbing equivalent of that command
is *not* what you wrote above, but is more like [*1*]:
git update-ref refs/heads/foo $(git rev-parse --verify HEAD) &&
git symbolic-ref HEAD refs/heads/foo
And the first step will fail the same way. While I share the sense of
annoyance with you, I do not think that it is a bug in "checkout -b".
When you are on an unborn branch, what the "symbolic-ref HEAD" command
reports does *not* appear in the output from the "for-each-ref refs/heads"
command (similarly, that branch name does not appear in the output from
the "git branch" command).
Such a behaviour indeed is *curious* and very *different* from the normal
case of being on an existing branch, but is that a bug?
You need to first admit that the state immediately after "git init" (or
for that matter, "checkout --orphan") where you are on an unborn branch
*is* special. Some things that would normally make sense would not.
[Footnote]
*1* Because you are not switching to a different commit, there won't be a
need for the third step which is "git read-tree -m -u HEAD@{1} HEAD" that
would usually be necessary if you are giving a starting commit that is
different from HEAD.
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Junio C Hamano @ 2012-01-29 7:50 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <7vwr8bvvxj.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ...
> Such a behaviour indeed is *curious* and very *different* from the normal
> case of being on an existing branch, but is that a bug?
>
> You need to first admit that the state immediately after "git init" (or
> for that matter, "checkout --orphan") where you are on an unborn branch
> *is* special. Some things that would normally make sense would not.
[sorry for having sent an incomplete message without conclusion]
The question then becomes this: what do you want to do about it with this
specific case, and more importantly what do you want to do about other
commands and options that would not make sense when HEAD knows what branch
the user wants to put the first commit on but there is no commit yet?
For some commands, we _do_ try to come up with a special case codepath so
that a command issued in the unborn state mimics the behaviour of the
command issued in the normal case to various different degrees. "git pull"
into an unborn branch simply resets to the other branch, for example, and
while technically speaking that is not merging the other branch into the
current commit (which does not exist), we do so because it was deemed to
be the most sensible behaviour to parallel the normal case.
I am not sure "git checkout -b foo" (without explict HEAD [*1*]) should
special case and degenerate to "symbolic-ref HEAD refs/heads/foo" when
HEAD points to a nonexistent branch. The mimicking does not go far enough
to satisfy people who are pedantic enough to expect "git checkout -b foo"
to work when you haven't even instantiated your current branch (when you
are on an already instantiated branch, after "git checkout -b foo", "git
branch" output will show both foo and the branch you were on, but if you
start from an unborn branch, the behaviour will be different and a pedant
will notice the difference).
It may make sense to let
$ git branch -m trunk
or even
$ git branch -m master trunk
move away from an unborn "master'"after "git init", with a special case
codepath. When you start from an instanticated branch, after a successful
such renaming, the original branch will not exist, and the new branch will
exist. This property would also hold true if you start from an unborn one,
so it would be much better mimickery than "git checkout -b foo" case you
brought up in this thread.
[Footnote]
*1* Given HEAD or $(git symbolic-ref HEAD) as the starting commit
explicitly, the command should error out.
^ permalink raw reply
* Re: BUG 1.7.9: git branch fails to create new branch when --edit-description is used
From: Michael Haggerty @ 2012-01-29 10:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Jason Dominus, git
In-Reply-To: <7v39azxb5l.fsf@alter.siamese.dyndns.org>
On 01/29/2012 07:42 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 01/28/2012 08:27 AM, Junio C Hamano wrote:
>>>
>>> We could error it out (i.e. you cannot name a thing that does not yet
>>> exist), or we could consider it is a convenience feature that you can
>>> prepare a description even before you create one, or we could even tweak
>>> it more like "-t $name" that tries to work both on existing one (without
>>> changing any base) or non-existing one, creating it while at it. The last
>>> approach historically is the most error prone (we had numerous bugs in the
>>> create_branch() helper after it started allowing an existing branch when
>>> updating the "track" information) and I would rather not go that route if
>>> we can avoid it.
>>>
>>> Honestly speaking, I haven't formed an opinion.
>>
>> I vote for an error. Otherwise a typo in the branch name would lead to
>> the description's apparent disappearance into Nirvana. An error would,
>> for example, have made it clear to the OP what was happening.
>>
>> A more useful option might be
>>
>> git branch --with-description <branchname> [<start-point>]
>>
>> i.e., that a branch's description can be set at the same time as the
>> branch is created.
>
> So you are saying either option 1 or 3 is preferrable, while I was saying
> I would rather avoid 3 if we could avoid it. Is that the short version?
Not quite. I agree that "--add-description" should fail if the branch
already exists. But I was suggesting that there be a new *different*
option that can be used when creating a branch. "--with-description" is
probably not a great name, but I think it is a good idea that it be
spelled differently than "--add-description". Perhaps even "--message",
even though the abbreviation "-m" is precluded by the existing "-m" option.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Torsten Bögershausen @ 2012-01-29 10:29 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git, Torsten Bögershausen
In-Reply-To: <CACsJy8BKQHLdoXfSKsULkWWbWjWEuZgr=bVNKmgCSArvwbf2UA@mail.gmail.com>
On 22.01.12 10:58, Nguyen Thai Ngoc Duy wrote:
> On Sun, Jan 22, 2012 at 5:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> [Pinging Nguyen who has worked rather extensively on the start-up sequence
>> for ideas.]
>>
[snip]
>
> I just have a quick look, you reencode opendir, readdir, and
> closedir() to precomposed form. But files are still in decomposed
> form, does open(<precomposed file>) work when only <decomposed file>
> exists?
Yes. All function like stat(), lstat(), open(), fopen(), unlink() behave the same
for precomped or decomposed. This is similar to the ignore case feature.
And because the default HFS+ is case preserving, case insenstive and unicode decomposing
all at the same time, a file name "Ä" could be reached under 4 different names.
Please see the output of the test script:
(which is at the end of this email)
tests/Darwin_i386/NFC file name created as nfc is readable as nfd
tests/Darwin_i386/NFC readdir returns nfd but expected is nfc
tests/Darwin_i386/NFD file name created as nfd is readable as nfc
tests/Darwin_i386/NFCNFD 1 file found in directory, but there should be 2
tests/Darwin_i386/NFCNFD nfc is missing, nfd is present
tests/Darwin_i386/NFCNFD nfc File content overwritten by nfd
tests/Darwin_i386/NFDNFC 1 file found in directory, but there should be 2
tests/Darwin_i386/NFDNFC nfc is missing, nfd is present
tests/Darwin_i386/NFDNFC nfd File content overwritten by nfc
>
>>> In order to prevent that ever a file name in decomposed unicode is
>>> entering the index, a "brute force" attempt is taken: all arguments into
>>> git (argv[1]..argv[n]) are converted into precomposed unicode. This is
>>> done in git.c by calling precompose_argv(). This function is actually a
>>> #define, and it is only defined under Mac OS. Nothing is converted on
>>> any other platforms.
>
> This is not entirely safe. Filenames can be taken from a file for
> example (--stdin option or similar). Unless I'm mistaken, all file
> names must enter git through the index, the conversion at read-cache.c
> may be a better option.
Good point, thanks.
I added some code to read-cache.c, and it works for files, but not for directories.
I looked through the code for "case-ignoring" directory names, and couldn't
find something obvious. More work is to be done.
[snip]
> I'd rather encode at index level and read_directory() than at argv[].
>But if reencoding argv is the only feasible way, perhaps put the
>conversion in parse_options()?
I tried that, and found that git-lsfiles.c doesn't use parse_options.
[snip]
On the long run I want to get rid of the argv[] conversion completely,
but I'm not there yet.
Thanks for all comments and inspiration!
(and apologies for my long response times I use to have)
/Torsten
PS:
Here the script.
Mac OS writes decomposd unicode to HFS+, precomposed unicode to VFAT and SAMBA.
In any case readdir() returns decomposed.
=================
#!/bin/sh
errorandout() {
echo Error: The shell can not handle nfd
echo try to run /bin/bash $0
rm -rf $DIR
exit 1
}
checkDirNfcOrNfd() {
DDNFCNFD=$1
readdirexp=$2
if test -r $DDNFCNFD/$aumlnfc; then
x=`cat $DDNFCNFD/$aumlnfc`
if test "$x" = nfd; then
echo $DDNFCNFD file name created as nfd is readable as nfc
fi
fi
if test -r $DDNFCNFD/$aumlnfd; then
x=`cat $DDNFCNFD/$aumlnfd 2>/dev/null` || {
echo $DDNFCNFD nfd is not readable, but readdir says that it exist
}
if test "$x" = nfc; then
echo $DDNFCNFD file name created as nfc is readable as nfd
fi
fi
readdirres=`echo $DDNFCNFD/*`
if test "$readdirres" != "$DDNFCNFD/$readdirexp"; then
if test "$readdirres" = $DDNFCNFD/$aumlnfd; then
echo $DDNFCNFD readdir returns nfd but expected is nfc
fi
if test "$readdirres" = $DDNFCNFD/$aumlnfc; then
echo $DDNFCNFD readdir returns nfc but expected is nfd
fi
fi
}
checkdirnfcnfd() {
DDNFCNFD=$1
if test `ls -1 $DDNFCNFD | wc -l` != 2; then
if test `ls -1 $DDNFCNFD | wc -l` == 1; then
echo $DDNFCNFD 1 file found in directory, but there should be 2
else
echo $DDNFCNFD 2 files should be in directory
fi
fi
x=`echo $DDNFCNFD/*`
a=`echo $DDNFCNFD/$aumlnfd $DDNFCNFD/$aumlnfc`
b=`echo $DDNFCNFD/$aumlnfc $DDNFCNFD/$aumlnfd`
c=`echo $DDNFCNFD/$aumlnfc $DDNFCNFD/$aumlnfc`
d=`echo $DDNFCNFD/$aumlnfd $DDNFCNFD/$aumlnfd`
e=`echo $DDNFCNFD/$aumlnfc`
f=`echo $DDNFCNFD/$aumlnfd`
case "$x" in
$a)
;;
$b)
;;
$c)
echo $DDNFCNFD nfd is hidden, nfc is listed twice
;;
$d)
echo $DDNFCNFD nfc is hidden, nfd is listed twice
;;
$e)
echo $DDNFCNFD nfd is missing, nfc is present
;;
$f)
echo $DDNFCNFD nfc is missing, nfd is present
;;
*)
echo $DDNFCNFD x`echo $x | xxd`
;;
esac
if ! test -r $DDNFCNFD/$aumlnfc; then
echo $DDNFCNFD/nfc File does not exist
else
x=`cat $DDNFCNFD/$aumlnfc`
if test "$x" != nfc; then
echo $DDNFCNFD nfc File content overwritten by $x
fi
fi
if ! test -r $DDNFCNFD/$aumlnfd; then
echo $DDNFCNFD/nfd File does not exist
else
x=`cat $DDNFCNFD/$aumlnfd`
if test "$x" != nfd; then
echo $DDNFCNFD nfd File content overwritten by $x
fi
fi
}
aumlnfc=$(printf '\303\204')
aumlnfd=$(printf '\101\314\210')
DIR=tests/`uname -s`_`uname -m`
echo "DIR=$DIR"
rm -rf $DIR/NFC &&
rm -rf $DIR/NFD &&
rm -rf $DIR/NFCNFD &&
rm -rf $DIR/NFDNFC &&
mkdir -p $DIR/NFC &&
mkdir -p $DIR/NFD &&
mkdir -p $DIR/NFDNFC &&
mkdir -p $DIR/NFCNFD &&
echo nfc > $DIR/NFC/$aumlnfc &&
echo nfd > $DIR/NFD/$aumlnfd &&
echo nfd > $DIR/NFDNFC/$aumlnfd &&
echo nfc > $DIR/NFDNFC/$aumlnfc &&
echo nfc > $DIR/NFCNFD/$aumlnfc &&
echo nfd > $DIR/NFCNFD/$aumlnfd && {
# test 1: basic if the shell handles nfd
if ! test -r $DIR/NFD/$aumlnfd; then
errorandout
fi
for DD in tests/*; do
checkDirNfcOrNfd $DD/NFC $aumlnfc
checkDirNfcOrNfd $DD/NFD $aumlnfd
checkdirnfcnfd $DD/NFCNFD
checkdirnfcnfd $DD/NFDNFC
done
} || errorandout
^ 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