* Re: [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-30 13:51 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <87pqe1nx9a.fsf@thomas.inf.ethz.ch>
On Mon, Jan 30, 2012 at 3:19 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, Jan 30, 2012 at 10:22 AM, Junio C Hamano <jch2355@gmail.com> wrote:
>>> Thomas Rast <trast@inf.ethz.ch> wrote:
>>>>Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>
>>>>> No reason. I hope they read the mailing list, otherwise I'll resend
>>>>> and CC them. A get_maintainers script, or something like that would
>>>>> make things easier.
>>>>
>>>>I simply use
>>>>
>>>> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>>>>
>>>>(In many parts the revision limiter can be omitted without losing much,
>>>>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
>>>
>>> Or "--since=1.year", which you can keep using forever without adjusting.
>>
>> Perhaps something like that can be stored in a script somewhere in
>> git's codebase so that people can set sendemail.cccmd to that.
>
> Umm, that seems rather AI-complete. You should always compile the list
> by hand.
Why? Take a look at the Linux kernel; having tons of contributors,
many still haven't learned the ropes, and looking at MAINTAIERS, plus
the output of 'git blame', for potentially dozens of patches is too
burdensome, which is why they have 'scripts/get_maintainer.pl' that
does a pretty good job of figuring out who to cc so you don't have to
think about it.
> Ok, this got rather long-winded. But I think the bottom line is, trying
> to put this in sendemail.cccmd is trying to script common sense.
It's still better than nothing.
I once wrote a much smarter script[1], but it never go into the tree.
The output I get is this:
"Shawn O. Pearce" <spearce@spearce.org>>
"Jonathan Nieder" <jrnieder@gmail.com>
"Mark Lodato" <lodatom@gmail.com>
"Junio C Hamano" <junkio@cox.net>
"Ted Pavlic" <ted@tedpavlic.com>
Note: seems like there's a bug with git blame -P:
% g blame -p -L 2730,+33 contrib/completion/git-completion.bash | grep
author-mail
And if this script is such a bad idea; why do you think sendmail.cccmd exists?
I think we should have a simple script that at least does something
sensible, at least in contrib, but I hope we could even have a
standard git-cccmd that all projects could use.
It looks like my ruby script never had much of a chance getting
anywhere, so would it be accepted in another format? perl? python?
bash?
Cheers.
[1] http://thread.gmane.org/gmane.comp.version-control.git/130391
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Jakub Narebski @ 2012-01-30 13:42 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Junio C Hamano, git
In-Reply-To: <20120130114447.GA9267@server.brlink.eu>
Bernhard R. Link wrote:
> @@ -6066,7 +6069,7 @@ sub git_summary {
>
> if ($check_forks) {
> # find forks of a project
> - @forklist = git_get_projects_list($project);
> + @forklist = git_get_projects_list($project =~ s/\.git$//r);
> # filter out forks of forks
> @forklist = filter_forks_from_projects_list(\@forklist)
> if (@forklist);
> --
The '/r' non-destructive modifier for regexp replacement is quite new
invention and requires Perl 5.14, while gitweb requires Perl 5.8.x
something. Please don't use it.
You can use this instead.
(my $filter = $project) =~ s/\.git$//
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] completion: --edit option for git-merge
From: Adrian Weimann @ 2012-01-30 13:37 UTC (permalink / raw)
To: git, gitster; +Cc: Adrian Weimann
Signed-off-by: Adrian Weimann <adrian.weimann@googlemail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1496c6d..be1fcea 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1622,7 +1622,7 @@ _git_log ()
__git_merge_options="
--no-commit --no-stat --log --no-log --squash --strategy
- --commit --stat --no-squash --ff --no-ff --ff-only
+ --commit --stat --no-squash --ff --no-ff --ff-only --edit
"
_git_merge ()
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 3/3] completion: remove unused code
From: Thomas Rast @ 2012-01-30 13:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAMP44s2ooo1uArhhtJkX3S9N=iE4MNJivMSvr3hsOkxFmJupFA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Mon, Jan 30, 2012 at 10:22 AM, Junio C Hamano <jch2355@gmail.com> wrote:
>> Thomas Rast <trast@inf.ethz.ch> wrote:
>>>Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> No reason. I hope they read the mailing list, otherwise I'll resend
>>>> and CC them. A get_maintainers script, or something like that would
>>>> make things easier.
>>>
>>>I simply use
>>>
>>> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>>>
>>>(In many parts the revision limiter can be omitted without losing much,
>>>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
>>
>> Or "--since=1.year", which you can keep using forever without adjusting.
>
> Perhaps something like that can be stored in a script somewhere in
> git's codebase so that people can set sendemail.cccmd to that.
Umm, that seems rather AI-complete. You should always compile the list
by hand.
For example, the list in this case started
25 SZEDER Gábor
4 Michael J Gruber
3 Teemu Matilainen
3 Thomas Rast
Would you Cc Michael, Teemu and me? Probably not. What if it started
5 SZEDER Gábor
4 Michael J Gruber
3 Teemu Matilainen
3 Thomas Rast
Also, something I didn't mention so far was that you may be patching
squarely into the code of one contributor, even if he only had a single
patch in that area. To catch this, you should blame the code you are
fixing (you already checked the message of the commit to verify whether
the bug/feature was intentional, right?). On top of that, the patch may
have involved a large number of people not listed in the Author field.
As a random example,
$ git shortlog -sn --no-merges v1.7.0..origin/next -- grep.[ch] builtin/grep.[ch]
15 René Scharfe
9 Junio C Hamano
8 Nguyễn Thái Ngọc Duy
5 Michał Kiedrowicz
4 Johannes Schindelin
3 Jeff King
3 Thomas Rast
but if you were to submit a patch that disputes the case made by
53b8d931, you should probably cc René, Peff and me (see the Helped-by
lines).
Ok, this got rather long-winded. But I think the bottom line is, trying
to put this in sendemail.cccmd is trying to script common sense.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Frans Klaver @ 2012-01-30 12:21 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAMP44s3a05dZqOqpDFDnWQ_C03EODgeP1eRhko-Mc8OjGXj6FQ@mail.gmail.com>
On Mon, Jan 30, 2012 at 12:55 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> We are not talking about backwards compatibility; we are talking about
> compatibility of remotes completion of the bash completion script of
> repositories more than 3 years old with remotes that haven't been
> migrated.
What's not backward about that?
> This barely resembles the git-foo -> 'git foo', which truly broke
> backwards compatibility, and at the time I proposed many different
> approaches to deal with these type of problems, which seem to be
> followed now (although probably not because of my recommendations).
>
> But this has nothing to do with _attitude_; I am merely stating fact.
> I have never expressed any opinion or attitude with respect to how
> backwards compatibility should be handled in this thread, have I?
As far as I know you haven't explicitly said anything about that.
There may still be a possibility that the sentence Junio quoted in his
reply could have implied a certain attitude.
>> Maybe numbers for this could be generated from the next git user
>> survey. If numbers justify this change, maybe this or something like
>> it could be scheduled for a major release of git.
>
> Maybe, but I doubt this issue hardly deserves much discussion.
I wouldn't know about that. Apparently not everybody is happy with
applying it without further discussion.
Cheers,
Frans
^ permalink raw reply
* Re: Autocompletion - commands no longer work as stand alone
From: Nathan Bullock @ 2012-01-30 12:00 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, git
In-Reply-To: <20120124232658.GD2256@goldbirke>
2012/1/24 SZEDER Gábor <szeder@ira.uka.de>:
> Hi,
>
>
>> Nathan Bullock <nathanbullock@gmail.com> writes:
>>
>> > I have for a number of years had the following in my .bashrc
>> >
>> > alias br="git branch"
>> > complete -F _git_branch br
>> >
>> > As well as similar commands for co and log.
>> >
>> > Recently though this broke, now when I type something like "br
>> > mas<command completion>" it will occasionally complain with messages
>> > like:
>> > bash: [: 1: unary operator expected
>> >
>> > From digging through the source it looks like this was broken back in
>> > April. (The commit is show at the bottom of this email.)
>> >
>> > So my questions are:
>> > 1. Is it reasonable for things like _git_branch to work as a
>> > standalone autocompletion function instead of having to go through
>> > _git? I certainly like it to work as a standalone function. I also use
>> > it to add autocompletion to other bash scripts that I use frequently.
>> >
>> > 2. If I add code that verifies that the variable cword exists at the
>> > start of these functions and only if not call something like
>> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be
>> > reasonable?
>
> That would be too fragile, it will break if $cword is set in the
> environment from which you invoke _git_<cmd>() completion functions
> directly (i.e. not though _git()).
>
>> > I think this should address the performance concerns that
>> > caused these to be removed in the first place, but it may make the
>> > code uglier.
>
> Actually it was not a performance problem, but a cleanup in a patch
> series to fix a zsh-related bug. Without this cleanup the bugfix
> would have been much more intrusive.
>
> http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369
>
>
>> > I have already added wrapper functions in my bashrc so that this is no
>> > longer a problem for me, but there may be other people who start
>> > hitting this as well once they start using newer versions of git.
>
> This issue was reported earlier, so it seems there are people who
> would like to use it. But getting $cur, $cword, etc. variables right
> in _git_<cmd>() completion functions is just part of the problem,
> there are other issues, as mentioned in the previous thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232
>
> Unfortunately, I couldn't come up with a solution yet that doesn't
> introduce too much code churn and doesn't cause yet another
> inconsistency between bash and zsh. I also haven't looked whether
> there are other issues similar to that with _git_fetch() mentioned on
> the above link.
At the end of this thread that you refer to,
http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232,
there is a set of wrapper functions that look reasonably good for
solving this problem. There was a question if those could be included
in the main git code base. Do you know if that is likely to happen?
Nathan
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 11:55 UTC (permalink / raw)
To: Frans Klaver; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAH6sp9Of2rT4ESMYj9kC2NPtapsN58X3A0FpHTTZO-kSqpb-2Q@mail.gmail.com>
On Mon, Jan 30, 2012 at 1:19 PM, Frans Klaver <fransklaver@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 11:51 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> OK, maybe some people use it, but most likely they are using an old
>>>> version of git, and thus an old version of the completion script.
>>>
>>> Please adjust your attitude about backward compatibility to match the
>>> standard used for other parts of Git.
>>
>> What attitude?
>
> This attitude:
>
>> I am simply stating a fact. How much percentage of
>> people do you think still have .git/remotes around? How many people do
>> you think have clones more than 3 years old? And how many of these
>> people would complain if remotes were not properly completed for these
>> repos?
>>
>> I doubt anybody would have complained, but I guess we would never
>> know, because I already proposed a solution that would work for them
>> and only uses a *single* line of code, unlike the current 40 ones.
>>
>> I don't see what is the problem with the attitude of sending a patch
>> to remove code that most likely nobody cares about (neither you or I
>> have numbers on this), and then finding an alternative when people do
>> care about it.
>
> I don't think Junio actually meant an "attitude", but just your angle
> of approach (== attitude) on backwards compatibility.
We are not talking about backwards compatibility; we are talking about
compatibility of remotes completion of the bash completion script of
repositories more than 3 years old with remotes that haven't been
migrated.
This barely resembles the git-foo -> 'git foo', which truly broke
backwards compatibility, and at the time I proposed many different
approaches to deal with these type of problems, which seem to be
followed now (although probably not because of my recommendations).
But this has nothing to do with _attitude_; I am merely stating fact.
I have never expressed any opinion or attitude with respect to how
backwards compatibility should be handled in this thread, have I?
> Maybe numbers for this could be generated from the next git user
> survey. If numbers justify this change, maybe this or something like
> it could be scheduled for a major release of git.
Maybe, but I doubt this issue hardly deserves much discussion.
Nobody is proposing to break backwards compatibility--as you can see,
I already proposed a simple solution that should work.
And FTR, when I wrote 'We don't need to check for GIT_DIR/remotes,
right? This was removed long time ago." I clearly wasn't sure if
.git/remotes was still used or not, after Jonathan Nieder replied, I
checked the source code of remotes.c, and I found that it was still
supported, so I wrote the proposed alternative.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v5 5/5] gitweb: place links to parent directories in page header
From: Bernhard R. Link @ 2012-01-30 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
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. (Allowing to jump to a list of all projects within
that intermediate directory directly and making the project_filter
feature visible to users).
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index dfc79df..b54ddb9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3853,7 +3853,10 @@ 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;
+ print_nav_breadcrumbs_path(@dirname);
+ print $cgi->a({-href => href(action=>"summary")}, esc_html($projectbasename));
if (defined $action) {
my $action_print = $action ;
if (defined $opts{-action_extra}) {
--
1.7.8.3
^ permalink raw reply related
* [PATCH v5 4/5] gitweb: show active project_filter in project_list page header
From: Bernhard R. Link @ 2012-01-30 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
In a project_list view show breadcrumbs with the currently active
project_filter (and those of parent directories) in the page header.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e022e11..dfc79df 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3836,6 +3836,18 @@ sub print_header_links {
}
}
+sub print_nav_breadcrumbs_path {
+ my $dirprefix = undef;
+ while (my $part = shift) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project => undef,
+ project_filter => $dirprefix,
+ action=>"project_list")},
+ esc_html($part)) . " / ";
+ }
+}
+
sub print_nav_breadcrumbs {
my %opts = @_;
@@ -3854,6 +3866,8 @@ sub print_nav_breadcrumbs {
print " / $opts{-action_extra}";
}
print "\n";
+ } elsif (defined $project_filter) {
+ print_nav_breadcrumbs_path(split '/', $project_filter);
}
}
--
1.7.8.3
^ permalink raw reply related
* Re: i18n: Avoid sentence puzzles
From: Nguyen Thai Ngoc Duy @ 2012-01-30 11:46 UTC (permalink / raw)
To: Frederik Schwarzer; +Cc: git
In-Reply-To: <201201301231.21090.schwarzerf@gmail.com>
On Mon, Jan 30, 2012 at 6:31 PM, Frederik Schwarzer
<schwarzerf@gmail.com> wrote:
> Hi,
>
> in order to enable translators to prepare proper translations,
> sentence puzzles have to be avoided. While it makes perfect sense for
> English, some languages may have to separate those words to sound or
> even be correct.
>
> The attached patch demonstrates a change to achive that.
> ...
> So my question would be: Is it considered worth it to extend the code
> for translators' and translations' sake? If so, I would be glad to
> help with that.
As a translator (though not git's because my time is limited and GUI
apps have my priority), I completely agree and support this. There are
other places where a sentence is broken down into many short phrases.
It's hard for a translator to find a good translation in such cases.
I remember there was also a patch about "1 file vs 2 files" in diff
summary, which was rejected because it would break scripts. I think
grammar patches should be allowed at least for interactive use (i.e.
either pager is on, or std{out,err} is tty).
--
Duy
^ permalink raw reply
* [PATCH 3/5] gitweb: limit links to alternate forms of project_list to active project_filter
From: Bernhard R. Link @ 2012-01-30 11:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
If project_list action is given a project_filter argument, pass that to
TXT and OPML formats.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 36efc10..e022e11 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3976,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";
}
print "</div>\n"; # class="page_footer"
--
1.7.8.3
^ permalink raw reply related
* [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
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 implementation of the filter reuses the implementation used for
the 'forks' action (i.e. listing all projects within that directory
from the projects list file (GITWEB_LIST) or only projects in the
given subdirectory of the project root directory without a projects
list file).
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.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index acf1bae..36efc10 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)) {
@@ -5984,7 +5992,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");
}
@@ -6023,7 +6031,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");
}
@@ -7860,7 +7868,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 v5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Bernhard R. Link @ 2012-01-30 11:44 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
Use of the filter option of git_get_projects_list is currently
limited to forks. It hard codes removal of ".git" suffixes from
the filter and assumes the project belonging to the filter directory
was already validated to be visible in the project list.
To make it more generic move the .git suffix removal to the callers
and add an optional argument to denote visibility verification is
still needed.
If there is a projects list file (GITWEB_LIST) only projects from
this list are returned anyway, so no more checks needed.
If there is no projects list file and the caller requests strict
checking (GITWEB_STRICT_EXPORT), do not jump directly to the
given directory but instead do a normal search and filter the
results instead.
The only (hopefully non-existing) effect of GITWEB_STRICT_EXPORT
without GITWEB_LIST is to make sure no project can be viewed without
also be found starting from project root. git_get_projects_list without
this patch does not enforce this but all callers only call it with
a filter already checked this way. With this parameter a caller
can request this check if the filter cannot be checked this way.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes to v4:
- split patch in smaller parts
- move ".git" suffix removal from filters to forks specific code
(if you want this as patch on top of the previous series, let me know)
- improve the descriptions of all patches
---
gitweb/gitweb.perl | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..acf1bae 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2829,10 +2829,9 @@ sub git_get_project_url_list {
sub git_get_projects_list {
my $filter = shift || '';
+ my $paranoid = shift;
my @list;
- $filter =~ s/\.git$//;
-
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
@@ -2841,7 +2840,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!/+$!!;
}
@@ -2866,6 +2865,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 };
@@ -6007,7 +6010,7 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list($project);
+ my @list = git_get_projects_list($project =~ s/\.git$//r);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6066,7 +6069,7 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list($project);
+ @forklist = git_get_projects_list($project =~ s/\.git$//r);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 11:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, git
In-Reply-To: <4F267AC9.1080407@viscovery.net>
On Mon, Jan 30, 2012 at 1:11 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 1/30/2012 9:39, schrieb Matthieu Moy:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>>
>> Probably stating the obvious, but this path shouldn't be hardcoded.
>>
>> Something along the lines of
>>
>> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>
>> should do it (mostly untested, and written by a non-ZSH expert).
>
> Moreover, if zsh is POSIX compliant, the value of ZSH_VERSION will be an
> empty string after this statement. That may or (more likely) may not be
> what you want.
It's not, only inside that script. Same in bash.
And that's exactly what I want... I wan the git-completion.bash to
avoid any zsh hacks and workarounds.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* i18n: Avoid sentence puzzles
From: Frederik Schwarzer @ 2012-01-30 11:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
Hi,
in order to enable translators to prepare proper translations,
sentence puzzles have to be avoided. While it makes perfect sense for
English, some languages may have to separate those words to sound or
even be correct.
The attached patch demonstrates a change to achive that. I did not
test it because its purpose is only to raise awareness and start a
discussion about this topic. After all the question is, how important
translations are for a tool like Git. I have started a German
translation but many things are really hard to translate.
1) Many words are used in a germanised way, so translating them
not only feels awkward in some cases but it also might confuse
users who are used to the original wording.
2) English is a language that can be used in a very compact way.
In German that can feel dumb or even rude. So texts can grow
up to twice or thrice their size. That can clutter the terminal
appearance quite a bit.
Given those problems many people avoid using command line tools in
their language and I see the usefulness of translations rather
limited.
So my question would be: Is it considered worth it to extend the code
for translators' and translations' sake? If so, I would be glad to
help with that.
Regards
[-- Attachment #2: 0001-Avoid-puzzle-sentences.patch --]
[-- Type: text/x-patch, Size: 2440 bytes --]
From 7b1475cbffe120fdae1b46a2974a7b94846702c4 Mon Sep 17 00:00:00 2001
From: Frederik Schwarzer <schwarzerf@gmail.com>
Date: Mon, 30 Jan 2012 12:02:46 +0100
Subject: [PATCH] Avoid puzzle sentences.
---
builtin/branch.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7095718..a07ac54 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -154,18 +154,17 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
const char *fmt, *remote;
int i;
int ret = 0;
+ int is_remote = 0;
struct strbuf bname = STRBUF_INIT;
switch (kinds) {
case REF_REMOTE_BRANCH:
fmt = "refs/remotes/%s";
- /* TRANSLATORS: This is "remote " in "remote branch '%s' not found" */
- remote = _("remote ");
+ is_remote = 1;
force = 1;
break;
case REF_LOCAL_BRANCH:
fmt = "refs/heads/%s";
- remote = "";
break;
default:
die(_("cannot use -a with -d"));
@@ -189,8 +188,11 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
name = xstrdup(mkpath(fmt, bname.buf));
if (read_ref(name, sha1)) {
- error(_("%sbranch '%s' not found."),
- remote, bname.buf);
+ if (is_remote) {
+ error(_("remote branch '%s' not found."), bname.buf);
+ } else {
+ error(_("branch '%s' not found."), bname.buf);
+ }
ret = 1;
continue;
}
@@ -211,14 +213,21 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
}
if (delete_ref(name, sha1, 0)) {
- error(_("Error deleting %sbranch '%s'"), remote,
- bname.buf);
+ if (is_remote) {
+ error(_("Error deleting remote branch '%s'"), bname.buf);
+ } else {
+ error(_("Error deleting branch '%s'"), bname.buf);
+ }
ret = 1;
} else {
struct strbuf buf = STRBUF_INIT;
- printf(_("Deleted %sbranch %s (was %s).\n"), remote,
- bname.buf,
+ if (is_remote) {
+ printf(_("Deleted remote branch %s (was %s).\n"), bname.buf,
find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ } else {
+ printf(_("Deleted branch %s (was %s).\n"), bname.buf,
+ find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ }
strbuf_addf(&buf, "branch.%s", bname.buf);
if (git_config_rename_section(buf.buf, NULL) < 0)
warning(_("Update of config-file failed"));
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 11:28 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <CAMP44s3QeZuXrR=UE4qvDadu66Cmi-txmSps8Ow24om27URxOg@mail.gmail.com>
On Mon, Jan 30, 2012 at 12:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 10:39 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>>
>> Probably stating the obvious, but this path shouldn't be hardcoded.
>>
>> Something along the lines of
>>
>> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>>
>> should do it (mostly untested, and written by a non-ZSH expert).
>
> Yes, it's hard-coded, because there's no way to know where is this
> file. In my case, it's on ~/.git-completion.sh, and this one that I am
> proposing sits in ~/.zsh/completion/_zsh, so your proposal breaks
> things completely for me.
>
> I will think about it, but I think for now, users of this script
> should set that manually--if for some reason they don't want to use
> the default.
>
> Maybe we should use zstyle so they can configure it on their .zshrc?
This seems to do the trick:
zstyle -s ":completion:$curcontext:" script script
test -z "$script" && script="$(dirname
${funcsourcetrace[1]%:*})"/git-completion.bash
ZSH_VERSION='' . "$script"
.zshrc:
zstyle ':completion:*:*:git:*' script ~/.git-completion.sh
--
Felipe Contreras
^ permalink raw reply
* [PATCH] find_pack_entry(): do not keep packed_git pointer locally
From: Nguyễn Thái Ngọc Duy @ 2012-01-30 11:25 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Commit f7c22cc (always start looking up objects in the last used pack
first - 2007-05-30) introduces a static packed_git* pointer as an
optimization. The kept pointer however may become invalid if
free_pack_by_name() happens to free that particular pack.
Current code base does not access packs after calling
free_pack_by_name() so it should not be a problem. Anyway, move the
pointer out so that free_pack_by_name() can reset it to avoid running
into troubles in future.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_file.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 88f2151..4ecc953 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -54,6 +54,8 @@ static struct cached_object empty_tree = {
0
};
+static struct packed_git *find_pack_entry_last_found = (void *)1;
+
static struct cached_object *find_cached_object(const unsigned char *sha1)
{
int i;
@@ -720,6 +722,8 @@ void free_pack_by_name(const char *pack_name)
close_pack_index(p);
free(p->bad_object_sha1);
*pp = p->next;
+ if (find_pack_entry_last_found == p)
+ find_pack_entry_last_found = (void*)1;
free(p);
return;
}
@@ -2012,14 +2016,13 @@ int is_pack_valid(struct packed_git *p)
static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
{
- static struct packed_git *last_found = (void *)1;
struct packed_git *p;
off_t offset;
prepare_packed_git();
if (!packed_git)
return 0;
- p = (last_found == (void *)1) ? packed_git : last_found;
+ p = (find_pack_entry_last_found == (void *)1) ? packed_git : find_pack_entry_last_found;
do {
if (p->num_bad_objects) {
@@ -2046,16 +2049,16 @@ static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
e->offset = offset;
e->p = p;
hashcpy(e->sha1, sha1);
- last_found = p;
+ find_pack_entry_last_found = p;
return 1;
}
next:
- if (p == last_found)
+ if (p == find_pack_entry_last_found)
p = packed_git;
else
p = p->next;
- if (p == last_found)
+ if (p == find_pack_entry_last_found)
p = p->next;
} while (p);
return 0;
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: [PATCH 2/3] completion: remove old code
From: Frans Klaver @ 2012-01-30 11:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAMP44s2j+qotu8Fb-1qq9bqHqt+ZF877YzZFXHiMo7Z_BGzTMA@mail.gmail.com>
Hi,
On Mon, Jan 30, 2012 at 11:51 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> OK, maybe some people use it, but most likely they are using an old
>>> version of git, and thus an old version of the completion script.
>>
>> Please adjust your attitude about backward compatibility to match the
>> standard used for other parts of Git.
>
> What attitude?
This attitude:
> I am simply stating a fact. How much percentage of
> people do you think still have .git/remotes around? How many people do
> you think have clones more than 3 years old? And how many of these
> people would complain if remotes were not properly completed for these
> repos?
>
> I doubt anybody would have complained, but I guess we would never
> know, because I already proposed a solution that would work for them
> and only uses a *single* line of code, unlike the current 40 ones.
>
> I don't see what is the problem with the attitude of sending a patch
> to remove code that most likely nobody cares about (neither you or I
> have numbers on this), and then finding an alternative when people do
> care about it.
I don't think Junio actually meant an "attitude", but just your angle
of approach (== attitude) on backwards compatibility.
Maybe numbers for this could be generated from the next git user
survey. If numbers justify this change, maybe this or something like
it could be scheduled for a major release of git.
Cheers,
Frans
^ permalink raw reply
* Re: [PATCH] completion: add new zsh completion
From: Johannes Sixt @ 2012-01-30 11:11 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Felipe Contreras, git
In-Reply-To: <vpqwr89d1p7.fsf@bauges.imag.fr>
Am 1/30/2012 9:39, schrieb Matthieu Moy:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>
> Probably stating the obvious, but this path shouldn't be hardcoded.
>
> Something along the lines of
>
> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>
> should do it (mostly untested, and written by a non-ZSH expert).
Moreover, if zsh is POSIX compliant, the value of ZSH_VERSION will be an
empty string after this statement. That may or (more likely) may not be
what you want.
-- Hannes
^ permalink raw reply
* Re: [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 10:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqwr89d1p7.fsf@bauges.imag.fr>
On Mon, Jan 30, 2012 at 10:39 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
>
> Probably stating the obvious, but this path shouldn't be hardcoded.
>
> Something along the lines of
>
> ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
>
> should do it (mostly untested, and written by a non-ZSH expert).
Yes, it's hard-coded, because there's no way to know where is this
file. In my case, it's on ~/.git-completion.sh, and this one that I am
proposing sits in ~/.zsh/completion/_zsh, so your proposal breaks
things completely for me.
I will think about it, but I think for now, users of this script
should set that manually--if for some reason they don't want to use
the default.
Maybe we should use zstyle so they can configure it on their .zshrc?
--
Felipe Contreras
^ permalink raw reply
* [PATCH] use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Nicholas Harteau @ 2012-01-30 10:51 UTC (permalink / raw)
To: git
perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
is not present. perl can't "use Git;" in that scenario, as $prefix/lib
isn't in perl's include path.
This patch installs Git.pm into perl's 'installsitelib', generally
$prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
present, Git.pm gets installed in a location where 'use Git;' just
works.
for some additional discussion, see:
https://github.com/mxcl/homebrew/pull/8643
https://github.com/mxcl/homebrew/issues/8620
---
perl/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index b2977cd..2199eb1 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -21,7 +21,7 @@ clean:
$(RM) $(makfile).old
ifdef NO_PERL_MAKEMAKER
-instdir_SQ = $(subst ','\'',$(prefix)/lib)
+instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
$(makfile): ../GIT-CFLAGS Makefile
echo all: private-Error.pm Git.pm > $@
echo ' mkdir -p blib/lib' >> $@
--
1.7.8.3
--
nicholas harteau
nrh@spotify.com
^ permalink raw reply related
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vd3a1erwf.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> OK, maybe some people use it, but most likely they are using an old
>> version of git, and thus an old version of the completion script.
>
> Please adjust your attitude about backward compatibility to match the
> standard used for other parts of Git.
What attitude? I am simply stating a fact. How much percentage of
people do you think still have .git/remotes around? How many people do
you think have clones more than 3 years old? And how many of these
people would complain if remotes were not properly completed for these
repos?
I doubt anybody would have complained, but I guess we would never
know, because I already proposed a solution that would work for them
and only uses a *single* line of code, unlike the current 40 ones.
I don't see what is the problem with the attitude of sending a patch
to remove code that most likely nobody cares about (neither you or I
have numbers on this), and then finding an alternative when people do
care about it.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: L10n for Git in Chinese begins
From: Ævar Arnfjörð Bjarmason @ 2012-01-30 10:40 UTC (permalink / raw)
To: worldhello.net; +Cc: Git List
In-Reply-To: <4F265AEF.5020409@gmail.com>
2012/1/30 Jiang Xin <worldhello.net@gmail.com>:
> With the release of v1.7.9 or some earlier , Git is multilingual.
> I select some typical git commands and translated into Chinese,
> works nice.
>
> - git status (in c)
> - git stash (in bash)
>
> Now I create a repo in Github hosting the po file (zh_cn.po) for git.
>
> - repo: https://github.com/gotgit/git-l10n-zh-cn/
> - file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
>
> Any help is appreciated, and will contribute here after 100% completed.
That's awesome, especially to get someone covering a really big
language whose speakers aren't usually near-native English speakers.
Please tell me if you have any problems, especially with the
instructions I added in po/README or anything else. I'd be happy to
fix them in Git if applicable.
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-30 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jonathan Nieder, git
In-Reply-To: <25ea208e-353d-48f7-a849-143689fb2be6@email.android.com>
On Mon, Jan 30, 2012 at 10:22 AM, Junio C Hamano <jch2355@gmail.com> wrote:
> Thomas Rast <trast@inf.ethz.ch> wrote:
>>Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> No reason. I hope they read the mailing list, otherwise I'll resend
>>> and CC them. A get_maintainers script, or something like that would
>>> make things easier.
>>
>>I simply use
>>
>> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>>
>>(In many parts the revision limiter can be omitted without losing much,
>>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
>
> Or "--since=1.year", which you can keep using forever without adjusting.
Perhaps something like that can be stored in a script somewhere in
git's codebase so that people can set sendemail.cccmd to that.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 6:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Let's avoid it. This has the advantage that the code is now actually
>> understandable (at least to me), while before it looked like voodoo.
>
> I am somewhat hesitant to accept a patch to shell scripts on the basis
> that the patch author does not understand the existing constructs that
> are standard parts of shell idioms.
I have been writing shell scripts for years[1], and I have *never* had
an encounter with ':'. vim's sh syntax doesn't seem to be prepared for
it, and zsh's sh emulation has problems only when ':' is involved, so
I still think ':' is quite obscure.
Plus, I haven't seen ${foo:=bar} that often.
In any case, there's no need for ad hominem arguments; there is a
problem when using zsh, that's a fact.
[1] https://www.ohloh.net/accounts/felipec/positions/total
--
Felipe Contreras
^ 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