* 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: 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: 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: [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: [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
* [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
* 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
* 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
* 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: 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: [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
* BUG 1.7.9: git branch fails to create new branch when --edit-description is used
From: Mark Jason Dominus @ 2012-01-27 21:52 UTC (permalink / raw)
To: git
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?
Creating the branch and editing the description afterwards works correctly:
% git branch blarf
% git branch --edit-description blarf
% git branch -a
blarf
* master
% cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
description = I like pie\n
[branch "blarf"]
description = I like blarf\n
Mark Jason Dominus mjd@plover.com
^ permalink raw reply
* Re: [PATCH] gitweb: add pf= to limit project list to a subdirectory
From: Jakub Narebski @ 2012-01-27 22:33 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20120126144517.GA4229@server.brlink.eu>
"Bernhard R. Link" <brl+list+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.
Could you explain why you want this feature, and why for example
project search just does not cut it?
> 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.
> 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.
> Reusing $project instead of adding a new parameter would have been
> nicer from a UI point-of-view (including PATH_INFO support) but
> complicate the $project validating code that is currently being
> used to ensure nothing is exported that should not be viewable.
That is I think quite reasonable.
> Signed-off-by: Bernhard R. Link <brlink@debian.org>
>
> ---
> 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).
[...]
> @@ -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).
> @@ -5979,7 +5997,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);
> if (!@list) {
> die_error(404, "No projects found");
> }
> @@ -6018,7 +6036,7 @@ sub git_forks {
> }
>
> sub git_project_index {
> - my @projects = git_get_projects_list();
> + my @projects = git_get_projects_list($project_filter);
> if (!@projects) {
> die_error(404, "No projects found");
> }
> @@ -7855,7 +7873,7 @@ sub git_atom {
> }
>
> sub git_opml {
> - my @list = git_get_projects_list();
> + my @list = git_get_projects_list($project_filter);
> if (!@list) {
> die_error(404, "No projects found");
> }
Nice!
--
Jakub Narebski
^ permalink raw reply
* What's cooking in git.git (Jan 2012, #06; Fri, 27)
From: Junio C Hamano @ 2012-01-27 21:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vipjwzvc2.fsf@alter.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
Now 1.7.9 is out, the development cycle for 1.7.10 will start shortly.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* jl/submodule-re-add (2012-01-24) 1 commit
(merged to 'next' on 2012-01-26 at 482553e)
+ submodule add: fix breakage when re-adding a deep submodule
Low-impact fix to an old issue.
Will merge early in the next cycle.
* jn/svn-fe (2012-01-27) 44 commits
- vcs-svn/svndiff.c: squelch false "unused" warning from gcc
- Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-fe
- vcs-svn: reset first_commit_done in fast_export_init
- Merge branch 'db/text-delta' into svn-fe
- vcs-svn: do not initialize report_buffer twice
- Merge branch 'db/text-delta' into svn-fe
- vcs-svn: avoid hangs from corrupt deltas
- vcs-svn: guard against overflow when computing preimage length
- Merge branch 'db/delta-applier' into db/text-delta
- vcs-svn: implement text-delta handling
- Merge branch 'db/delta-applier' into db/text-delta
- Merge branch 'db/delta-applier' into svn-fe
- vcs-svn: cap number of bytes read from sliding view
- test-svn-fe: split off "test-svn-fe -d" into a separate function
- vcs-svn: let deltas use data from preimage
- vcs-svn: let deltas use data from postimage
- vcs-svn: verify that deltas consume all inline data
- vcs-svn: implement copyfrom_data delta instruction
- vcs-svn: read instructions from deltas
- vcs-svn: read inline data from deltas
- vcs-svn: read the preimage when applying deltas
- vcs-svn: parse svndiff0 window header
- vcs-svn: skeleton of an svn delta parser
- vcs-svn: make buffer_read_binary API more convenient
- vcs-svn: learn to maintain a sliding view of a file
- Makefile: list one vcs-svn/xdiff object or header per line
- Merge branch 'db/svn-fe-code-purge' into svn-fe
- vcs-svn: drop obj_pool
- vcs-svn: drop treap
- vcs-svn: drop string_pool
- vcs-svn: pass paths through to fast-import
- Merge branch 'db/strbufs-for-metadata' into db/svn-fe-code-purge
- Merge branch 'db/length-as-hash' (early part) into db/svn-fe-code-purge
- Merge branch 'db/vcs-svn-incremental' into svn-fe
- vcs-svn: avoid using ls command twice
- vcs-svn: use mark from previous import for parent commit
- vcs-svn: handle filenames with dq correctly
- vcs-svn: quote paths correctly for ls command
- vcs-svn: eliminate repo_tree structure
- vcs-svn: add a comment before each commit
- vcs-svn: save marks for imported commits
- vcs-svn: use higher mark numbers for blobs
- vcs-svn: set up channel to read fast-import cat-blob response
- Merge commit 'v1.7.5' into svn-fe
Will merge early in the next cycle.
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* mh/ref-api-rest (2011-12-12) 35 commits
. repack_without_ref(): call clear_packed_ref_cache()
. read_packed_refs(): keep track of the directory being worked in
. is_refname_available(): query only possibly-conflicting references
. refs: read loose references lazily
. read_loose_refs(): take a (ref_entry *) as argument
. struct ref_dir: store a reference to the enclosing ref_cache
. sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
. do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
. add_entry(): take (ref_entry *) instead of (ref_dir *)
. search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
. find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
. add_ref(): take (ref_entry *) instead of (ref_dir *)
. read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
. find_ref(): take (ref_entry *) instead of (ref_dir *)
. is_refname_available(): take (ref_entry *) instead of (ref_dir *)
. get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
. get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
. refs: wrap top-level ref_dirs in ref_entries
. get_ref_dir(): keep track of the current ref_dir
. do_for_each_ref(): only iterate over the subtree that was requested
. refs: sort ref_dirs lazily
. sort_ref_dir(): do not sort if already sorted
. refs: store references hierarchically
. refs.c: rename ref_array -> ref_dir
. struct ref_entry: nest the value part in a union
. check_refname_component(): return 0 for zero-length components
. free_ref_entry(): new function
. refs.c: reorder definitions more logically
. is_refname_available(): reimplement using do_for_each_ref_in_array()
. names_conflict(): simplify implementation
. names_conflict(): new function, extracted from is_refname_available()
. repack_without_ref(): reimplement using do_for_each_ref_in_array()
. do_for_each_ref_in_arrays(): new function
. do_for_each_ref_in_array(): new function
. do_for_each_ref(): correctly terminate while processesing extra_refs
I had to remove this temporarily out of 'pu' as I didn't want to deal with
merge conflicts with the mh/ref-clone-without-extra-refs topic that
removes yet another caller of add_extra_ref() that this series touches.
Will defer till the next cycle.
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
(merged to 'next' on 2012-01-05 at 954f125)
+ perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
Will defer till the next cycle.
* nd/commit-ignore-i-t-a (2012-01-16) 2 commits
- commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
- cache-tree: update API to take abitrary flags
May want to consider this as fixing an earlier UI mistake, and not as a
feature that devides the userbase.
Will defer till the next cycle.
--------------------------------------------------
[Cooking]
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
* jl/test-pause (2012-01-17) 1 commit
(merged to 'next' on 2012-01-20 at ee56335)
+ test-lib: add the test_pause convenience function
Looked reasonable.
Will merge early in the next cycle.
* mh/ref-clone-without-extra-refs (2012-01-17) 4 commits
(merged to 'next' on 2012-01-20 at 2e9645e)
+ write_remote_refs(): create packed (rather than extra) refs
+ add_packed_ref(): new function in the refs API.
+ ref_array: keep track of whether references are sorted
+ pack_refs(): remove redundant check
Looked reasonable; will hopefully help making mh/ref-api-rest simpler and
cleaner.
Will merge early in the next cycle.
* 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'.
* ar/i18n-no-gettext (2012-01-27) 4 commits
(merged to 'next' on 2012-01-27 at 0ecf258)
+ i18n: Do not force USE_GETTEXT_SCHEME=fallthrough on NO_GETTEXT
(merged to 'next' on 2012-01-23 at 694a94e)
+ i18n: Make NO_GETTEXT imply fallthrough scheme in shell l10n
+ add a Makefile switch to avoid gettext translation in shell scripts
+ git-sh-i18n: restructure the logic to compute gettext.sh scheme
Will merge early in the next cycle and deal with any fallout in 'master'.
* da/maint-mergetool-twoway (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at f927323)
+ mergetool: Provide an empty file when needed
Caters to GUI merge backends that cannot merge two files without
a base by giving them an empty file as a "pretend" common ancestor.
Will merge early in the next cycle and deal with any fallout in 'master'.
* jc/maint-log-first-parent-pathspec (2012-01-19) 1 commit
(merged to 'next' on 2012-01-20 at fb2b35f)
+ Making pathspec limited log play nicer with --first-parent
A bugfix.
Will merge early in the next cycle.
* ld/git-p4-branches-and-labels (2012-01-20) 5 commits
(merged to 'next' on 2012-01-23 at 9020ec4)
+ git-p4: label import fails with multiple labels at the same changelist
+ git-p4: add test for p4 labels
+ git-p4: importing labels should cope with missing owner
+ git-p4: cope with labels with empty descriptions
+ git-p4: handle p4 branches and labels containing shell chars
(this branch is used by va/git-p4-branch.)
Will merge early in the next cycle.
* va/git-p4-branch (2012-01-26) 4 commits
(merged to 'next' on 2012-01-26 at e67c52a)
+ t9801: do not overuse test_must_fail
+ git-p4: Change p4 command invocation
+ git-p4: Add test case for complex branch import
+ git-p4: Search for parent commit on branch creation
(this branch uses ld/git-p4-branches-and-labels.)
Rerolled and Acked.
Will merge early in the next cycle.
* sp/smart-http-failure-to-push (2012-01-20) 1 commit
(merged to 'next' on 2012-01-20 at a892434)
+ remote-curl: Fix push status report when all branches fail
Looked reasonable.
Will merge early in the next cycle.
* ks/sort-wildcard-in-makefile (2012-01-22) 1 commit
(merged to 'next' on 2012-01-23 at e2e0c1d)
+ t/Makefile: Use $(sort ...) explicitly where needed
Looked reasonable.
Will merge early in the next cycle.
* tr/grep-l-with-decoration (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 42b8795)
+ grep: fix -l/-L interaction with decoration lines
Looked reasonable.
Will merge early in the next cycle.
* jc/pull-signed-tag (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 4257553)
+ merge: use editor by default in interactive sessions
Per Linus's strong suggestion, sugarcoated (aka "taking blame for the
original UI screw-ups") so that it is easier for me to swallow and accept
a potentially huge backward incompatibility issue, "git merge" is made to
launch an editor to explain the merge in the merge commit by default in
interactive sessions.
I've updated the special-case environment variable to MERGE_AUTOEDIT that
scripts can set to "no" when they start. There is no plan to encourage
humans to keep using the historical behaviour, hence there is no support
for configuration variable (e.g. merge.autoedit) that can be set to 'no'.
Oh, also I updated the documentation a bit.
Will merge early in the next cycle and deal with any fallout in 'master'.
* nd/maint-refname-in-hierarchy-check (2012-01-11) 1 commit
(merged to 'next' on 2012-01-20 at acb5611)
+ Fix incorrect ref namespace check
Avoid getting confused by "ref/headxxx" and mistaking it as if it is under
the "refs/heads/" hierarchy.
Will merge early in the next cycle.
* jc/advise-i18n (2011-12-22) 1 commit
(merged to 'next' on 2012-01-23 at 6447013)
+ i18n of multi-line advice messages
Allow localization of advice messages that tend to be longer and
multi-line formatted. For now this is deliberately limited to advise()
interface and not vreportf() in general as touching the latter has
interactions with error() that has plumbing callers whose prefix "error: "
should never be translated.
Will merge early in the next cycle.
* rr/sequencer (2012-01-11) 2 commits
(merged to 'next' on 2012-01-23 at f349b56)
+ sequencer: factor code out of revert builtin
+ revert: prepare to move replay_action to header
Moving large chunk of code out of cherry-pick/revert for later reuse,
primarily to prepare for the next cycle.
Will merge early in the next cycle.
* tr/maint-mailinfo (2012-01-16) 2 commits
(merged to 'next' on 2012-01-20 at 278fae1)
+ mailinfo: with -b, keep space after [foo]
+ am: learn passing -b to mailinfo
Looked reasonable.
Will merge early in the next cycle.
* pw/p4-view-updates (2012-01-11) 5 commits
(merged to 'next' on 2012-01-20 at 8ca2c7b)
+ git-p4: add tests demonstrating spec overlay ambiguities
+ git-p4: adjust test to adhere to stricter useClientSpec
+ git-p4: clarify comment
+ git-p4: fix verbose comment typo
+ git-p4: only a single ... wildcard is supported
Will merge early in the next cycle.
* rs/diff-postimage-in-context (2012-01-06) 1 commit
(merged to 'next' on 2012-01-09 at 9635032)
+ xdiff: print post-image for common records instead of pre-image
Looked reasonable.
Will merge early in the next cycle and deal with any fallout in 'master'.
* cb/push-quiet (2012-01-08) 3 commits
(merged to 'next' on 2012-01-20 at 4326dda)
+ t5541: avoid TAP test miscounting
+ fix push --quiet: add 'quiet' capability to receive-pack
+ server_supports(): parse feature list more carefully
Looked reasonable.
Will merge early in the next cycle.
* nd/clone-detached (2012-01-24) 12 commits
(merged to 'next' on 2012-01-26 at 7b0cc8a)
+ clone: fix up delay cloning conditions
(merged to 'next' on 2012-01-23 at bee31c6)
+ push: do not let configured foreign-vcs permanently clobbered
(merged to 'next' on 2012-01-23 at 9cab64e)
+ clone: print advice on checking out detached HEAD
+ clone: allow --branch to take a tag
+ clone: refuse to clone if --branch points to bogus ref
+ clone: --branch=<branch> always means refs/heads/<branch>
+ clone: delay cloning until after remote HEAD checking
+ clone: factor out remote ref writing
+ clone: factor out HEAD update code
+ clone: factor out checkout code
+ clone: write detached HEAD in bare repositories
+ t5601: add missing && cascade
(this branch uses nd/clone-single-branch.)
Applied two band-aids to a corner-case regression.
Will merge early in the next cycle and deal with any fallout in 'master'.
* nd/clone-single-branch (2012-01-08) 1 commit
(merged to 'next' on 2012-01-09 at 6c3c759)
+ clone: add --single-branch to fetch only one branch
(this branch is used by nd/clone-detached.)
Looked reasonable.
Will merge early in the next cycle.
* jn/gitweb-unspecified-action (2012-01-09) 1 commit
(merged to 'next' on 2012-01-20 at 2b31714)
+ gitweb: Fix actionless dispatch for non-existent objects
Looked reasonable.
Will merge early in the next cycle.
* nd/index-pack-no-recurse (2012-01-16) 3 commits
(merged to 'next' on 2012-01-20 at d1e964e)
+ index-pack: eliminate unlimited recursion in get_base_data()
+ index-pack: eliminate recursion in find_unresolved_deltas
+ Eliminate recursion in setting/clearing marks in commit list
Much better explained than the previous round.
Will merge early in the next cycle and deal with any fallout in 'master'.
* cb/git-daemon-tests (2012-01-08) 5 commits
(merged to 'next' on 2012-01-08 at 1db8351)
+ git-daemon tests: wait until daemon is ready
+ git-daemon: produce output when ready
+ git-daemon: add tests
+ dashed externals: kill children on exit
+ run-command: optionally kill children on exit
Will merge early in the next cycle.
* jk/parse-object-cached (2012-01-06) 3 commits
(merged to 'next' on 2012-01-08 at 8c6fa4a)
+ upload-pack: avoid parsing tag destinations
+ upload-pack: avoid parsing objects during ref advertisement
+ parse_object: try internal cache before reading object db
These are a bit scary changes, but I do think they are worth doing.
Will merge early in the next cycle and deal with any fallout in 'master'.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2012-01-27 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <7vipjwzvc2.fsf@alter.siamese.dyndns.org>
Welcome to git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
Some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.9 done on
Jan 27, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.8.4. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong, David D. Kilzer and Sam Vilain on git-svn.
- Simon Hausmann and Pete Wyckoff on git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
gitweb.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
^ permalink raw reply
* Re: Fwd: Gitweb error
From: Jakub Narebski @ 2012-01-27 21:39 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <61c866a5-31a0-4994-ae29-2086f18e707b@o9g2000yqa.googlegroups.com>
rajesh boyapati <boyapatisrajesh@gmail.com> writes:
> We integrated git-web to our gerrit Code-review.
> I installed gitweb using the command:
> $ sudo apt-get install gitweb
> Then I configured gitweb to our gerrit using the command:
> $ git config --file $SITE_PATH/etc/gerrit.config gitweb.cgi /usr/lib/
> cgi-bin/gitweb.cgi
> Now the gitweb is added to gerrit.config and in gerrit config file, it
> looks like
> [gitweb]
> cgi = /usr/lib/cgi-bin/gitweb.cgi
> Then, restarted gerrit server.
This combination of gitweb (which version?) and Gerrit can be hard to
debug, unfortunately.
> When I go to one of the projects in gerrit through gitweb and when I
> click "summary", I am getting the below error.
> If I click other tabs(log, shortlog, commit, tree,etc) after clicking
> "summary", I am getting following error in error-log.
> If I click other tabs(log, shortlog, commit, tree,etc) before clicking
> "summary", everything works fine.
>
> Error:
> =================================================================
> [2012-01-25 18:50:32,334] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
> 18:50:32 2012] gitweb.cgi: Use of uninitialized value $head in string
> eq at /usr/lib/cgi-bin/gitweb.cgi line 4720.
Could you show this line and about 3 lines of context in your
gitweb.cgi?
> [2012-01-25 18:50:35,658] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
> 18:50:35 2012] gitweb.cgi: Use of uninitialized value $commit_id in
> open at /usr/lib/cgi-bin/gitweb.cgi line 2817.
Same here.
> [2012-01-25 18:50:35,660] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad
> revision ''
It looks like gitweb incorrectly gets empty revision
parameter... strange.
--
Jakub Narebski
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Jakub Narebski @ 2012-01-27 21:35 UTC (permalink / raw)
To: Ondra Medek; +Cc: git
In-Reply-To: <1327673954458-7229895.post@n2.nabble.com>
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.
A simple _workaround_ would be to create one's own extra stylesheet,
with rule hiding control characters visualization (including "\r"), e.g.
.cntrl { display: none; }
and stuff thys additional it in @stylesheets via gitweb config file.
> I have created a simple patch to avoid this.
Please read Documentation/SubmittingPatches if you want your work to
be considered for inclusion. This is not a proper patch -- it lacks
commit message (comments should be outside of it, e.g. between "---"
and diffstat) and signoff.
> It adds just one line. I am not sure if the regexp should
> contain 'g' switch in the end. Also, not sure if there should be some config
> option to switch on/off this?
Note that your patch beside hiding "\r" in the case when file has
Windows line endings, it also hides "\r" in the case where file has
_mixed_ line endings (LF mixed with CRLF, which is incorrect). Though
handling that well would be quite difficult, I think...
Though esc_html gets passed whole lines, I am not sure if it always
gets passed whole lines and would continue getting passed only whole
lines in the future, so there should be 'g' modifier (or better 'gm'
modifier to make sure that $ matches end of line not only end of
string).
I think it would be better if there was an option to switch hiding
"\r" on and off... though I am not sure if it can be done without
incuring large performance penalty.
> ---
> gitweb/gitweb.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index abb5a79..92175bc 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1500,6 +1500,7 @@ sub esc_html {
> if ($opts{'-nbsp'}) {
> $str =~ s/ / /g;
> }
> + $str =~ s/\r$//;
> $str =~ s|([[:cntrl:]])|(($1 ne "\t") ? quot_cec($1) : $1)|eg;
> return $str;
> }
> --
Another solution would be to modify quot_cec...
--
Jakub Narebski
^ permalink raw reply
* [ANNOUNCE] Git 1.7.9
From: Junio C Hamano @ 2012-01-27 21:31 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest feature release Git 1.7.9 is now available at the usual
places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
ed51ef5ef250daaa6e98515cf2641820cd268d4c git-1.7.9.tar.gz
c7b1fa20dc501beb2cb5091dd24dbfd2a0013a0c git-htmldocs-1.7.9.tar.gz
1ca1fc430b2814f9e9cf82ec3bf7f2eaf5209b7a git-manpages-1.7.9.tar.gz
Also the following public repositories all have a copy of the v1.7.9
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Have fun.
Git v1.7.9 Release Notes
========================
Updates since v1.7.8
--------------------
* gitk updates accumulated since early 2011.
* git-gui updated to 0.16.0.
* git-p4 (in contrib/) updates.
* Git uses gettext to translate its most common interface messages
into the user's language if translations are available and the
locale is appropriately set. Distributors can drop new PO files
in po/ to add new translations.
* The code to handle username/password for HTTP transactions used in
"git push" & "git fetch" learned to talk "credential API" to
external programs to cache or store them, to allow integration with
platform native keychain mechanisms.
* The input prompts in the terminal use our own getpass() replacement
when possible. HTTP transactions used to ask for the username without
echoing back what was typed, but with this change you will see it as
you type.
* The internals of "revert/cherry-pick" have been tweaked to prepare
building more generic "sequencer" on top of the implementation that
drives them.
* "git rev-parse FETCH_HEAD" after "git fetch" without specifying
what to fetch from the command line will now show the commit that
would be merged if the command were "git pull".
* "git add" learned to stream large files directly into a packfile
instead of writing them into individual loose object files.
* "git checkout -B <current branch> <elsewhere>" is a more intuitive
way to spell "git reset --keep <elsewhere>".
* "git checkout" and "git merge" learned "--no-overwrite-ignore" option
to tell Git that untracked and ignored files are not expendable.
* "git commit --amend" learned "--no-edit" option to say that the
user is amending the tree being recorded, without updating the
commit log message.
* "git commit" and "git reset" re-learned the optimization to prime
the cache-tree information in the index, which makes it faster to
write a tree object out after the index entries are updated.
* "git commit" detects and rejects an attempt to stuff NUL byte in
the commit log message.
* "git commit" learned "-S" to GPG-sign the commit; this can be shown
with the "--show-signature" option to "git log".
* fsck and prune are relatively lengthy operations that still go
silent while making the end-user wait. They learned to give progress
output like other slow operations.
* The set of built-in function-header patterns for various languages
knows MATLAB.
* "git log --format='<format>'" learned new %g[nNeE] specifiers to
show information from the reflog entries when walking the reflog
(i.e. with "-g").
* "git pull" can be used to fetch and merge an annotated/signed tag,
instead of the tip of a topic branch. The GPG signature from the
signed tag is recorded in the resulting merge commit for later
auditing.
* "git log" learned "--show-signature" option to show the signed tag
that was merged that is embedded in the merge commit. It also can
show the signature made on the commit with "git commit -S".
* "git branch --edit-description" can be used to add descriptive text
to explain what a topic branch is about.
* "git fmt-merge-msg" learned to take the branch description into
account when preparing a merge summary that "git merge" records
when merging a local branch.
* "git request-pull" has been updated to convey more information
useful for integrators to decide if a topic is worth merging and
what is pulled is indeed what the requestor asked to pull,
including:
- the tip of the branch being requested to be merged;
- the branch description describing what the topic is about;
- the contents of the annotated tag, when requesting to pull a tag.
* "git pull" learned to notice 'pull.rebase' configuration variable,
which serves as a global fallback for setting 'branch.<name>.rebase'
configuration variable per branch.
* "git tag" learned "--cleanup" option to control how the whitespaces
and empty lines in tag message are cleaned up.
* "gitweb" learned to show side-by-side diff.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.7.8
------------------
Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
releases are contained in this release (see release notes to them for
details).
^ permalink raw reply
* Re: commit/from command in git-fast-import
From: Jonathan Nieder @ 2012-01-27 21:09 UTC (permalink / raw)
To: David Barr; +Cc: Mike Hommey, git, Dmitry Ivankov, Sverre Rabbelier
In-Reply-To: <CAFfmPPM_xqZoMd391UdqRtK5bgW5V2z9Mg=8LYLA7ZVZQGR3Mg@mail.gmail.com>
David Barr wrote:
>>> On Sat, Jan 28, 2012 at 1:08 AM, Mike Hommey <mh@glandium.org> wrote:
>>>> This is however not what the manpage suggests in what I quoted in my
>>>> message:
>>>> Omitting the from command on existing branches is usually desired, as
>>>> the current commit on that branch is automatically assumed to be the
>>>> first ancestor of the new commit.
[...]
> Looks like we have a real fast-import bug, in Debian Unstable at least.
Yep, this is a real fast-import documentation bug. The manual says:
Omitting the from command in the first commit of a new branch
will cause fast-import to create that commit with no ancestor.
This tends to be desired only for the initial commit of a
project.
[...]
The special case of restarting an incremental import from the
current branch value should be written as:
from refs/heads/branch^0
The unfortunate term here is "existing branches", which seems to have
been intended to refer to refs that have already been populated in
this fast-import stream by a "commit" or "reset" command, rather than
any old ref that already exists in the repository.
In other words, instead of "existing branch", the manual should say
something along the lines of "branch already in fast-import's internal
branch table".
Here's a sketch.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-fast-import.txt | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index ec6ef311..28a317ff 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -306,9 +306,9 @@ and control the current import process. More detailed discussion
(with examples) of each command follows later.
`commit`::
- Creates a new branch or updates an existing branch by
- creating a new commit and updating the branch to point at
- the newly created commit.
+ Creates a new branch or updates a branch by creating a new
+ commit and updating the branch to point at the newly created
+ commit.
`tag`::
Creates an annotated tag object from an existing commit or
@@ -317,7 +317,7 @@ and control the current import process. More detailed discussion
in time.
`reset`::
- Reset an existing branch (or a new branch) to a specific
+ Reset an existing branch or a new branch to a specific
revision. This command must be used to change a branch to
a specific revision without making a commit on it.
@@ -439,13 +439,15 @@ The `from` command is used to specify the commit to initialize
this branch from. This revision will be the first ancestor of the
new commit.
-Omitting the `from` command in the first commit of a new branch
+Omitting the `from` command in the first commit of a branch that
+has not been created previously with a `commit` or `reset` command
will cause fast-import to create that commit with no ancestor. This
tends to be desired only for the initial commit of a project.
If the frontend creates all files from scratch when making a new
branch, a `merge` command may be used instead of `from` to start
the commit with an empty tree.
-Omitting the `from` command on existing branches is usually desired,
+Omitting the `from` command on branches that have already been
+initialized in the same stream is usually desired,
as the current commit on that branch is automatically assumed to
be the first ancestor of the new commit.
--
1.7.9.rc2
^ permalink raw reply related
* Re: commit/from command in git-fast-import
From: David Barr @ 2012-01-27 20:56 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Dmitry Ivankov, Sverre Rabbelier, Jonathan Nieder
In-Reply-To: <20120127144702.GA6693@glandium.org>
On Sat, Jan 28, 2012 at 1:47 AM, Mike Hommey <mh@glandium.org> wrote:
> On Sat, Jan 28, 2012 at 01:15:34AM +1100, David Barr wrote:
>> On Sat, Jan 28, 2012 at 1:08 AM, Mike Hommey <mh@glandium.org> wrote:
>> > On Sat, Jan 28, 2012 at 01:00:17AM +1100, David Barr wrote:
>> >> On Fri, Jan 27, 2012 at 11:48 PM, Mike Hommey <mh@glandium.org> wrote:
>> >> > When I do create a commit on a given branch with a stream like:
>> >> > commit refs/heads/branch
>> >> > author ...
>> >> > committer ...
>> >> > data <<EOF
>> >> > Commit message
>> >> > EOF
>> >> > deleteall
>> >> >
>> >> > All I get is this warning:
>> >> > warning: Not updating refs/heads/branch (new tip new_sha1
>> >> > does not contain old_sha1)
>> >> >
>> >> > And the branch only has one commit, which is the one I just created.
>> >> > On the other hand, if I add a "from" instruction in the above stream,
>> >> > I have the expected branch history.
>> >>
>> >> This is precisely the expected behavior.
>> >> If 'from' is omitted, the resulting commit has no preceding history.
>> >> On the other hand, what you want is to specify the parent so that
>> >> there is a continuation of history.
>> >
>> > This is however not what the manpage suggests in what I quoted in my
>> > message:
>> > Omitting the from command on existing branches is usually desired, as
>> > the current commit on that branch is automatically assumed to be the
>> > first ancestor of the new commit.
>> >
>> > Mike
>>
>> Oh, right. I guess I wasn't paying enough attention, sorry.
>> That does sound like a bug then. Is it reproducible in a new repo?
>> eg:
>> git init foo && cd foo && touch bar && git add -A && git commit -m "baz"
>> git fast-import < ../fast-import-regression.txt
>
> It is.
I accidentally took this thread off-list.
Looks like we have a real fast-import bug, in Debian Unstable at least.
--
David Barr
^ permalink raw reply
* Re: [PATCH] Revert "gitweb: Time::HiRes is in core for Perl 5.8"
From: Junio C Hamano @ 2012-01-27 20:44 UTC (permalink / raw)
To: Jakub Narebski
Cc: Ævar Arnfjörð Bjarmason, Hallvard Breien Furuseth,
git
In-Reply-To: <201201271845.39576.jnareb@gmail.com>
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.
> For example RedHat has split it out to a separate RPM perl-Time-HiRes.
>
> Noticed-by: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
> Suggested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Signed-off-by: Jakub Narębski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> 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()?
>
> 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)
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.
^ permalink raw reply
* Re: [PULL] svn-fe updates for master or next
From: Junio C Hamano @ 2012-01-27 18:50 UTC (permalink / raw)
To: Jonathan Nieder
Cc: David Barr, Scott Chacon, Brian Gernhardt, david,
Ramkumar Ramachandra, git, Dmitry Ivankov
In-Reply-To: <20120127003258.GA6946@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> t/t0081-line-buffer.sh | 106 +-------------
Curious; this series seem to be based on a codebase that is older than
6908e99 (Revert "t0081 (line-buffer): add buffering tests", 2011-03-30).
Not complaining, not asking any question. Just making an observation.
^ permalink raw reply
* Re: [PULL] svn-fe updates for master or next
From: Junio C Hamano @ 2012-01-27 18:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: David Barr, Scott Chacon, Brian Gernhardt, david,
Ramkumar Ramachandra, git, Dmitry Ivankov
In-Reply-To: <20120127003258.GA6946@burratino>
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.
By the way, we should have done a GPG keysigning at the last GitTogether.
The above paragraph ("The series simplifies svn-fe a great deal...") could
have been recorded in the message body of a signed tag, and we could have
started eating our own dogfood, now even Linus and his lieutenants are
using the upcoming 1.7.9 feature.
^ permalink raw reply
* Fwd: Git-web error
From: rajesh boyapati @ 2012-01-27 18:15 UTC (permalink / raw)
To: git
In-Reply-To: <5fa08a8b-f0a2-4796-bf0d-06a8f13bf703@b23g2000yqn.googlegroups.com>
---------- Forwarded message ----------
From: rajesh boyapati <boyapatisraj...@gmail.com>
Date: Jan 25, 7:10 pm
Subject: Git-web error
To: Repo and Gerrit Discussion
Hi,
We integrated git-web to our gerrit Code-review.
I installed gitweb using the command:
$ sudo apt-get install gitweb
Then I configured gitweb to our gerrit using the command:
$ git config --file $SITE_PATH/etc/gerrit.config gitweb.cgi /usr/lib/
cgi-bin/gitweb.cgi
Now the gitweb is added to gerrit.config and in gerrit config file, it
looks like
[gitweb]
cgi = /usr/lib/cgi-bin/gitweb.cgi
Then, restarted gerrit server.
When I go to one of the projects in gerrit through gitweb and when I
click "summary", I am getting the below error.
If I click other tabs(log, shortlog, commit, tree,etc) after clicking
"summary", I am getting following error in error-log.
If I click other tabs(log, shortlog, commit, tree,etc) before clicking
"summary", everything works fine.
Error:
=================================================================
[2012-01-25 18:50:32,334] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
18:50:32 2012] gitweb.cgi: Use of uninitialized value $head in string
eq at /usr/lib/cgi-bin/gitweb.cgi line 4720.
[2012-01-25 18:50:35,658] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
18:50:35 2012] gitweb.cgi: Use of uninitialized value $commit_id in
open at /usr/lib/cgi-bin/gitweb.cgi line 2817.
[2012-01-25 18:50:35,660] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad
revision ''
[2012-01-25 18:50:39,209] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
18:50:39 2012] gitweb.cgi: Use of uninitialized value $commit_id in
open at /usr/lib/cgi-bin/gitweb.cgi line 2817.
[2012-01-25 18:50:39,210] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad
revision ''
[2012-01-25 18:50:40,656] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad
revision 'HEAD'
[2012-01-25 18:53:17,097] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad
revision 'HEAD'
[2012-01-25 18:53:17,113] ERROR
com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
18:53:17 2012] gitweb.cgi: Use of uninitialized value $head in string
eq at /usr/lib/cgi-bin/gitweb.cgi line 4720.
=================================================================
Can any one help me on how to resolve this issue?.
Thanks,
Rajesh.
^ permalink raw reply
* [PATCH] Revert "gitweb: Time::HiRes is in core for Perl 5.8"
From: Jakub Narebski @ 2012-01-27 17:45 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Hallvard Breien Furuseth, git
In-Reply-To: <CACBZZX4cjcY5d3mPJAV+rbSTqCEUOrF=_dd3ny_jSM++G-Bg1Q@mail.gmail.com>
On Mon, 23 Jan 2012, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jan 23, 2012 at 05:50, Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> wrote:
> >
> > t9500-gitweb-standalone-no-errors fails: Git 1.7.9.rc2/1.7.8.4, RHEL
> > 6.2, Perl 5.10.1. Reverting 3962f1d756ab41c1d180e35483d1c8dffe51e0d1
> > fixes it. The commit expects Time::HiRes to be present, but RedHat
> > has split it out to a separate RPM perl-Time-HiRes. Better add a
> > comment about that, so it doesn't get re-reverted.
> >
> > Or pacify the test and expect gitweb@RHEL-users to install the RPM:
[...]
> This doesn't actually fix the issue, it only sweeps it under the rug
> by making the tests pass, gitweb will still fail to compile on Red
> Hat once installed.
I think you meant "fail to run" here.
> I think the right solution is to partially revert
> 3962f1d756ab41c1d180e35483d1c8dffe51e0d1, but add a comment in the
> code indicating that it's to deal with RedHat's broken fork of Perl.
I have added comment in commit message, but not in code. I wonder if
it would be enough.
> However even if it's required in an eval it might still fail at
> runtime in the reset_timer() function, which'll need to deal with it
> too.
It shouldn't; everything else related to timer is protected with
'if defined $t0', which is false if Time::HiRes module is not available.
Here is the patch
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Subject: [PATCH] Revert "gitweb: Time::HiRes is in core for Perl 5.8"
This reverts commit 3962f1d756ab41c1d180e35483d1c8dffe51e0d1.
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.
For example RedHat has split it out to a separate RPM perl-Time-HiRes.
Noticed-by: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
Suggested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
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;
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;
}
@@ -3974,7 +3976,7 @@ sub git_footer_html {
print "<div id=\"generating_info\">\n";
print 'This page took '.
'<span id="generating_time" class="time_span">'.
- tv_interval($t0, [ gettimeofday() ]).
+ Time::HiRes::tv_interval($t0, [Time::HiRes::gettimeofday()]).
' seconds </span>'.
' and '.
'<span id="generating_cmd">'.
@@ -6253,7 +6255,7 @@ sub git_blame_common {
print 'END';
if (defined $t0 && gitweb_check_feature('timed')) {
print ' '.
- tv_interval($t0, [ gettimeofday() ]).
+ Time::HiRes::tv_interval($t0, [Time::HiRes::gettimeofday()]).
' '.$number_of_git_cmds;
}
print "\n";
--
1.7.6
^ permalink raw reply related
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