* Re: [PATCH 4/4] config: allow including config from repository blobs
From: Junio C Hamano @ 2012-01-27 23:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, git
In-Reply-To: <4F2251D4.9060005@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 1/27/2012 6:42, schrieb Jeff King:
>> That being said, I think it would be nicer for projects to carry meta
>> information like this out-of-tree in a special ref. It's just simpler to
>> work with, and it means the project's source isn't polluted with extra
>> junk.
>
> Really? I doubt that carrying configuration in a special ref outside the
> normal contents will have any practical relevance:
>
> To manage such a config file would mean to switch to a branch with
> entirely different contents. But before you can test the new configuration
> in action, you have to commit, switch branches, which exchanges the
> worktree completely; and if the config change didn't work out, repeat the
> process (and if we are talking about source code repository, this usally
> includes a complete rebuild). Sure, you could keep the config branch in a
> separate repository, but, again, how do you test an updated configuration?
> It is not funny, and nobody will go this route.
>
> Which raises doubts about the usefulness of the include.ref feature.
Hmm, good point.
What I envisioned, when I said "meta:gitconfig" might make sense, was to
do something like:
* have a separate worktree via git-new-worktree in meta/, so that you
do not have to switch away from the "source" branch and trash the
working tree for it; and
* update meta/gitconfig, perhaps make commit there, and possibly push
it back for public consuption.
In other words, I think "you *could* keep the config branch in a separate
repository" is more like "you would most likely want to have a separate
checkout of the config branch for this 'meta' branch to be useful".
And at that point, as you said, setting include.path = meta/gitconfig
(with possibly adding meta/ in .git/info/exclude) would be far more
pleasant, because you would have a chance to experiment your changes to
the file before committing it.
So having include.ref, while it is a fun thought experiment, would not
help very much in the real life.
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Junio C Hamano @ 2012-01-27 23:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ondra Medek, git
In-Reply-To: <m3aa58eskw.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Ondra Medek <xmedeko@gmail.com> writes:
>
>> we have gitweb running on Linux box. Some files have Windows line ending
>> (CRLF) end we do not use core.autcrlf translation. gitweb show the last \r
>> in the end of each line, which is annoying.
>
> Well, this "\r" allows to recognize when file with Windows line ending
> (CRLF) made it into repository... which usually is discouraged. But
> if you allow this, I can understand that those "\r" at the end of
> every line can be annoying.
I think the right thing to do is:
* If the repository data is _supposed_ to have CRLF endings (e.g. check
with core.crlf or something), strip \r and do not show them.
* Otherwise, i.e. if the repository data is supposed _not_ to have CRLF
endings, do show these '\r'. Annoyance here is a *feature* to remind
the viewer that the contents needs _fixing_.
* No other switches.
^ 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-27 23:21 UTC (permalink / raw)
To: Mark Jason Dominus; +Cc: git
In-Reply-To: <2443.1327701165@plover.com>
Mark Jason Dominus <mjd@plover.com> writes:
> This should work, but doesn't:
>
> % git branch
> * master
> % git branch --edit-description blarf
> [Edit description and exit editor normally]
> % cat .git/BRANCH_DESCRIPTION
> I like blarf
> # Please edit the description for the branch
> # blarf
> # Lines starting with '#' will be stripped.
> % git branch -a
> * master
>
> 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.
^ permalink raw reply
* Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-27 23:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m31uqkepx6.fsf@localhost.localdomain>
* Jakub Narebski <jnareb@gmail.com> [120127 23:33]:
> > 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.
>
> Could you explain why you want this feature, and why for example
> project search just does not cut it?
The project list takes often a very long time and searching in that list
takes the same time (and would also show projects not starting with the
text).
I'd for example like to be able to place a link to all projects shown
at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get
a not having to wait for description information being extracted for all
the other projects.
> > It uses the infrastructure already there for 'forks' (which also filters
> > projects but needs a project called like the filter directory to work).
>
> It is not entirely clear for me that what you mean here is (I think)
> that using
>
> git_get_projects_list($project_filter);
>
> just works thanks to forks filtering infrastructure.
Yes, it uses the optional git_get_projects_list argument which is
currently only used by action=forks.
> > This feature is disabled if strict_export is used and there is no
> > projects_list to avoid showing more than intended.
> > Without strict_export enabled this change should not show any projects
> > one could not get details from anyway. So if the validate_pathname
> > checks are not sufficient this would at most make it easier to get a
> > list of viewable content.
>
> I don't wuite understand this reasoning. Why project filtering is
> disabled with strict_export? It should just filter, regardless if
> project are from scanning $project_filter subdirectory, or filtering
> out project names from $projects_list file that do not begin with
> $project_filter prefix.
strict_export is a security switch to make sure that no unintended
information is exported. Without a project_list all that strict_export
ensures is that there is no way to escape the project_root by giving
some path to a project outside that is not catched by the simple check
against /./ and /../. As the new code would allow a way around this
check, I think the sane thing is to simply disable this new feature in
case of this paranoid check being activated. (And reporting an error
message if it is used).
> > ---
> > As most parameters are not documented in documentation/gitweb.txt,
> > I did not add documentation for this one either.
>
> On the other hand IIRC getting list of projects is quite well
> documented in gitweb manpage (or at least it should be).
In Documentation/gitweb.txt there is only a list of possible actions, but no
documentation of any of the other arguments. (none of the order argument
to project_list nor anything else). If actions like blob_plain do list
essential arguments like f= then giving this option special rooms does
not seem to fit very well with the rest.
>
> [...]
> > @@ -3962,6 +3973,13 @@ sub git_footer_html {
> > -class => $feed_class}, $format)."\n";
> > }
> >
> > + } elsif (defined $project_filter) {
> > + 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",
> > + project_filter => $project_filter),
> > + -class => $feed_class}, "TXT") . "\n";
> > } else {
> > print $cgi->a({-href => href(project=>undef, action=>"opml"),
> > -class => $feed_class}, "OPML") . " ";
>
> I wonder if perhaps a better solution wouldn't be to use -replay=>1 in
> generating projects list in other formats (OPML and TXT).
Wouldn't that also replay options like "order"?
Bernhard R. Link
^ permalink raw reply
* Bisecting through the middle of a big merge?
From: walt @ 2012-01-28 0:03 UTC (permalink / raw)
To: git
My problem is that I lack a good mental model of what git does
when it commits a big merge, and so I get lost when I try to
bisect back through a merge. (I'm a tester, not a developer.)
This specific recent example is causing me problems:
Merge: b3c9dd1 85a0f7b
Author: Linus Torvalds
Date: Sun Jan 15 12:48:41 2012 -0800
Merge branch 'for-3.3/drivers' of git://git.kernel.dk/linux-block
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?
Thanks for any clues.
^ permalink raw reply
* [PATCH/RFC] grep: Add the option '--exclude'
From: Albert Yale @ 2012-01-28 2:06 UTC (permalink / raw)
To: git; +Cc: pclouds, rene.scharfe, tfransosi, Albert Yale
grep: Add the option '--exclude'
Signed-off-by: Albert Yale <surfingalbert@gmail.com>
---
This is a work-in-progress. It's functional,
but it hasn't been thoroughly tested.
I'd like some feedback. Particularly for
init_pathspec_string_list() in dir.c.
Thank you,
Albert Yale
Documentation/git-grep.txt | 7 ++++++
builtin/grep.c | 50 ++++++++++++++++++++++++++++++++++++-------
cache.h | 1 +
dir.c | 32 ++++++++++++++++++++++++++++
4 files changed, 82 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 6a8b1e3..8cbb161 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -22,6 +22,7 @@ SYNOPSIS
[--color[=<when>] | --no-color]
[-A <post-context>] [-B <pre-context>] [-C <context>]
[-f <file>] [-e] <pattern>
+ [-x <pattern>|--exclude=<pattern>]
[--and|--or|--not|(|)|-e <pattern>...]
[ [--exclude-standard] [--cached | --no-index | --untracked] | <tree>...]
[--] [<pathspec>...]
@@ -124,6 +125,12 @@ OPTIONS
Use fixed strings for patterns (don't interpret pattern
as a regex).
+-x <pattern>::
+--exclude=<pattern>::
+ In addition to those found in .gitignore (per directory) and
+ $GIT_DIR/info/exclude, also consider these patterns to be in the
+ set of the ignore rules in effect.
+
-n::
--line-number::
Prefix the line number to matching lines.
diff --git a/builtin/grep.c b/builtin/grep.c
index 9ce064a..106810f 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -518,7 +518,8 @@ static void run_pager(struct grep_opt *opt, const char *prefix)
free(argv);
}
-static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int cached)
+static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec,
+ int cached, const struct pathspec *exclude_pathspec)
{
int hit = 0;
int nr;
@@ -530,6 +531,9 @@ static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int
continue;
if (!match_pathspec_depth(pathspec, ce->name, ce_namelen(ce), 0, NULL))
continue;
+ if (exclude_pathspec->nr &&
+ match_pathspec_depth(exclude_pathspec, ce->name, ce_namelen(ce), 0, NULL))
+ continue;
/*
* If CE_VALID is on, we assume worktree file and its cache entry
* are identical, even if worktree file has been modified, so use
@@ -639,16 +643,23 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,
}
static int grep_objects(struct grep_opt *opt, const struct pathspec *pathspec,
- const struct object_array *list)
+ const struct object_array *list, const struct pathspec *exclude_pathspec)
{
unsigned int i;
int hit = 0;
const unsigned int nr = list->nr;
for (i = 0; i < nr; i++) {
+ const char *name = list->objects[i].name;
+ int namelen = strlen(name);
struct object *real_obj;
real_obj = deref_tag(list->objects[i].item, NULL, 0);
- if (grep_object(opt, pathspec, real_obj, list->objects[i].name)) {
+
+ if (exclude_pathspec->nr &&
+ match_pathspec_depth(exclude_pathspec, name, namelen, 0, NULL))
+ continue;
+
+ if (grep_object(opt, pathspec, real_obj, name)) {
hit = 1;
if (opt->status_only)
break;
@@ -658,7 +669,7 @@ static int grep_objects(struct grep_opt *opt, const struct pathspec *pathspec,
}
static int grep_directory(struct grep_opt *opt, const struct pathspec *pathspec,
- int exc_std)
+ int exc_std, struct string_list *exclude_list)
{
struct dir_struct dir;
int i, hit = 0;
@@ -667,6 +678,10 @@ static int grep_directory(struct grep_opt *opt, const struct pathspec *pathspec,
if (exc_std)
setup_standard_excludes(&dir);
+ for (i = 0; i < exclude_list->nr; i++)
+ add_exclude(exclude_list->items[i].string, "", 0,
+ &dir.exclude_list[EXC_CMDL]);
+
fill_directory(&dir, pathspec->raw);
for (i = 0; i < dir.nr; i++) {
const char *name = dir.entries[i]->name;
@@ -764,6 +779,14 @@ static int pattern_callback(const struct option *opt, const char *arg,
return 0;
}
+static int exclude_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ struct string_list *exclude_list = opt->value;
+ string_list_append(exclude_list, arg);
+ return 0;
+}
+
static int help_callback(const struct option *opt, const char *arg, int unset)
{
return -1;
@@ -780,6 +803,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
struct object_array list = OBJECT_ARRAY_INIT;
const char **paths = NULL;
struct pathspec pathspec;
+ struct pathspec exclude_pathspec;
struct string_list path_list = STRING_LIST_INIT_NODUP;
int i;
int dummy;
@@ -792,7 +816,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
pattern_type_pcre,
};
int pattern_type = pattern_type_unspecified;
-
+ struct string_list exclude_list = STRING_LIST_INIT_NODUP;
struct option options[] = {
OPT_BOOLEAN(0, "cached", &cached,
"search in index instead of in the work tree"),
@@ -872,6 +896,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
"read patterns from file", file_callback),
{ OPTION_CALLBACK, 'e', NULL, &opt, "pattern",
"match <pattern>", PARSE_OPT_NONEG, pattern_callback },
+ { OPTION_CALLBACK, 'x', "exclude", &exclude_list, "pattern",
+ "add <pattern> to ignore rules", PARSE_OPT_NONEG, exclude_cb },
{ OPTION_CALLBACK, 0, "and", &opt, NULL,
"combine patterns specified with -e",
PARSE_OPT_NOARG | PARSE_OPT_NONEG, and_callback },
@@ -1053,6 +1079,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
pathspec.max_depth = opt.max_depth;
pathspec.recursive = 1;
+ init_pathspec_string_list(&exclude_pathspec, &exclude_list);
+ exclude_pathspec.max_depth = opt.max_depth;
+ exclude_pathspec.recursive = 1;
+
if (show_in_pager && (cached || list.nr))
die(_("--open-files-in-pager only works on the worktree"));
@@ -1083,18 +1113,19 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
int use_exclude = (opt_exclude < 0) ? use_index : !!opt_exclude;
if (list.nr)
die(_("--no-index or --untracked cannot be used with revs."));
- hit = grep_directory(&opt, &pathspec, use_exclude);
+ hit = grep_directory(&opt, &pathspec, use_exclude, &exclude_list);
} else if (0 <= opt_exclude) {
die(_("--[no-]exclude-standard cannot be used for tracked contents."));
} else if (!list.nr) {
if (!cached)
setup_work_tree();
- hit = grep_cache(&opt, &pathspec, cached);
+ hit = grep_cache(&opt, &pathspec, cached, &exclude_pathspec);
} else {
if (cached)
die(_("both --cached and trees are given."));
- hit = grep_objects(&opt, &pathspec, &list);
+
+ hit = grep_objects(&opt, &pathspec, &list, &exclude_pathspec);
}
if (use_threads)
@@ -1102,5 +1133,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (hit && show_in_pager)
run_pager(&opt, prefix);
free_grep_patterns(&opt);
+ free_pathspec(&pathspec);
+ free_pathspec(&exclude_pathspec);
+ string_list_clear(&exclude_list, 0);
return !hit;
}
diff --git a/cache.h b/cache.h
index 10afd71..5c34ccb 100644
--- a/cache.h
+++ b/cache.h
@@ -536,6 +536,7 @@ struct pathspec {
};
extern int init_pathspec(struct pathspec *, const char **);
+extern int init_pathspec_string_list(struct pathspec *, struct string_list *);
extern void free_pathspec(struct pathspec *);
extern int ce_path_match(const struct cache_entry *ce, const struct pathspec *pathspec);
diff --git a/dir.c b/dir.c
index 0a78d00..65749cc 100644
--- a/dir.c
+++ b/dir.c
@@ -9,6 +9,8 @@
#include "dir.h"
#include "refs.h"
+#include "string-list.h"
+
struct path_simplify {
int len;
const char *path;
@@ -1259,6 +1261,36 @@ static int pathspec_item_cmp(const void *a_, const void *b_)
return strcmp(a->match, b->match);
}
+int init_pathspec_string_list(struct pathspec *pathspec, struct string_list *path_list)
+{
+ int i;
+
+ memset(pathspec, 0, sizeof(*pathspec));
+ if (!path_list)
+ return 0;
+ pathspec->raw = 0; /* THIS IS PROBABLY BAD!!! */
+ pathspec->nr = path_list->nr;
+ if (!pathspec->nr)
+ return 0;
+
+ pathspec->items = xmalloc(sizeof(struct pathspec_item)*pathspec->nr);
+ for (i = 0; i < pathspec->nr; i++) {
+ struct pathspec_item *item = pathspec->items+i;
+ const char *path = path_list->items[i].string;
+
+ item->match = path;
+ item->len = strlen(path);
+ item->use_wildcard = !no_wildcard(path);
+ if (item->use_wildcard)
+ pathspec->has_wildcard = 1;
+ }
+
+ qsort(pathspec->items, pathspec->nr,
+ sizeof(struct pathspec_item), pathspec_item_cmp);
+
+ return 0;
+}
+
int init_pathspec(struct pathspec *pathspec, const char **paths)
{
const char **p = paths;
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH/RFC] grep: Add the option '--exclude'
From: Albert Yale @ 2012-01-28 2:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: rene.scharfe, tfransosi, git, pclouds
In-Reply-To: <CAPc5daW+pcO-HLoo9THLgt4Ow2BHZ-fWgXL=zPgyunvt1mf9ZQ@mail.gmail.com>
I think you're correct. That would be a better way to implement this.
I'll look into it this weekend.
Albert Yale
On Fri, Jan 27, 2012 at 9:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I'd prefer to see this done not by introducing a separate pathspec, but
> instead by adding exclusion-related fields to struct pathspec. That way, the
> existing callsites to match_pathspec() do not have to change, and only the
> program start-up needs to learn to stuff these negative pathspecs, no?
>
> On Jan 27, 2012 6:06 PM, "Albert Yale" <surfingalbert@gmail.com> wrote:
>>
>> grep: Add the option '--exclude'
>>
>> Signed-off-by: Albert Yale <surfingalbert@gmail.com>
>> ---
>> This is a work-in-progress. It's functional,
>> but it hasn't been thoroughly tested.
>>
>> I'd like some feedback. Particularly for
>> init_pathspec_string_list() in dir.c.
>>
>> Thank you,
>>
>> Albert Yale
>>
>> Documentation/git-grep.txt | 7 ++++++
>> builtin/grep.c | 50
>> ++++++++++++++++++++++++++++++++++++-------
>> cache.h | 1 +
>> dir.c | 32 ++++++++++++++++++++++++++++
>> 4 files changed, 82 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
>> index 6a8b1e3..8cbb161 100644
>> --- a/Documentation/git-grep.txt
>> +++ b/Documentation/git-grep.txt
>> @@ -22,6 +22,7 @@ SYNOPSIS
>> [--color[=<when>] | --no-color]
>> [-A <post-context>] [-B <pre-context>] [-C <context>]
>> [-f <file>] [-e] <pattern>
>> + [-x <pattern>|--exclude=<pattern>]
>> [--and|--or|--not|(|)|-e <pattern>...]
>> [ [--exclude-standard] [--cached | --no-index | --untracked] |
>> <tree>...]
>> [--] [<pathspec>...]
>> @@ -124,6 +125,12 @@ OPTIONS
>> Use fixed strings for patterns (don't interpret pattern
>> as a regex).
>>
>> +-x <pattern>::
>> +--exclude=<pattern>::
>> + In addition to those found in .gitignore (per directory) and
>> + $GIT_DIR/info/exclude, also consider these patterns to be in the
>> + set of the ignore rules in effect.
>> +
>> -n::
>> --line-number::
>> Prefix the line number to matching lines.
>> diff --git a/builtin/grep.c b/builtin/grep.c
>> index 9ce064a..106810f 100644
>> --- a/builtin/grep.c
>> +++ b/builtin/grep.c
>> @@ -518,7 +518,8 @@ static void run_pager(struct grep_opt *opt, const char
>> *prefix)
>> free(argv);
>> }
>>
>> -static int grep_cache(struct grep_opt *opt, const struct pathspec
>> *pathspec, int cached)
>> +static int grep_cache(struct grep_opt *opt, const struct pathspec
>> *pathspec,
>> + int cached, const struct pathspec
>> *exclude_pathspec)
>> {
>> int hit = 0;
>> int nr;
>> @@ -530,6 +531,9 @@ static int grep_cache(struct grep_opt *opt, const
>> struct pathspec *pathspec, int
>> continue;
>> if (!match_pathspec_depth(pathspec, ce->name,
>> ce_namelen(ce), 0, NULL))
>> continue;
>> + if (exclude_pathspec->nr &&
>> + match_pathspec_depth(exclude_pathspec, ce->name,
>> ce_namelen(ce), 0, NULL))
>> + continue;
>> /*
>> * If CE_VALID is on, we assume worktree file and its cache
>> entry
>> * are identical, even if worktree file has been modified,
>> so use
>> @@ -639,16 +643,23 @@ static int grep_object(struct grep_opt *opt, const
>> struct pathspec *pathspec,
>> }
>>
>> static int grep_objects(struct grep_opt *opt, const struct pathspec
>> *pathspec,
>> - const struct object_array *list)
>> + const struct object_array *list, const struct
>> pathspec *exclude_pathspec)
>> {
>> unsigned int i;
>> int hit = 0;
>> const unsigned int nr = list->nr;
>>
>> for (i = 0; i < nr; i++) {
>> + const char *name = list->objects[i].name;
>> + int namelen = strlen(name);
>> struct object *real_obj;
>> real_obj = deref_tag(list->objects[i].item, NULL, 0);
>> - if (grep_object(opt, pathspec, real_obj,
>> list->objects[i].name)) {
>> +
>> + if (exclude_pathspec->nr &&
>> + match_pathspec_depth(exclude_pathspec, name,
>> namelen, 0, NULL))
>> + continue;
>> +
>> + if (grep_object(opt, pathspec, real_obj, name)) {
>> hit = 1;
>> if (opt->status_only)
>> break;
>> @@ -658,7 +669,7 @@ static int grep_objects(struct grep_opt *opt, const
>> struct pathspec *pathspec,
>> }
>>
>> static int grep_directory(struct grep_opt *opt, const struct pathspec
>> *pathspec,
>> - int exc_std)
>> + int exc_std, struct string_list *exclude_list)
>> {
>> struct dir_struct dir;
>> int i, hit = 0;
>> @@ -667,6 +678,10 @@ static int grep_directory(struct grep_opt *opt, const
>> struct pathspec *pathspec,
>> if (exc_std)
>> setup_standard_excludes(&dir);
>>
>> + for (i = 0; i < exclude_list->nr; i++)
>> + add_exclude(exclude_list->items[i].string, "", 0,
>> + &dir.exclude_list[EXC_CMDL]);
>> +
>> fill_directory(&dir, pathspec->raw);
>> for (i = 0; i < dir.nr; i++) {
>> const char *name = dir.entries[i]->name;
>> @@ -764,6 +779,14 @@ static int pattern_callback(const struct option *opt,
>> const char *arg,
>> return 0;
>> }
>>
>> +static int exclude_cb(const struct option *opt, const char *arg,
>> + int unset)
>> +{
>> + struct string_list *exclude_list = opt->value;
>> + string_list_append(exclude_list, arg);
>> + return 0;
>> +}
>> +
>> static int help_callback(const struct option *opt, const char *arg, int
>> unset)
>> {
>> return -1;
>> @@ -780,6 +803,7 @@ int cmd_grep(int argc, const char **argv, const char
>> *prefix)
>> struct object_array list = OBJECT_ARRAY_INIT;
>> const char **paths = NULL;
>> struct pathspec pathspec;
>> + struct pathspec exclude_pathspec;
>> struct string_list path_list = STRING_LIST_INIT_NODUP;
>> int i;
>> int dummy;
>> @@ -792,7 +816,7 @@ int cmd_grep(int argc, const char **argv, const char
>> *prefix)
>> pattern_type_pcre,
>> };
>> int pattern_type = pattern_type_unspecified;
>> -
>> + struct string_list exclude_list = STRING_LIST_INIT_NODUP;
>> struct option options[] = {
>> OPT_BOOLEAN(0, "cached", &cached,
>> "search in index instead of in the work tree"),
>> @@ -872,6 +896,8 @@ int cmd_grep(int argc, const char **argv, const char
>> *prefix)
>> "read patterns from file", file_callback),
>> { OPTION_CALLBACK, 'e', NULL, &opt, "pattern",
>> "match <pattern>", PARSE_OPT_NONEG,
>> pattern_callback },
>> + { OPTION_CALLBACK, 'x', "exclude", &exclude_list,
>> "pattern",
>> + "add <pattern> to ignore rules", PARSE_OPT_NONEG,
>> exclude_cb },
>> { OPTION_CALLBACK, 0, "and", &opt, NULL,
>> "combine patterns specified with -e",
>> PARSE_OPT_NOARG | PARSE_OPT_NONEG, and_callback },
>> @@ -1053,6 +1079,10 @@ int cmd_grep(int argc, const char **argv, const
>> char *prefix)
>> pathspec.max_depth = opt.max_depth;
>> pathspec.recursive = 1;
>>
>> + init_pathspec_string_list(&exclude_pathspec, &exclude_list);
>> + exclude_pathspec.max_depth = opt.max_depth;
>> + exclude_pathspec.recursive = 1;
>> +
>> if (show_in_pager && (cached || list.nr))
>> die(_("--open-files-in-pager only works on the worktree"));
>>
>> @@ -1083,18 +1113,19 @@ int cmd_grep(int argc, const char **argv, const
>> char *prefix)
>> int use_exclude = (opt_exclude < 0) ? use_index :
>> !!opt_exclude;
>> if (list.nr)
>> die(_("--no-index or --untracked cannot be used
>> with revs."));
>> - hit = grep_directory(&opt, &pathspec, use_exclude);
>> + hit = grep_directory(&opt, &pathspec, use_exclude,
>> &exclude_list);
>> } else if (0 <= opt_exclude) {
>> die(_("--[no-]exclude-standard cannot be used for tracked
>> contents."));
>> } else if (!list.nr) {
>> if (!cached)
>> setup_work_tree();
>>
>> - hit = grep_cache(&opt, &pathspec, cached);
>> + hit = grep_cache(&opt, &pathspec, cached,
>> &exclude_pathspec);
>> } else {
>> if (cached)
>> die(_("both --cached and trees are given."));
>> - hit = grep_objects(&opt, &pathspec, &list);
>> +
>> + hit = grep_objects(&opt, &pathspec, &list,
>> &exclude_pathspec);
>> }
>>
>> if (use_threads)
>> @@ -1102,5 +1133,8 @@ int cmd_grep(int argc, const char **argv, const char
>> *prefix)
>> if (hit && show_in_pager)
>> run_pager(&opt, prefix);
>> free_grep_patterns(&opt);
>> + free_pathspec(&pathspec);
>> + free_pathspec(&exclude_pathspec);
>> + string_list_clear(&exclude_list, 0);
>> return !hit;
>> }
>> diff --git a/cache.h b/cache.h
>> index 10afd71..5c34ccb 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -536,6 +536,7 @@ struct pathspec {
>> };
>>
>> extern int init_pathspec(struct pathspec *, const char **);
>> +extern int init_pathspec_string_list(struct pathspec *, struct
>> string_list *);
>> extern void free_pathspec(struct pathspec *);
>> extern int ce_path_match(const struct cache_entry *ce, const struct
>> pathspec *pathspec);
>>
>> diff --git a/dir.c b/dir.c
>> index 0a78d00..65749cc 100644
>> --- a/dir.c
>> +++ b/dir.c
>> @@ -9,6 +9,8 @@
>> #include "dir.h"
>> #include "refs.h"
>>
>> +#include "string-list.h"
>> +
>> struct path_simplify {
>> int len;
>> const char *path;
>> @@ -1259,6 +1261,36 @@ static int pathspec_item_cmp(const void *a_, const
>> void *b_)
>> return strcmp(a->match, b->match);
>> }
>>
>> +int init_pathspec_string_list(struct pathspec *pathspec, struct
>> string_list *path_list)
>> +{
>> + int i;
>> +
>> + memset(pathspec, 0, sizeof(*pathspec));
>> + if (!path_list)
>> + return 0;
>> + pathspec->raw = 0; /* THIS IS PROBABLY BAD!!! */
>> + pathspec->nr = path_list->nr;
>> + if (!pathspec->nr)
>> + return 0;
>> +
>> + pathspec->items = xmalloc(sizeof(struct
>> pathspec_item)*pathspec->nr);
>> + for (i = 0; i < pathspec->nr; i++) {
>> + struct pathspec_item *item = pathspec->items+i;
>> + const char *path = path_list->items[i].string;
>> +
>> + item->match = path;
>> + item->len = strlen(path);
>> + item->use_wildcard = !no_wildcard(path);
>> + if (item->use_wildcard)
>> + pathspec->has_wildcard = 1;
>> + }
>> +
>> + qsort(pathspec->items, pathspec->nr,
>> + sizeof(struct pathspec_item), pathspec_item_cmp);
>> +
>> + return 0;
>> +}
>> +
>> int init_pathspec(struct pathspec *pathspec, const char **paths)
>> {
>> const char **p = paths;
>> --
>> 1.7.8.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PULL] svn-fe updates for master or next
From: Junio C Hamano @ 2012-01-28 4:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, David Barr, Scott Chacon, Brian Gernhardt, david,
Ramkumar Ramachandra, git, Dmitry Ivankov
In-Reply-To: <7v39b10z3k.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Junio, please pull
>>
>> git://repo.or.cz/git/jrn.git svn-fe
>>
>> to get the following changes since commit ec014eac0e9e6f30cbbca616090fa2ecf74797e7:
>>
>> Git 1.7.5 (2011-04-23 23:36:32 -0700)
>>
>> up to c5bcbcdcfa1e2a1977497cb3a342c0365c8d78d6:
>>
>> vcs-svn: reset first_commit_done in fast_export_init (2011-06-23 10:04:36 -0500)
>>
>> I'd even be okay with pulling this for v1.7.9, but application for the
>> next release would also be fine with me. It simplifies svn-fe a great
>> deal and fulfills a longstanding wish: support for dumps with deltas
>> in them. The cost is that commandline usage of the svn-fe tool
>> becomes a little more complicated since it no longer keeps state
>> itself but instead reads blobs back from fast-import in order to copy
>> them between revisions and apply deltas to them.
>
> Thanks, but will pull after 1.7.9 that was scheduled to happen today.
There were some conflicts, but I think I resolved correctly. Please
double-check what appears in 'pu'.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #06; Fri, 27)
From: Junio C Hamano @ 2012-01-28 5:37 UTC (permalink / raw)
To: Matthieu Moy, Felipe Contreras; +Cc: git
In-Reply-To: <7v7h0czur2.fsf@alter.siamese.dyndns.org>
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?
^ 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-28 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Jason Dominus, git
In-Reply-To: <7vr4ykybnl.fsf@alter.siamese.dyndns.org>
On 01/28/2012 12:21 AM, Junio C Hamano wrote:
> Mark Jason Dominus <mjd@plover.com> writes:
>
>> This should work, but doesn't:
>>
>> % git branch
>> * master
>> % git branch --edit-description blarf
>> [Edit description and exit editor normally]
>> % cat .git/BRANCH_DESCRIPTION
>> I like blarf
>> # Please edit the description for the branch
>> # blarf
>> # Lines starting with '#' will be stripped.
>> % git branch -a
>> * master
>>
>> 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?
Shouldn't it also resolve ambiguous reference names?
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-28 7:27 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, Mark Jason Dominus, git
In-Reply-To: <4F2399B6.8020507@alum.mit.edu>
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.
> 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?
^ permalink raw reply
* Re: Bisecting through the middle of a big merge?
From: Andreas Schwab @ 2012-01-28 8:55 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <jfve09$ih5$1@dough.gmane.org>
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.
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: [PATCH] gitweb: add pf= to limit project list to a subdirectory
From: Jakub Narebski @ 2012-01-28 14:53 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20120127235330.GA2718@server.brlink.eu>
On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> * Jakub Narebski <jnareb@gmail.com> [120127 23:33]:
> > > 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.
> >
> > Could you explain why you want this feature, and why for example
> > project search just does not cut it?
>
> The project list takes often a very long time and searching in that list
> takes the same time (and would also show projects not starting with the
> text).
There are at least two ways to speed up getting projects list page.
First is to limit number of projects shown, like e.g. http://repo.or.cz
which shows only search form and tag cloud, but no projects, or at least
paginate (divide into pages of e.g. 100 projects) list of projects.
I have some patches improving projects list and searching projects,
including slight speedup to search result generation and project list
pagination in my StGit stack. I'll clean them up and (re)send them to
git mailing list for discussion.
Second solution would be to finally add caching support to gitweb,
either on the level of caching git command output like Lea Wiemann
work from GSoC2008, or caching intermediate Perl data structures
used by gitweb like in old patches by Petr 'Pasky' Baudis (though only
for projects list page), or caching of final HTML output like in
http://git.kernel.org fork of gitweb.
There is some work in progress that I have in gitweb/cache branch and
in gitweb/cache-kernel* branches in my repository (either on
http://github.com/jnareb/git or http://repo.or.cz/w/git/jnareb-git.git).
The problem with cleaning it up to the form suitable for inclusion is
that it is quite a bit of code, and it very much requires splitting gitweb.
Splitting gitweb in turn requires reworking of current hacky "longjump"
based (non-local goto) error handling into exception based error handling.
That in turn would be best handled using non-core CPAN modules, namely
Try::Tiny and HTTP::Exception or at least Exception::Class. For that
we need I think a way of bundling requirements with gitweb in inc/
a la Module::Install.
Ehhh...
> I'd for example like to be able to place a link to all projects shown
> at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get
> a not having to wait for description information being extracted for all
> the other projects.
I would prefer instead of introducing yet another arbitrary parameter
extend project searching, so that you can specify that you want to
search project names only (IIRC I have a patch for that, or beginnings
of one, in my StGit stack), and use prefix search by the way of regexp
search.
So
pf=mirrorer/
would be
s=^mirrorer/;sr=1;st=project_name
> > > It uses the infrastructure already there for 'forks' (which also filters
> > > projects but needs a project called like the filter directory to work).
> >
> > It is not entirely clear for me that what you mean here is (I think)
> > that using
> >
> > git_get_projects_list($project_filter);
> >
> > just works thanks to forks filtering infrastructure.
>
> Yes, it uses the optional git_get_projects_list argument which is
> currently only used by action=forks.
This needs to be stated more clearly in the commit message.
> > > This feature is disabled if strict_export is used and there is no
> > > projects_list to avoid showing more than intended.
> > > Without strict_export enabled this change should not show any projects
> > > one could not get details from anyway. So if the validate_pathname
> > > checks are not sufficient this would at most make it easier to get a
> > > list of viewable content.
> >
> > I don't quite understand this reasoning. Why project filtering is
> > disabled with strict_export? It should just filter, regardless if
> > project are from scanning $project_filter subdirectory, or filtering
> > out project names from $projects_list file that do not begin with
> > $project_filter prefix.
>
> strict_export is a security switch to make sure that no unintended
> information is exported. Without a project_list all that strict_export
> ensures is that there is no way to escape the project_root by giving
> some path to a project outside that is not catched by the simple check
> against /./ and /../. As the new code would allow a way around this
> check, I think the sane thing is to simply disable this new feature in
> case of this paranoid check being activated. (And reporting an error
> message if it is used).
Hmmm... I think this new feature can be made compatible with strict export...
if it is not replaced by search extension, as I have proposed above.
> > > ---
> > > As most parameters are not documented in documentation/gitweb.txt,
> > > I did not add documentation for this one either.
> >
> > On the other hand IIRC getting list of projects is quite well
> > documented in gitweb manpage (or at least it should be).
>
> In Documentation/gitweb.txt there is only a list of possible actions, but no
> documentation of any of the other arguments. (none of the order argument
> to project_list nor anything else). If actions like blob_plain do list
> essential arguments like f= then giving this option special rooms does
> not seem to fit very well with the rest.
I was thinking about "Controlling access to git repositories" section in
Documentation/gitweb.txt, but after closer examination I think it wouldn't
fit there.
> >
> > [...]
> > > @@ -3962,6 +3973,13 @@ sub git_footer_html {
> > > -class => $feed_class}, $format)."\n";
> > > }
> > >
> > > + } elsif (defined $project_filter) {
> > > + 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",
> > > + project_filter => $project_filter),
> > > + -class => $feed_class}, "TXT") . "\n";
> > > } else {
> > > print $cgi->a({-href => href(project=>undef, action=>"opml"),
> > > -class => $feed_class}, "OPML") . " ";
> >
> > I wonder if perhaps a better solution wouldn't be to use -replay=>1 in
> > generating projects list in other formats (OPML and TXT).
>
> Wouldn't that also replay options like "order"?
Right. My mistake.
Anyway
+ 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",
+ project_filter => $project_filter),
+ -class => $feed_class}, "TXT") . "\n";
would do the right thing because of the way href() works when passed
key-value pair with undefined key.
In other words there is no need for conditional; just add
project_filter => $project_filter
and href() would do the right thing.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-28 15:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201201281553.29387.jnareb@gmail.com>
* Jakub Narebski <jnareb@gmail.com> [120128 15:53]:
> On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> > The project list takes often a very long time and searching in that list
> > takes the same time (and would also show projects not starting with the
> > text).
>
> There are at least two ways to speed up getting projects list page.
There are other ways, but they are both limited and quite backward:
Instead of showing me the information I want (what is in that
directory), I guess to search in the larger pool of information needing
all sort of half-working tricks causing all kinds of other problems
working around the issue that much more information never used must be
collected first.
Subversion's ViewVC for example only shows what is in some directory
directory and available subdirectories. (That of course has the
disadvantage to make it harder to find a project one does not know
the subdirectory it is in, but why shouldn't gitweb offer the best of
both worlds?)
> First is to limit number of projects shown, like e.g. http://repo.or.cz
> which shows only search form and tag cloud, but no projects, or at least
> paginate (divide into pages of e.g. 100 projects) list of projects.
But a page showing all projects (as long as it is possible) is something
I'd quite miss if it is gone. What I want is some way to have that and
to also be able to look at some subset interesting to me directly in an
effective way.
> Second solution would be to finally add caching support to gitweb,
But caching also means new projects or changes will take some time to
show up. And again it would not be a solution to by original problem.
(Showing effectively what is in some directory).
> > I'd for example like to be able to place a link to all projects shown
> > at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get
> > a not having to wait for description information being extracted for all
> > the other projects.
>
> I would prefer instead of introducing yet another arbitrary parameter
> extend project searching, so that you can specify that you want to
> search project names only (IIRC I have a patch for that, or beginnings
> of one, in my StGit stack), and use prefix search by the way of regexp
> search.
> So
>
> pf=mirrorer/
>
> would be
>
> s=^mirrorer/;sr=1;st=project_name
That might be a workaround, but still need to look at quite some amount
of unecessary data (i.e. it would need to run at least as long as a
http://anonscm.debian.org/gitweb/?a=project_index would not to load,
wouldn't it?)
Bernhard R. Link
^ permalink raw reply
* Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory
From: Jakub Narebski @ 2012-01-28 16:03 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20120128153750.GB3397@server.brlink.eu>
On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> * Jakub Narebski <jnareb@gmail.com> [120128 15:53]:
> > On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> > > The project list takes often a very long time and searching in that list
> > > takes the same time (and would also show projects not starting with the
> > > text).
> >
> > There are at least two ways to speed up getting projects list page.
>
> There are other ways, but they are both limited and quite backward:
> Instead of showing me the information I want (what is in that
> directory), I guess to search in the larger pool of information needing
> all sort of half-working tricks causing all kinds of other problems
> working around the issue that much more information never used must be
> collected first.
>
> Subversion's ViewVC for example only shows what is in some directory
> directory and available subdirectories. (That of course has the
> disadvantage to make it harder to find a project one does not know
> the subdirectory it is in, but why shouldn't gitweb offer the best of
> both worlds?)
Well, ViewVC follows Subversion concepts... including broken-by-design
branching by copying ;-)
Anyway, I think I am getting convinced that supporting project filtering
by subdirectory, in a way similar to existing support for forks (and reusing
it implementation) could be a good idea.
The one serious disadvantage of "pf=" is that it is not solution for a
faster gitweb homepage. It works _only_ when you have pf=subdirectory/
link.
And I'd rather it worked with strict export, correctly and safely,
if "pf=" is to be included in gitweb.
> > First is to limit number of projects shown, like e.g. http://repo.or.cz
> > which shows only search form and tag cloud, but no projects, or at least
> > paginate (divide into pages of e.g. 100 projects) list of projects.
>
> But a page showing all projects (as long as it is possible) is something
> I'd quite miss if it is gone. What I want is some way to have that and
> to also be able to look at some subset interesting to me directly in an
> effective way.
The http://repo.or.cz homepage has 'Show all projects' link, but it is
at explicit request.
> > Second solution would be to finally add caching support to gitweb,
>
> But caching also means new projects or changes will take some time to
> show up. And again it would not be a solution to by original problem.
> (Showing effectively what is in some directory).
Well, it would solve "The project list takes often a very long time"
part of your problem. Though very large list of projects can cause
performance problems rendering on client side, I guess...
> > > I'd for example like to be able to place a link to all projects shown
> > > at http://anonscm.debian.org/gitweb/ which are below mirrorer/ and get
> > > a not having to wait for description information being extracted for all
> > > the other projects.
> >
> > I would prefer instead of introducing yet another arbitrary parameter
> > extend project searching, so that you can specify that you want to
> > search project names only (IIRC I have a patch for that, or beginnings
> > of one, in my StGit stack), and use prefix search by the way of regexp
> > search.
> >
> > So
> >
> > pf=mirrorer/
> >
> > would be
> >
> > s=^mirrorer/;sr=1;st=project_name
>
> That might be a workaround, but still need to look at quite some amount
> of unecessary data (i.e. it would need to run at least as long as a
> http://anonscm.debian.org/gitweb/?a=project_index would not to load,
> wouldn't it?)
Not with 'gitweb: Faster project search' from this series of commits
# gitweb: Allow underscore in $searchtype ('st')
# gitweb: Improve projects search form
# gitweb: Option for filling only specified info in fill_project_list_info
# gitweb: Faster project search
# gitweb: Highlight matched part of project name when searching projects
# gitweb: Highlight matched part of project description when searching projects
which does not search for description nor check for latest changes in
repository for repositories it doesn't show.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2 1/2] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-28 16:56 UTC (permalink / raw)
To: git
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.
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 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.
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>
---
Changed since version 1:
- improve description
- simplify as suggested by Jakub Narebski
- support the strict_exports + no projects_list case
gitweb/gitweb.perl | 29 ++++++++++++++++++++++-------
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index abb5a79..a114bd4 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 || 0;
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 };
@@ -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";
}
print "</div>\n"; # class="page_footer"
@@ -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");
}
@@ -6018,7 +6033,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 +7870,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 v2 2/2] gitweb: place links to parent directories in page header
From: Bernhard R. Link @ 2012-01-28 16:57 UTC (permalink / raw)
To: git
In-Reply-To: <20120128165606.GA6770@server.brlink.eu>
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.
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}) {
@@ -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)) . " / ";
+ }
}
}
--
1.7.8.3
^ permalink raw reply related
* Re: gitweb showing slash r at the end of line
From: Jakub Narebski @ 2012-01-28 17:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ondra Medek, git
In-Reply-To: <7vvcnwybxj.fsf@alter.siamese.dyndns.org>
On Sat, 28 Jan 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Ondra Medek <xmedeko@gmail.com> writes:
>>
>>> we have gitweb running on Linux box. Some files have Windows line ending
>>> (CRLF) end we do not use core.autcrlf translation. gitweb show the last \r
>>> in the end of each line, which is annoying.
>>
>> Well, this "\r" allows to recognize when file with Windows line ending
>> (CRLF) made it into repository... which usually is discouraged. But
>> if you allow this, I can understand that those "\r" at the end of
>> every line can be annoying.
>
> I think the right thing to do is:
>
> * If the repository data is _supposed_ to have CRLF endings (e.g. check
> with core.crlf or something), strip \r and do not show them.
>
> * Otherwise, i.e. if the repository data is supposed _not_ to have CRLF
> endings, do show these '\r'. Annoyance here is a *feature* to remind
> the viewer that the contents needs _fixing_.
>
> * No other switches.
I agree that it would be a bast solution if gitweb could automatically
infer whether CRLF is allowed (whitelist) or disallowed (blacklist) in
files in given repository.
But I am not sure if it is possible and what rules there should be for
a *BARE* repository; crlf and eol gitattributes and config variables
are about what should appear in working area - something gitweb is not
interested in at all.
If gitweb code was structured in different way, we could check if all
lines end in LF or all lines end in CRLF and add a note about that to
file or diff header, showing "\r" only in case of mixed line endings...
But that's a futile wish, for now at least.
--
Jakub Narebski
Poland
^ permalink raw reply
* 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
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