* [PATCH 19/21] grep: use writable strbuf from caller for grep_tree()
From: Nguyễn Thái Ngọc Duy @ 2010-12-17 12:44 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <AANLkTi=hXQqtYmhtHh+D67d9puRrDA+iScpafaYYMsAk@mail.gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
strbuf_offset and its patch are dropped.
builtin/grep.c | 51 ++++++++++++++++++++++++---------------------------
1 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index fbc7d02..fa1ad28 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -623,43 +623,29 @@ static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int
}
static int grep_tree(struct grep_opt *opt, const struct pathspec *pathspec,
- struct tree_desc *tree,
- const char *tree_name, const char *base)
+ struct tree_desc *tree, struct strbuf *base, int tn_len)
{
- int len;
int hit = 0;
struct name_entry entry;
- char *down;
- int tn_len = strlen(tree_name);
- struct strbuf pathbuf;
-
- strbuf_init(&pathbuf, PATH_MAX + tn_len);
-
- if (tn_len) {
- strbuf_add(&pathbuf, tree_name, tn_len);
- strbuf_addch(&pathbuf, ':');
- tn_len = pathbuf.len;
- }
- strbuf_addstr(&pathbuf, base);
- len = pathbuf.len;
+ int old_baselen = base->len;
while (tree_entry(tree, &entry)) {
int te_len = tree_entry_len(entry.path, entry.sha1);
- pathbuf.len = len;
- strbuf_add(&pathbuf, entry.path, te_len);
+
+ strbuf_add(base, entry.path, te_len);
if (S_ISDIR(entry.mode))
/* Match "abc/" against pathspec to
* decide if we want to descend into "abc"
* directory.
*/
- strbuf_addch(&pathbuf, '/');
+ strbuf_addch(base, '/');
- down = pathbuf.buf + tn_len;
- if (!pathspec_matches(pathspec->raw, down, opt->max_depth))
+ if (!pathspec_matches(pathspec->raw, base->buf + tn_len, opt->max_depth))
;
- else if (S_ISREG(entry.mode))
- hit |= grep_sha1(opt, entry.sha1, pathbuf.buf, tn_len);
+ else if (S_ISREG(entry.mode)) {
+ hit |= grep_sha1(opt, entry.sha1, base->buf, tn_len);
+ }
else if (S_ISDIR(entry.mode)) {
enum object_type type;
struct tree_desc sub;
@@ -671,13 +657,14 @@ static int grep_tree(struct grep_opt *opt, const struct pathspec *pathspec,
die("unable to read tree (%s)",
sha1_to_hex(entry.sha1));
init_tree_desc(&sub, data, size);
- hit |= grep_tree(opt, pathspec, &sub, tree_name, down);
+ hit |= grep_tree(opt, pathspec, &sub, base, tn_len);
free(data);
}
+ strbuf_setlen(base, old_baselen);
+
if (hit && opt->status_only)
break;
}
- strbuf_release(&pathbuf);
return hit;
}
@@ -690,13 +677,23 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,
struct tree_desc tree;
void *data;
unsigned long size;
- int hit;
+ struct strbuf base;
+ int hit, len;
+
data = read_object_with_reference(obj->sha1, tree_type,
&size, NULL);
if (!data)
die("unable to read tree (%s)", sha1_to_hex(obj->sha1));
+
+ len = name ? strlen(name) : 0;
+ strbuf_init(&base, PATH_MAX + len + 1);
+ if (len) {
+ strbuf_add(&base, name, len);
+ strbuf_addch(&base, ':');
+ }
init_tree_desc(&tree, data, size);
- hit = grep_tree(opt, pathspec, &tree, name, "");
+ hit = grep_tree(opt, pathspec, &tree, &base, base.len);
+ strbuf_release(&base);
free(data);
return hit;
}
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* [PATCH 20/21] grep: drop pathspec_matches() in favor of tree_entry_interesting()
From: Nguyễn Thái Ngọc Duy @ 2010-12-17 12:45 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1292425376-14550-21-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
tree_entry_interesting now takes base_offset. The real base is
base->buf+base_offset
builtin/grep.c | 125 ++++++-------------------------------------------------
tree-diff.c | 4 +-
tree-walk.c | 19 ++++----
tree-walk.h | 2 +-
4 files changed, 27 insertions(+), 123 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index fa1ad28..7256002 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -333,106 +333,6 @@ static int grep_config(const char *var, const char *value, void *cb)
return 0;
}
-/*
- * Return non-zero if max_depth is negative or path has no more then max_depth
- * slashes.
- */
-static int accept_subdir(const char *path, int max_depth)
-{
- if (max_depth < 0)
- return 1;
-
- while ((path = strchr(path, '/')) != NULL) {
- max_depth--;
- if (max_depth < 0)
- return 0;
- path++;
- }
- return 1;
-}
-
-/*
- * Return non-zero if name is a subdirectory of match and is not too deep.
- */
-static int is_subdir(const char *name, int namelen,
- const char *match, int matchlen, int max_depth)
-{
- if (matchlen > namelen || strncmp(name, match, matchlen))
- return 0;
-
- if (name[matchlen] == '\0') /* exact match */
- return 1;
-
- if (!matchlen || match[matchlen-1] == '/' || name[matchlen] == '/')
- return accept_subdir(name + matchlen + 1, max_depth);
-
- return 0;
-}
-
-/*
- * git grep pathspecs are somewhat different from diff-tree pathspecs;
- * pathname wildcards are allowed.
- */
-static int pathspec_matches(const char **paths, const char *name, int max_depth)
-{
- int namelen, i;
- if (!paths || !*paths)
- return accept_subdir(name, max_depth);
- namelen = strlen(name);
- for (i = 0; paths[i]; i++) {
- const char *match = paths[i];
- int matchlen = strlen(match);
- const char *cp, *meta;
-
- if (is_subdir(name, namelen, match, matchlen, max_depth))
- return 1;
- if (!fnmatch(match, name, 0))
- return 1;
- if (name[namelen-1] != '/')
- continue;
-
- /* We are being asked if the directory ("name") is worth
- * descending into.
- *
- * Find the longest leading directory name that does
- * not have metacharacter in the pathspec; the name
- * we are looking at must overlap with that directory.
- */
- for (cp = match, meta = NULL; cp - match < matchlen; cp++) {
- char ch = *cp;
- if (ch == '*' || ch == '[' || ch == '?') {
- meta = cp;
- break;
- }
- }
- if (!meta)
- meta = cp; /* fully literal */
-
- if (namelen <= meta - match) {
- /* Looking at "Documentation/" and
- * the pattern says "Documentation/howto/", or
- * "Documentation/diff*.txt". The name we
- * have should match prefix.
- */
- if (!memcmp(match, name, namelen))
- return 1;
- continue;
- }
-
- if (meta - match < namelen) {
- /* Looking at "Documentation/howto/" and
- * the pattern says "Documentation/h*";
- * match up to "Do.../h"; this avoids descending
- * into "Documentation/technical/".
- */
- if (!memcmp(match, name, meta - match))
- return 1;
- continue;
- }
- }
- return 0;
-}
-
static void *lock_and_read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size)
{
void *data;
@@ -625,25 +525,24 @@ static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int
static int grep_tree(struct grep_opt *opt, const struct pathspec *pathspec,
struct tree_desc *tree, struct strbuf *base, int tn_len)
{
- int hit = 0;
+ int hit = 0, matched = 0;
struct name_entry entry;
int old_baselen = base->len;
while (tree_entry(tree, &entry)) {
int te_len = tree_entry_len(entry.path, entry.sha1);
- strbuf_add(base, entry.path, te_len);
+ if (matched != 2) {
+ matched = tree_entry_interesting(&entry, base, tn_len, pathspec);
+ if (matched == -1)
+ break; /* no more matches */
+ if (!matched)
+ continue;
+ }
- if (S_ISDIR(entry.mode))
- /* Match "abc/" against pathspec to
- * decide if we want to descend into "abc"
- * directory.
- */
- strbuf_addch(base, '/');
+ strbuf_add(base, entry.path, te_len);
- if (!pathspec_matches(pathspec->raw, base->buf + tn_len, opt->max_depth))
- ;
- else if (S_ISREG(entry.mode)) {
+ if (S_ISREG(entry.mode)) {
hit |= grep_sha1(opt, entry.sha1, base->buf, tn_len);
}
else if (S_ISDIR(entry.mode)) {
@@ -656,6 +555,8 @@ static int grep_tree(struct grep_opt *opt, const struct pathspec *pathspec,
if (!data)
die("unable to read tree (%s)",
sha1_to_hex(entry.sha1));
+
+ strbuf_addch(base, '/');
init_tree_desc(&sub, data, size);
hit |= grep_tree(opt, pathspec, &sub, base, tn_len);
free(data);
@@ -1062,6 +963,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
paths[1] = NULL;
}
init_pathspec(&pathspec, paths);
+ pathspec.max_depth = opt.max_depth;
+ pathspec.recursive = 1;
if (show_in_pager && (cached || list.nr))
die("--open-files-in-pager only works on the worktree");
diff --git a/tree-diff.c b/tree-diff.c
index bde2c52..064233a 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -72,7 +72,7 @@ static void show_tree(struct diff_options *opt, const char *prefix,
if (all_interesting)
show = 1;
else {
- show = tree_entry_interesting(&desc->entry, base,
+ show = tree_entry_interesting(&desc->entry, base, 0,
&opt->pathspec);
if (show == 2)
all_interesting = 1;
@@ -130,7 +130,7 @@ static void skip_uninteresting(struct tree_desc *t, struct strbuf *base,
if (all_interesting)
show = 1;
else {
- show = tree_entry_interesting(&t->entry, base,
+ show = tree_entry_interesting(&t->entry, base, 0,
&opt->pathspec);
if (show == 2)
all_interesting = 1;
diff --git a/tree-walk.c b/tree-walk.c
index 99413b3..9b43ad5 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -551,17 +551,17 @@ static int match_dir_prefix(const char *base, int baselen,
* - negative for "no, and no subsequent entries will be either"
*/
int tree_entry_interesting(const struct name_entry *entry,
- struct strbuf *base,
+ struct strbuf *base, int base_offset,
const struct pathspec *ps)
{
int i;
- int pathlen, baselen = base->len;
+ int pathlen, baselen = base->len - base_offset;
int never_interesting = ps->has_wildcard ? 0 : -1;
if (!ps->nr) {
if (!ps->recursive || ps->max_depth == -1)
return 1;
- return !!within_depth(base->buf, baselen,
+ return !!within_depth(base->buf + base_offset, baselen,
!!S_ISDIR(entry->mode),
ps->max_depth);
}
@@ -571,24 +571,25 @@ int tree_entry_interesting(const struct name_entry *entry,
for (i = ps->nr-1; i >= 0; i--) {
const struct pathspec_item *item = ps->items+i;
const char *match = item->match;
+ const char *base_str = base->buf + base_offset;
int matchlen = item->len;
if (baselen >= matchlen) {
/* If it doesn't match, move along... */
- if (!match_dir_prefix(base->buf, baselen, match, matchlen))
+ if (!match_dir_prefix(base_str, baselen, match, matchlen))
goto match_wildcards;
if (!ps->recursive || ps->max_depth == -1)
return 2;
- return !!within_depth(base->buf + matchlen + 1,
+ return !!within_depth(base_str + matchlen + 1,
baselen - matchlen - 1,
!!S_ISDIR(entry->mode),
ps->max_depth);
}
/* Does the base match? */
- if (!strncmp(base->buf, match, baselen)) {
+ if (!strncmp(base_str, match, baselen)) {
if (match_entry(entry, pathlen,
match + baselen, matchlen - baselen,
&never_interesting))
@@ -620,11 +621,11 @@ match_wildcards:
strbuf_add(base, entry->path, pathlen);
- if (!fnmatch(match, base->buf, 0)) {
- strbuf_setlen(base, baselen);
+ if (!fnmatch(match, base->buf + base_offset, 0)) {
+ strbuf_setlen(base, base_offset + baselen);
return 1;
}
- strbuf_setlen(base, baselen);
+ strbuf_setlen(base, base_offset + baselen);
/*
* Match all directories. We'll try to match files
diff --git a/tree-walk.h b/tree-walk.h
index 6589ee2..39524b7 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -60,6 +60,6 @@ static inline int traverse_path_len(const struct traverse_info *info, const stru
return info->pathlen + tree_entry_len(n->path, n->sha1);
}
-extern int tree_entry_interesting(const struct name_entry *, struct strbuf *, const struct pathspec *ps);
+extern int tree_entry_interesting(const struct name_entry *, struct strbuf *, int, const struct pathspec *ps);
#endif
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* Re: Performance issue exposed by git-filter-branch
From: Nguyen Thai Ngoc Duy @ 2010-12-17 13:01 UTC (permalink / raw)
To: Ken Brownfield; +Cc: git
In-Reply-To: <41C1B4AC-8427-4D62-BEB6-689A4BE4EE5B@irridia.com>
On Fri, Dec 17, 2010 at 8:07 AM, Ken Brownfield <krb@irridia.com> wrote:
> cache_name_compare (and the presumed follow-ons of memcpy/sha/malloc/etc) is the major consumer.
Other people have given you alternative approaches. I'm just wondering
if we can improve something here. cache_name_compare() is essentially
memcmp() on two full paths. A tree-based index might help. How long
are your file names on average? Are your trees deep?
--
Duy
^ permalink raw reply
* [PATCH] Make rev-list --objects work together with pathspecs
From: Nguyễn Thái Ngọc Duy @ 2010-12-17 13:26 UTC (permalink / raw)
To: git, Elijah Newren, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
From: Elijah Newren <newren@gmail.com>
When traversing commits, the selection of commits would heed the list of
pathspecs passed, but subsequent walking of the trees of those commits
would not. This resulted in 'rev-list --objects HEAD -- <paths>'
displaying objects at unwanted paths.
Have process_tree() call tree_entry_interesting() to determine which paths
are interesting and should be walked.
Naturally, this change can provide a large speedup when paths are specified
together with --objects, since many tree entries are now correctly ignored.
Interestingly, though, this change also gives me a small (~1%) but
repeatable speedup even when no paths are specified with --objects.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Replacement for 1/2 of en/object-list-with-pathspec, on top of
nd/struct-pathspec v2 and followup patches.
Note that I dropped path_name() changes.
list-objects.c | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index 8953548..61f6cc9 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -61,12 +61,15 @@ static void process_tree(struct rev_info *revs,
struct tree *tree,
show_object_fn show,
struct name_path *path,
+ struct strbuf *base,
const char *name)
{
struct object *obj = &tree->object;
struct tree_desc desc;
struct name_entry entry;
struct name_path me;
+ int all_interesting = (revs->diffopt.pathspec.nr == 0);
+ int baselen = base->len;
if (!revs->tree_objects)
return;
@@ -82,13 +85,32 @@ static void process_tree(struct rev_info *revs,
me.elem = name;
me.elem_len = strlen(name);
+ if (!all_interesting) {
+ strbuf_addstr(base, name);
+ if (base->len)
+ strbuf_addch(base, '/');
+ }
+
init_tree_desc(&desc, tree->buffer, tree->size);
while (tree_entry(&desc, &entry)) {
+ if (!all_interesting) {
+ int showit = tree_entry_interesting(&entry,
+ base, 0,
+ &revs->diffopt.pathspec);
+
+ if (showit < 0)
+ break;
+ else if (!showit)
+ continue;
+ else if (showit == 2)
+ all_interesting = 1;
+ }
+
if (S_ISDIR(entry.mode))
process_tree(revs,
lookup_tree(entry.sha1),
- show, &me, entry.path);
+ show, &me, base, entry.path);
else if (S_ISGITLINK(entry.mode))
process_gitlink(revs, entry.sha1,
show, &me, entry.path);
@@ -97,6 +119,7 @@ static void process_tree(struct rev_info *revs,
lookup_blob(entry.sha1),
show, &me, entry.path);
}
+ strbuf_setlen(base, baselen);
free(tree->buffer);
tree->buffer = NULL;
}
@@ -146,7 +169,9 @@ void traverse_commit_list(struct rev_info *revs,
{
int i;
struct commit *commit;
+ struct strbuf base;
+ strbuf_init(&base, PATH_MAX);
while ((commit = get_revision(revs)) != NULL) {
add_pending_tree(revs, commit->tree);
show_commit(commit, data);
@@ -164,7 +189,7 @@ void traverse_commit_list(struct rev_info *revs,
}
if (obj->type == OBJ_TREE) {
process_tree(revs, (struct tree *)obj, show_object,
- NULL, name);
+ NULL, &base, name);
continue;
}
if (obj->type == OBJ_BLOB) {
@@ -181,4 +206,5 @@ void traverse_commit_list(struct rev_info *revs,
revs->pending.alloc = 0;
revs->pending.objects = NULL;
}
+ strbuf_release(&base);
}
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* Flattr for Git donations (was Re: [ANNOUNCE] Git in the SFC)
From: Bradley M. Kuhn @ 2010-12-17 13:09 UTC (permalink / raw)
To: kusmabite; +Cc: Jeff King, git, git
In-Reply-To: <AANLkTikB5eMLh0fZBBOjwAaAwxPnC-3hap28RCXNXa0y@mail.gmail.com>
Erik Faye-Lund wrote at 20:02 (EST) on Thursday:
> I see there's donation-buttons for google checkout and paypal. Would
> it be possible to donate through flattr also?
Yes, I've been looking into flattr in the last two weeks. I'm trying to
figure out a way for flattr to allow a "master account" so that each of
Conservancy's member projects can have its own and the funds all come to
Conservancy, properly routed for each project.
If Flattr doesn't support that 'master account' idea, what I'll do is
make a separate flattr account for each of Conservancy's member
projects. Hopefully, that can be done yet have all the banking
information be the same.
I'll experiment more with this over the weekend and into early next
week. I'll report to the Conservancy Git Committee (which is currently
Jeff, Junio, and Shawn) on what I discover and how we can make it work.
Anyway, I'll find a way to do it, one way or the other. Flattr has
become a very popular way to donate to FLOSS projects and Conservancy
therefore needs to support it.
BTW, to reiterate what Jeff mentioned in his post, if anyone ever has any
questions about Git's membership in Conservancy, just email
<git@sfconservancy.org>. That alias reaches both me and the Conservancy
Git Committee simultaneously.
--
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
^ permalink raw reply
* unable to resume git svn fetch
From: Justin Pitts @ 2010-12-17 14:28 UTC (permalink / raw)
To: git
Hello,
I am trying to import a SVN repo that I will be tracking for the foreseeable future.
The clone command was
git svn clone -T trunk -t tags -t release_tags -b branches -b private/branches $REPO
The fetch has been interrupted several times. Up until now I have had no problem resuming with git svn fetch.
Now, fetch fails on r9007 with
Incomplete data: Delta source ended unexpectedly at /opt/local/libexec/git-core/git-svn line 5117
I see some messages on the BUG mailing list regarding this error, but I get somewhat lost in the details of the repair and trying to understand how I might apply them to my scenario. Also,
git svn log
and
git svn reset -r9006
fail with
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
More detail from my shell session is at https://gist.github.com/79e08fe7551875f8bce9
This is git v1.7.3.3 on OSX v1.6.5 via MacPorts. I see that 1.7.3.4 is out, though not in MacPorts yet and nothing in the
release notes lead me to believe it would be useful, though I am certainly willing to do a source install if it is.
It was suggested in #git that I ought to limit the amount of history I am importing. I think that's a cop-out, but I'll listen to a reasoned argument why that opinion is wrong.
Thanks in advance,
Justin
^ permalink raw reply
* Re: [PATCH 14/21] Convert ce_path_match() to use struct pathspec
From: Junio C Hamano @ 2010-12-17 15:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTikKCU==mS5_TdqHstETj=CQ_deHMCJ4xW0r+Sck@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> I wonder if it makes more sense to change the type of revs->prune_data
>> from an array of pointers to strings to a pointer to struct pathspec.
>> Is there a downside?
>
> Converting a pointer to another pointer means mis typecasting can
> happen and the compiler won't help catching them.
You can rename the field at the same time, and the compiler will catch
anything you forgot to touch, no?
^ permalink raw reply
* Re: [PATCH 14/21] Convert ce_path_match() to use struct pathspec
From: Nguyen Thai Ngoc Duy @ 2010-12-17 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfwtwjv0f.fsf@alter.siamese.dyndns.org>
On Fri, Dec 17, 2010 at 10:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>>> I wonder if it makes more sense to change the type of revs->prune_data
>>> from an array of pointers to strings to a pointer to struct pathspec.
>>> Is there a downside?
>>
>> Converting a pointer to another pointer means mis typecasting can
>> happen and the compiler won't help catching them.
>
> You can rename the field at the same time, and the compiler will catch
> anything you forgot to touch, no?
>
Yes. I didn't think of that :(
--
Duy
^ permalink raw reply
* Re: conflict resolution of pd/bash-4-completion [Re: What's cooking in git.git (Dec 2010, #05; Thu, 16)]
From: Junio C Hamano @ 2010-12-17 19:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20101217111856.GA9304@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> On Thu, Dec 16, 2010 at 11:38:21PM -0800, Junio C Hamano wrote:
>> * pd/bash-4-completion (2010-12-15) 3 commits
>> - Merge branch 'master' (early part) into pd/bash-4-completion
>> - bash: simple reimplementation of _get_comp_words_by_ref
>> - bash: get --pretty=m<tab> completion to work with bash v4
>>
>> Updated by Jonathan; this still has some conflicts around "notes"
>> completion I tried to resolve near the tip of 'pu'.
>
> The resolution of that conflict is not quite correct. I'm not sure
> how I should send a proper conflict resolution... but I'll try
> anyway.
Thanks, this helped me quite a lot to update my rerere database, so that
the fix-up can be carried forward in future merges to 'next' and
eventually 'master'.
For anybody interested, here is how a merge fix-up patch like yours can be
used:
1. First apply to the commit it is intended to be applied:
$ git co pu
$ git am your-patch
2. Re-attempt the merge. CG stands for "Commit Goal".
$ CG=$(git rev-parse HEAD)
$ git reset --hard HEAD^^
$ git merge pd/bash-4-completion
3. Clear the rerere database and redo the merge, letting it conflict.
$ git rerere forget contrib/completion/git-completion.bash
$ git reset --hard
$ git merge pd/bash-4-completion
4. Take the fixup and conclude the merge; this updates the rerere
database.
$ git checkout $CG .
$ git commit
^ permalink raw reply
* Re: [PATCH 07/14] t7800-difftool.sh: Fix a test failure on Cygwin
From: Junio C Hamano @ 2010-12-17 19:59 UTC (permalink / raw)
To: David Aguilar; +Cc: Ramsay Jones, Junio C Hamano, GIT Mailing-list
In-Reply-To: <20101217023357.GA30083@gmail.com>
David Aguilar <davvid@gmail.com> writes:
>> diff --git a/git-difftool.perl b/git-difftool.perl
>> index e95e4ad..ced1615 100755
>> --- a/git-difftool.perl
>> +++ b/git-difftool.perl
>> @@ -52,6 +52,7 @@ sub generate_command
>> my @command = (exe('git'), 'diff');
>> my $skip_next = 0;
>> my $idx = -1;
>> + my $prompt = '';
>
> Would it be simpler to set $prompt = 1 and then
> flip it to 0 when -y | or --no-prompt is supplied?
> ...
>
> This would become:
>
> if ($prompt) {
> ...
> }
> else {
> ...
> }
But that is not what the patch does, is it?
Isn't it more like initializing $prompt to undef and then the above
condition becomes:
if (!defined $prompt) {
; # nothing
elsif ($prompt) {
setenv PROMPT true
} else {
setenv NO_PROMPT true
}
no?
^ permalink raw reply
* Re: [PATCH 10/21] tree_entry_interesting(): fix depth limit with overlapping pathspecs
From: Junio C Hamano @ 2010-12-17 20:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTi=4vnitj-U5M+V_ALVpAk0ncMG=09aAEqA=KD41@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2010/12/17 Junio C Hamano <gitster@pobox.com>:
>> One thing I am not clear is what it means to limit the recursion level
>> when you have wildcards.
>
> Recursion level does not affect wildcards at all. That was original
> design, a91f453 (grep: Add --max-depth option. - 2009-07-22). I think
> current git-grep still follows that.
I know what the current code does, as I remember a91f453 essentially
punted on coming up with a sane semantics. As this series under
discussion is about coming up with a unified and sane pathspec handling
across board, it would be a good opportunity to think about it again, this
time without punting so fast.
^ permalink raw reply
* Re: how to recover a repository
From: david @ 2010-12-17 20:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20101217044530.GA8590@burratino>
On Thu, 16 Dec 2010, Jonathan Nieder wrote:
> Hi David,
>
> david@lang.hm wrote:
>
>> I managed to do a 'rm *' in the .git directory (the usual sort of
>> fat-fingering when cleaning up after another mistake)
>>
>> the subdirectories are still there.
>
> I'd suggest:
>
> 1. Make a backup!
> 2. From the worktree (i.e. parent to the .git directory),
> run "git init".
> 3. git update-ref HEAD refs/heads/(branch you were on)
I was on the default branch but if I do 'git update-ref HEAD
refs/heads/master' I get an error 'not a valid SHA1'
.git/refs/heads is empty
.git/logs/HEAD looks like it shows all the commits in it properly
David Lang
> 4. git reset; # (alas, the old index file is gone)
> 5. git diff; gitk --all
>
> See gitrepository-layout(7) for details.
>
^ permalink raw reply
* Re: [PATCH 14/21] Convert ce_path_match() to use struct pathspec
From: Junio C Hamano @ 2010-12-17 20:29 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTinfzd8wOFTymVGeKH6cBg-6Ua6U+4N8x1TrQcHZ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Fri, Dec 17, 2010 at 10:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>
>>>> I wonder if it makes more sense to change the type of revs->prune_data
>>>> from an array of pointers to strings to a pointer to struct pathspec.
>>>> Is there a downside?
>>>
>>> Converting a pointer to another pointer means mis typecasting can
>>> happen and the compiler won't help catching them.
>>
>> You can rename the field at the same time, and the compiler will catch
>> anything you forgot to touch, no?
>>
> Yes. I didn't think of that :(
And it would have an added benefit that it would catch new callsites
somebody else added while being unaware of your conversion--the merge
result will not compile.
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Junio C Hamano @ 2010-12-17 20:44 UTC (permalink / raw)
To: Jeff King; +Cc: Martin von Zweigbergk, git, Junio C Hamano
In-Reply-To: <20101215130046.GB25647@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> All variables are case-insensitive. The config parser down-cases them,
> so all code should treat tham as all-lowercase. However, we tend to
> document them as camelCase for readability.
Careful. The second level of three-level names is supposed to be usable
for user defined names (e.g. names of branches and remotes) and I think
the completion code should not downcase it.
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Junio C Hamano @ 2010-12-17 20:52 UTC (permalink / raw)
To: Jeff King; +Cc: Martin von Zweigbergk, git
In-Reply-To: <20101216042304.GA886@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Dec 15, 2010 at 08:44:45PM +0100, Martin von Zweigbergk wrote:
>
>> > One note:
>> >
>> > > color.diff
>> > > color.diff.commit
>> > > color.diff.frag
>> > > + color.diff.func
>> > > color.diff.meta
>> > > color.diff.new
>> > > color.diff.old
>> > > color.diff.plain
>> > > color.diff.whitespace
>> >
>> > We have color.diff.branch coming soon (I think it is in 'next' now).
>
> The "correct" thing to do from a topic branch standpoint is to submit
> this patch without it as its own topic, submit a patch with just
> color.diff.branch on top of the other topic, and then the merge
> resolution will include both sets.
Perhaps, if we had color.diff.branch ;-).
> In this case, it might be OK to just start shipping color.diff.branch in
> the completion list. It doesn't hurt anything to have the extra
> completion before the feature is in, and the feature seems very likely
> to make it in soon.
>
> But I'll let Junio decide how meticulous about history he wants to be.
Well, in this case, probably the right thing to do is to ignore this
addition to completion as the lowest priority item for now, wait for other
changes that add or modify the set of configuration variables to land on
'master', and then resubmit a single patch.
Yes, merge is wonderful and easy, but it is merely a tool to help
coordination between developers (the ones who add code to understand new
variables, the others who add completion to help spell the new variables),
not a replacement. And orderly submission of patches that are related and
have dependencies is a prime example of such coordination.
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Jeff King @ 2010-12-17 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git
In-Reply-To: <7v7hf8i0lk.fsf@alter.siamese.dyndns.org>
On Fri, Dec 17, 2010 at 12:52:07PM -0800, Junio C Hamano wrote:
> >> > We have color.diff.branch coming soon (I think it is in 'next' now).
> >
> > The "correct" thing to do from a topic branch standpoint is to submit
> > this patch without it as its own topic, submit a patch with just
> > color.diff.branch on top of the other topic, and then the merge
> > resolution will include both sets.
>
> Perhaps, if we had color.diff.branch ;-).
Urgh. Color.status.branch is what I meant all along.
> >
> > But I'll let Junio decide how meticulous about history he wants to be.
>
> Well, in this case, probably the right thing to do is to ignore this
> addition to completion as the lowest priority item for now, wait for other
> changes that add or modify the set of configuration variables to land on
> 'master', and then resubmit a single patch.
Sure, that is reasonable to me.
> Yes, merge is wonderful and easy, but it is merely a tool to help
> coordination between developers (the ones who add code to understand new
> variables, the others who add completion to help spell the new variables),
> not a replacement. And orderly submission of patches that are related and
> have dependencies is a prime example of such coordination.
Well, yes. But on the other hand, they are two totally separate topics;
they just happen to both have a component of "add stuff to config
completion". And don't you always preach about not holding one topic
hostage by introducing an unnecessary dependency on another?
I don't think it is a huge deal in this case, but Martin's patch could
theoretically be "maint" material (I say theoretically because I didn't
actually check whether any of the added completions were for things not
yet in maint). Basing it on something in "next", even if you wait until
it's in "master", makes that impossible.
But this is all philosphical wankery. I think any of the solutions is
fine.
-Peff
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Jeff King @ 2010-12-17 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git
In-Reply-To: <7vei9gi0y3.fsf@alter.siamese.dyndns.org>
On Fri, Dec 17, 2010 at 12:44:36PM -0800, Junio C Hamano wrote:
> > All variables are case-insensitive. The config parser down-cases them,
> > so all code should treat tham as all-lowercase. However, we tend to
> > document them as camelCase for readability.
>
> Careful. The second level of three-level names is supposed to be usable
> for user defined names (e.g. names of branches and remotes) and I think
> the completion code should not downcase it.
Yeah, good point. It is not even "second level" in the parsing code,
though, since that code sees:
[first "second"]
third
and not
first.second.third
IOW, the second one is ambiguous in the face of an internal dot. So if
I had something like:
[Foo "Bar.Baz"]
Bleep = true
then "Foo" and "Bleep" are case-insensitive, but both "Bar" and "Baz"
are not. So in terms of dotted components, the rule is "the first and
last dotted components are case-insensitive, and middle ones are
case-sensitive". At least with respect to my simple test of calling "git
config x.y.z". I'm afraid if I look too deeply I might discover some
inconsistency. :)
-Peff
^ permalink raw reply
* Re: how to recover a repository
From: Jeff King @ 2010-12-17 21:22 UTC (permalink / raw)
To: david; +Cc: Jonathan Nieder, git
In-Reply-To: <alpine.DEB.2.00.1012171218450.18272@asgard.lang.hm>
On Fri, Dec 17, 2010 at 12:20:56PM -0800, david@lang.hm wrote:
> >3. git update-ref HEAD refs/heads/(branch you were on)
>
> I was on the default branch but if I do 'git update-ref HEAD
> refs/heads/master' I get an error 'not a valid SHA1'
That should be "git symbolic-ref HEAD refs/heads/master".
-Peff
^ permalink raw reply
* Re: [PATCH 08/14] help.c: Fix detection of custom merge strategy on cygwin
From: Johannes Sixt @ 2010-12-17 21:46 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, jrnieder, vmiklos
In-Reply-To: <4D0A80C5.4020003@ramsay1.demon.co.uk>
On Donnerstag, 16. Dezember 2010, Ramsay Jones wrote:
> Johannes Sixt wrote:
> > On Dienstag, 14. Dezember 2010, Ramsay Jones wrote:
> >> @@ -126,7 +126,10 @@ static int is_executable(const char *name)
> >> !S_ISREG(st.st_mode))
> >> return 0;
> >>
> >> -#ifdef WIN32
> >> +#if defined(WIN32) || defined(__CYGWIN__)
> >> +#if defined(__CYGWIN__)
> >> +if ((st.st_mode & S_IXUSR) == 0)
> >> +#endif
> >> { /* cannot trust the executable bit, peek into the file instead */
> >> char buf[3] = { 0 };
> >> int n;
> >
> > Do you gain a lot by this extra condition? Wouldn't
> >
> > -#ifdef WIN32
> > +#if defined(WIN32) || defined(__CYGWIN__)
> >
> > be sufficient?
>
> Yes, that would be sufficient. No, I probably don't gain a great deal
> (but I have *not* timed it), since the number of files that are tested
> by is_executable() is fairly low anyway since they are already filtered
> by a filename prefix (eg. git-merge-).
>
> However, if the executable bit is set, then executing the WIN32 code
> block is wasted effort (we already know the answer), so why bother?
It would have made to code a bit easier to read with one less #if defined(),
but it's not a big deal.
-- Hannes
^ permalink raw reply
* Re: [PATCH 13/14] t4135-*.sh: Skip the "backslash" tests on cygwin
From: Johannes Sixt @ 2010-12-17 21:54 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, jrnieder
In-Reply-To: <4D0A94D8.6090206@ramsay1.demon.co.uk>
On Donnerstag, 16. Dezember 2010, Ramsay Jones wrote:
> Johannes Sixt wrote:
> > On Dienstag, 14. Dezember 2010, Ramsay Jones wrote:
> >> Note t3700-*.sh has a test protected by BSLASHSPEC which
> >> previously passed on cygwin and will now be (unnecessarily)
> >> skipped. This test needs to be skipped on MinGW, given how
> >> it is written; if you remove the single quotes around the
> >> filename, however, it will pass even on MinGW.
> >
> > That is suspicious. It would mean that git add does not do file globbing
> > anymore. Should it or should it not do file globbing?
>
> Hmm, something like "git add 'a.[ch]'" works just fine. The problems
> occur when you back-quote the metachars like "git add 'a.\[ch\]'".
>
> The test is skipped on MinGW, because of BSLASHSPEC. The test is now
> skipped on cygwin, after this patch, even though it passes on cygwin.
> BSLASHSPEC is, apparently, used for both a '\' in a filename and for
> a "\-quoting". (Perhaps it should be split into two prerequisites)
>
> The difference in behaviour between cygwin and MinGW (& msvc) is easy
> to trace, thus:
>
> cmd_add()
> =>validate_pathspec() builtin/add.c:435
> =>get_pathspec() builtin/add.c:216
> =>prefix_path() setup.c:147
> =>normalize_path_copy() setup.c:18
> =>is_dir_sep()
>
> on cygwin is_dir_sep() is defined thus:
>
> git-compat-util.h:208:#define is_dir_sep(c) ((c) == '/')
>
> where on MinGW it is defined thus:
>
> compat/mingw.h:291:#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
>
> So, on entry to git-add the pathspec (in argv[1]) is
> fo\[ou\]bar
> On return from validate_pathspec(), on cygwin it is *still*
> fo\[ou\]bar
> but on MinGW (and msvc), it is now
> fo/[ou/]bar
>
> and everything follows from there. (So for example, on cygwin, match_one()
> matches fo\[ou\]bar with fo[ou]bar, but not with foobar.)
Yes, that's clear, and this is the reason that we must skip this test on
MinGW.
But you said that when the single quotes are removed, the test passes (and you
are right). Then git-add sees this pathspec/pattern:
fo[ou]bar
and it matches 'foobar' when it interprets that as a pattern, but 'fo[ou]bar'
when it interprets that as straight file name. Even on Linux, the latter
happens, and *that* is suspicious. What am I missing?
-- Hannes
^ permalink raw reply
* Re: how to recover a repository
From: david @ 2010-12-17 22:30 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git
In-Reply-To: <20101217212201.GC11511@sigill.intra.peff.net>
thanks, that appears to have worked.
David Lang
On Fri, 17 Dec 2010, Jeff King wrote:
> Date: Fri, 17 Dec 2010 16:22:02 -0500
> From: Jeff King <peff@peff.net>
> To: david@lang.hm
> Cc: Jonathan Nieder <jrnieder@gmail.com>, git@vger.kernel.org
> Subject: Re: how to recover a repository
>
> On Fri, Dec 17, 2010 at 12:20:56PM -0800, david@lang.hm wrote:
>
>>> 3. git update-ref HEAD refs/heads/(branch you were on)
>>
>> I was on the default branch but if I do 'git update-ref HEAD
>> refs/heads/master' I get an error 'not a valid SHA1'
>
> That should be "git symbolic-ref HEAD refs/heads/master".
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH 10/21] tree_entry_interesting(): fix depth limit with overlapping pathspecs
From: Nguyen Thai Ngoc Duy @ 2010-12-18 3:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxo5l2g4.fsf@alter.siamese.dyndns.org>
2010/12/17 Junio C Hamano <gitster@pobox.com>:
> One possible definition of interaction between limit and wildcard may be
> to count the number of slashes in the part of the path that matches the
> wildcarded part of the pathspec, add the number of path components
> appended due to the leading directory match, and then subtract the number
> of literal slashes in the wildcarded part of the pattern from the above,
> and declare that a match is found if the difference is less than the
> limit.
>
> E.g. a pathspec element "a/*/x" would match "a/b/c/x", "a/b/c/d/e/x",
> "a/b/x/y" and "a/b/x/y/z" without limit, and with the limit of 1:
>
> a/b/c/x matches ('*' expands to "b/c")
> a/b/c/d/e/x no ('*' has to expand to "c/d/e" and needs 2 levels)
> a/b/x/y matches ('*' expands to "b" costing zero, "/y" needs 1)
> a/b/x/y/z does not match
>
> Another definition could be to count _only_ the part that is appended by
> recursion (i.e. we do not count how many slashes has to match '*' in the
> above examples), and as the option is called --depth, it might make more
> sense.
So with the above example, "a/" won't be counted. Depth limit of 0 or
1 will result in no matches. Depth limit of 2 will result in a/b/c/x
and a/b/x/y, correct?
I prefer this definition to the former. It sounds simpler to
understand and use, also less computation. But I can implement both
:-) We can mark what matching strategy we would use in struct
pathspec. Hmm.. I'm not much help in figuring out which one makes
more sense.
Another thing, I don't know if anybody would need it. Should we
support depth limit per pathspec, so "a/*/x" can have depth limit of
2, but "*.c" has depth limit of 1..For one thing, his may help keeping
current's git-grep depth limit behavior if depth limit can also be
applied to wildcard pathspecs by setting depth limit for wildcard
pathspecs to -1. Exposing depth limit per pathspec to users is another
matter.
> In either case, I am not sure if "if it matches the longest pathspec, we
> have the answer without looking at shorter ones" would be a good rule to
> use.
As long as the rule of matching is "if any of these pathspecs is
matched, we have a match", then pathspec order should not matter
(without depth limit). Matching decision of one pathspec does not
affect the others. Depth limit is the first one breaking the last
sentence. And because pathspec order does not matter before depth
limit introduction, it should not cause any regression when depth
limit requires pathspecs in certain order. That's how I thought when I
decided to sort pathspecs.
Wildcard pathspecs are handled in a completely different path (even
with depth limit in either way you described). Overlapping is no issue
to wildcard pathspecs, we always need full pathspec to call fnmatch()
(unless you implied some early cut optmization that I don't see).
Therefore pathspec order is no issue.
Even when I introduce negative pathspec, it would be actually negative
prefix and go the same route as current depth limit impl (it also has
the same overlapping pathspec issue). Negative wildcard pathspecs
would blow my mind.
--
Duy
^ permalink raw reply
* [PATCHv2 0/8] docs: use metavariables consistently
From: Mark Lodato @ 2010-12-18 5:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Mark Lodato
Update the documentation and usage statements to use metavariables, such as
<commit>, more consistently. The biggest change is to drop the <tree-ish> and
<commit-ish> (or <committish>) notation and just use <tree> or <commit>, since
every command but commit-tree accepts tree-ishes and commit-ishes. The "-ish"
terms are still kept around in various places where it makes sense to
differentiate between an actual tree or commit and a tree-ish or commit-ish.
This is a rework of my earlier patch set from March [1], with the following
differences:
- Drop the patch to commit-tree that makes it accept a tree-ish.
- Drop the patch dealing with <tag> and <tagname>.
- Leave -ish terms in comments and in places where they make sense.
- Rebase onto master (1b97434). Some of the patches from before have since
been accepted from other authors.
- Fix a problem that Junio noticed with the "grep docs" patch.
[1] http://kerneltrap.org/mailarchive/git/2010/3/13/25484
Mark Lodato (8):
fsck docs: remove outdated and useless diagnostic
docs: use `...' instead of `*' for multiplicity
docs: use <sha1> to mean unabbreviated ID
http-fetch docs: use <commit-id> consistently
grep docs: grep accepts a <tree-ish>, not a <tree>
docs: use <tree> instead of <tree-ish>
docs: use <commit> instead of <commit-ish>
describe docs: note that <commit> is optional
Documentation/RelNotes/1.6.2.4.txt | 2 +-
Documentation/diff-format.txt | 10 +++++-----
Documentation/diff-generate-patch.txt | 2 +-
Documentation/git-archive.txt | 4 ++--
Documentation/git-cat-file.txt | 2 +-
Documentation/git-checkout.txt | 16 ++++++++--------
Documentation/git-commit-tree.txt | 3 ++-
Documentation/git-describe.txt | 15 ++++++++-------
Documentation/git-diff-index.txt | 4 ++--
Documentation/git-diff-tree.txt | 18 +++++++++---------
Documentation/git-fast-import.txt | 22 +++++++++++-----------
Documentation/git-fsck.txt | 5 +----
Documentation/git-http-fetch.txt | 4 ++--
Documentation/git-ls-files.txt | 6 +++---
Documentation/git-ls-tree.txt | 6 +++---
Documentation/git-merge-index.txt | 2 +-
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-name-rev.txt | 2 +-
Documentation/git-read-tree.txt | 10 +++++-----
Documentation/git-rebase.txt | 2 +-
Documentation/git-svn.txt | 6 +++---
Documentation/git-tar-tree.txt | 4 ++--
Documentation/git.txt | 27 +++++++++++++--------------
Documentation/gitcli.txt | 6 +++---
Documentation/gittutorial-2.txt | 6 ++----
Documentation/glossary-content.txt | 4 ++++
archive.c | 4 ++--
builtin/commit-tree.c | 2 +-
builtin/describe.c | 4 ++--
builtin/diff-index.c | 2 +-
builtin/diff-tree.c | 2 +-
builtin/ls-files.c | 4 ++--
builtin/ls-tree.c | 2 +-
builtin/merge-index.c | 2 +-
builtin/read-tree.c | 2 +-
builtin/revert.c | 4 ++--
builtin/tar-tree.c | 2 +-
contrib/examples/git-reset.sh | 2 +-
contrib/examples/git-revert.sh | 4 ++--
git-svn.perl | 6 +++---
t/t4100/t-apply-3.patch | 8 ++++----
t/t4100/t-apply-7.patch | 8 ++++----
42 files changed, 124 insertions(+), 124 deletions(-)
--
1.7.3.2
^ permalink raw reply
* [PATCH 2/8] docs: use `...' instead of `*' for multiplicity
From: Mark Lodato @ 2010-12-18 5:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Mark Lodato
In-Reply-To: <1292650725-21149-1-git-send-email-lodatom@gmail.com>
Finish the work of 0adda93 (Use parentheses and `...' where appropriate)
to follow the rules set forth in Documentation/CodingGuidelines.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-fsck.txt | 2 +-
Documentation/git-merge-index.txt | 2 +-
Documentation/gitcli.txt | 2 +-
builtin/describe.c | 2 +-
builtin/merge-index.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 86f9b2b..38207a1 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>...]
DESCRIPTION
-----------
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 921b38f..3716309 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -8,7 +8,7 @@ git-merge-index - Run a merge for files needing merging
SYNOPSIS
--------
-'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>*)
+'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>...)
DESCRIPTION
-----------
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 6928724..eb65dcf 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -81,7 +81,7 @@ couple of magic command line options:
+
---------------------------------------------
$ git describe -h
-usage: git describe [options] <committish>*
+usage: git describe [options] <committish>...
--contains find the tag that comes after the commit
--debug debug search strategy on stderr
diff --git a/builtin/describe.c b/builtin/describe.c
index a0f52c1..34a8031 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -12,7 +12,7 @@
#define MAX_TAGS (FLAG_BITS - 1)
static const char * const describe_usage[] = {
- "git describe [options] <committish>*",
+ "git describe [options] <committish>...",
"git describe [options] --dirty",
NULL
};
diff --git a/builtin/merge-index.c b/builtin/merge-index.c
index 2c4cf5e..c683bbd 100644
--- a/builtin/merge-index.c
+++ b/builtin/merge-index.c
@@ -76,7 +76,7 @@ int cmd_merge_index(int argc, const char **argv, const char *prefix)
signal(SIGCHLD, SIG_DFL);
if (argc < 3)
- usage("git merge-index [-o] [-q] <merge-program> (-a | [--] <filename>*)");
+ usage("git merge-index [-o] [-q] <merge-program> (-a | [--] <filename>...)");
read_cache();
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/8] fsck docs: remove outdated and useless diagnostic
From: Mark Lodato @ 2010-12-18 5:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Mark Lodato
In-Reply-To: <1292650725-21149-1-git-send-email-lodatom@gmail.com>
In git-fsck(1), there was a reference to the warning "<tree> has full
pathnames in it". This exact wording has not been used since 2005
(commit f1f0d0889e55), when the wording was changed slightly. More
importantly, the description of that warning was useless, and there were
many other similar warning messages which were not document at all.
Since all these warnings are fairly obvious, there is no need for them
to be in the man page.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
---
Documentation/git-fsck.txt | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 3ad48a6..86f9b2b 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -123,9 +123,6 @@ dangling <type> <object>::
The <type> object <object>, is present in the database but never
'directly' used. A dangling commit could be a root node.
-warning: git-fsck: tree <tree> has full pathnames in it::
- And it shouldn't...
-
sha1 mismatch <object>::
The database has an object who's sha1 doesn't match the
database value.
--
1.7.3.2
^ 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