Commits gone AWOL, but not reported by git-fsck --unreachable

Commits gone AWOL, but not reported by git-fsck --unreachable

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

Background:
-----------
Using git-svn to work with an external project (non-public), and the
other day I happened to run 'git-svn dcommit' right as their SVN went
down for a moment (under 5 seconds) for the snapshot-backup. I recall
swearing profusely at the time, but thought nothing of it after that,
until now, when I saw that parts of my tree weren't as they should be.

Problem:
--------
A bunch of my commits are NOT present in git-log, git-rev-list, or any
tool that provides the history of my branches.

If I hack around and recover the commitid, I can pass it to git-show,
and the commit does still exist in the data.

git-fsck --unreachable does not list the commit in question either, but
does list other blobs and trees.

Luckily, since the entire tree had ~900 commits, I was able to work some
magic and recovery my work:
1. Hack to get list of all commits
2. Exclude all commits that had git-svn-id in their description.
3. Exclude all merges.
4. Manually review all remaining commits (~70).

The following questions are mainly things that would have made my
recovery far easier.

Questions:
----------
1. Is there a plumbing tool to list EVERY single object of a given type
   (blob, tree, commit, tag) that git is aware of, regardless of it
   being reachable? (Right now I have a hack to read the pack index, and
   use find to find the non-packed object ids, then git-cat-file -t for
   the type).
2. A sane way to view an ordered set of commits, so that it should be
   possible to spot when there's a path of commits that went off and
   isn't used anymore.
3. Given a set of commits, list which are actually unique (in my tree,
   git-svn uses rebase often, so I have a lot of commits that are
   identical bar the commitid).
4. Strongly related to #4, given everything a commit, tell me what other
   identical commits exist in the tree.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Jeff King]

On Sat, May 19, 2007 at 03:30:11AM -0700, Robin H. Johnson wrote:

> Problem:
> --------
> A bunch of my commits are NOT present in git-log, git-rev-list, or any
> tool that provides the history of my branches.
> 
> If I hack around and recover the commitid, I can pass it to git-show,
> and the commit does still exist in the data.
> 
> git-fsck --unreachable does not list the commit in question either, but
> does list other blobs and trees.

Are you sure it isn't in your reflog? Try 'git reflog show' or 'git log
-g'.

-Peff

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

On Sat, May 19, 2007 at 07:52:45AM -0400, Jeff King wrote:
> On Sat, May 19, 2007 at 03:30:11AM -0700, Robin H. Johnson wrote:
> > Problem:
> > --------
> > A bunch of my commits are NOT present in git-log, git-rev-list, or any
> > tool that provides the history of my branches.
> > 
> > If I hack around and recover the commitid, I can pass it to git-show,
> > and the commit does still exist in the data.
> > 
> > git-fsck --unreachable does not list the commit in question either, but
> > does list other blobs and trees.
> Are you sure it isn't in your reflog? Try 'git reflog show' or 'git log
> -g'.
Ahh, they do show up there (and I learnt a new git command now, thanks)
- the ones that I can remember the Subject lines for anyway.

Any hints for the future on finding stuff that is in the reflog but not
in the tree? (Remembering every subject line isn't feasible).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Jeff King]

On Sat, May 19, 2007 at 05:09:33AM -0700, Robin H. Johnson wrote:

> Ahh, they do show up there (and I learnt a new git command now, thanks)
> - the ones that I can remember the Subject lines for anyway.
> 
> Any hints for the future on finding stuff that is in the reflog but not
> in the tree? (Remembering every subject line isn't feasible).

Try 'git-fsck --unreachable --no-reflogs'. :)

-Peff

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Anand Kumria]

On Sat, 19 May 2007 08:11:54 -0400, Jeff King wrote:

> On Sat, May 19, 2007 at 05:09:33AM -0700, Robin H. Johnson wrote:
> 
>> Ahh, they do show up there (and I learnt a new git command now, thanks)
>> - the ones that I can remember the Subject lines for anyway.
>> 
>> Any hints for the future on finding stuff that is in the reflog but not
>> in the tree? (Remembering every subject line isn't feasible).
> 
> Try 'git-fsck --unreachable --no-reflogs'. :)

What version? git 1.5.1.4 doesn't seem to have that.

Anand

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Matthieu Moy]

Anand Kumria <wildfire@progsoc.org> writes:

> On Sat, 19 May 2007 08:11:54 -0400, Jeff King wrote:
>
>> On Sat, May 19, 2007 at 05:09:33AM -0700, Robin H. Johnson wrote:
>> 
>>> Ahh, they do show up there (and I learnt a new git command now, thanks)
>>> - the ones that I can remember the Subject lines for anyway.
>>> 
>>> Any hints for the future on finding stuff that is in the reflog but not
>>> in the tree? (Remembering every subject line isn't feasible).
>> 
>> Try 'git-fsck --unreachable --no-reflogs'. :)
>
> What version? git 1.5.1.4 doesn't seem to have that.

The commit introducing it is 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
and I'd say it's in git 1.5.1:

$ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b                                                                                     
v1.5.1-34-g566842f

-- 
Matthieu

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Brian Gernhardt]

On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:

> The commit introducing it is 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
> and I'd say it's in git 1.5.1:
>
> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
> v1.5.1-34-g566842f

Actually, I think that means it's 34 commits *after* v1.5.1, not  
before.  It's in 1.5.2-rc0, but none of the 1.5.1.* series.

~~ Brian

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Matthieu Moy]

Brian Gernhardt <benji@silverinsanity.com> writes:

> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>
>> The commit introducing it is 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>> and I'd say it's in git 1.5.1:
>>
>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>> v1.5.1-34-g566842f
>
> Actually, I think that means it's 34 commits *after* v1.5.1, not
> before.  It's in 1.5.2-rc0, but none of the 1.5.1.* series.

You're right. Then, is there any easy way to ask git the oldest tag(s)
that a commit is an ancestor of? In other words, which command should
I have typed above?

-- 
Matthieu

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Brian Gernhardt]

On May 19, 2007, at 12:55 PM, Matthieu Moy wrote:

> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>>
>>> The commit introducing it is  
>>> 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>>> and I'd say it's in git 1.5.1:
>>>
>>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>>> v1.5.1-34-g566842f
>>
>> Actually, I think that means it's 34 commits *after* v1.5.1, not
>> before.  It's in 1.5.2-rc0, but none of the 1.5.1.* series.
>
> You're right. Then, is there any easy way to ask git the oldest tag(s)
> that a commit is an ancestor of? In other words, which command should
> I have typed above?

I did it the hard way with "git log v1.5.1..v.1.5.1.1", "..1.5.1.2",  
and using grep to look for 566842.  Anybody better at constructing  
these incantations want to chime in?

~~ Brian

Re: Commits gone AWOL, but not reported by git-fsck --unreachable

[Junio C Hamano]

Brian Gernhardt <benji@silverinsanity.com> writes:

> On May 19, 2007, at 12:55 PM, Matthieu Moy wrote:
>
>> Brian Gernhardt <benji@silverinsanity.com> writes:
>>
>>> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>>>
>>>> The commit introducing it is
>>>> 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>>>> and I'd say it's in git 1.5.1:
>>>>
>>>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>>>> v1.5.1-34-g566842f
>>>
>>> Actually, I think that means it's 34 commits *after* v1.5.1, not
>>> before.  It's in 1.5.2-rc0, but none of the 1.5.1.* series.
>>
>> You're right. Then, is there any easy way to ask git the oldest tag(s)
>> that a commit is an ancestor of? In other words, which command should
>> I have typed above?
>
> I did it the hard way with "git log v1.5.1..v.1.5.1.1", "..1.5.1.2",
> and using grep to look for 566842.  Anybody better at constructing
> these incantations want to chime in?

Perhaps "git-name-rev --refs='refs/tags/v*' $it"?

[PATCH] Cross-reference the manpages for git-name-rev and git-describe (was Re: Commits gone AWOL, but not reported by git-fsck --unreachable)

[Matthieu Moy]

Junio C Hamano <junkio@cox.net> writes:

> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> On May 19, 2007, at 12:55 PM, Matthieu Moy wrote:
>>
>>> Brian Gernhardt <benji@silverinsanity.com> writes:
>>>
>>>> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>>>>
>>>>> The commit introducing it is
>>>>> 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>>>>> and I'd say it's in git 1.5.1:
>>>>>
>>>>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>>>>> v1.5.1-34-g566842f
>>>>
>>>> Actually, I think that means it's 34 commits *after* v1.5.1, not
>>>> before.  It's in 1.5.2-rc0, but none of the 1.5.1.* series.
>>>
>>> You're right. Then, is there any easy way to ask git the oldest tag(s)
>>> that a commit is an ancestor of? In other words, which command should
>>> I have typed above?
>>
>> I did it the hard way with "git log v1.5.1..v.1.5.1.1", "..1.5.1.2",
>> and using grep to look for 566842.  Anybody better at constructing
>> these incantations want to chime in?
>
> Perhaps "git-name-rev --refs='refs/tags/v*' $it"?

Yes, that's the one I was looking for (I knew it, but mixed name-rev
and describe).

How about this documentation patch then?


>From c280d7db974faacf388314e0396c9d50b40d55aa Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Sun, 20 May 2007 14:33:44 +0200
Subject: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

Both commands achieve a very similar goal.
---
 Documentation/git-describe.txt |    4 ++++
 Documentation/git-name-rev.txt |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 47a583d..ff8383d 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -105,6 +105,10 @@ selected and output.  Here fewest commits different is defined as
 the number of commits which would be shown by "git log tag..input"
 will be the smallest number of commits possible.
 
+See Also
+--------
+gitlink:git-name-rev[1] (very similar to git-describe, but searches
+the succesors of the commit)
 
 Author
 ------
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index d6c8bf8..bdb0b27 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -57,6 +57,10 @@ Another nice thing you can do is:
 % git log | git name-rev --stdin
 ------------
 
+See Also
+--------
+gitlink:git-describe[1] (very similar to git-name-rev, but searches
+the ancestors of the commit)
 
 Author
 ------
-- 
1.5.2.rc3.32.ga3b1



-- 
Matthieu

Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> wouldn't this be useful?
> 
> $ git-describe --contains --tags 1b600e659
> v1.5.0-rc3~34

Like this?  ;-)

-->8--
Teach git-describe how to run name-rev

Often users want to know not which tagged version a commit came
after, but which tagged version a commit is contained within.
This latter task is the job of git-name-rev, but most users are
looking to git-describe to do the job.

Junio suggested we make `git describe --contains` run the correct
tool, `git name-rev`, and that's exactly what we do here.  The output
of name-rev was adjusted slightly through the new --name-only option,
allowing describe to execv into name-rev and maintain its current
output format.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/git-describe.txt |    7 ++++++-
 Documentation/git-name-rev.txt |    7 +++++++
 builtin-describe.c             |   15 +++++++++++++++
 builtin-name-rev.c             |   23 +++++++++++++++++------
 4 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 47a583d..dc47b65 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
 
 SYNOPSIS
 --------
-'git-describe' [--all] [--tags] [--abbrev=<n>] <committish>...
+'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
 
 DESCRIPTION
 -----------
@@ -31,6 +31,11 @@ OPTIONS
 	Instead of using only the annotated tags, use any tag
 	found in `.git/refs/tags`.
 
+--contains::
+	Instead of finding the tag that predates the commit, find
+	the tag that comes after the commit, and thus contains it.
+	Automatically implies --tags.
+
 --abbrev=<n>::
 	Instead of using the default 8 hexadecimal digits as the
 	abbreviated object name, use <n> digits.
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index d6c8bf8..9a1645d 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -34,6 +34,13 @@ OPTIONS
 	Read from stdin, append "(<rev_name>)" to all sha1's of nameable
 	commits, and pass to stdout
 
+--name-only::
+	Instead of printing both the SHA-1 and the name, print only
+	the name.  If given with --tags the usual tag prefix of
+	"tags/" is also ommitted from the name, matching the output
+	of gitlink::git-describe[1] more closely.  This option
+	cannot be combined with --stdin.
+
 EXAMPLE
 -------
 
diff --git a/builtin-describe.c b/builtin-describe.c
index 165917e..efbd43f 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -3,6 +3,7 @@
 #include "tag.h"
 #include "refs.h"
 #include "builtin.h"
+#include "exec_cmd.h"
 
 #define SEEN		(1u<<0)
 #define MAX_TAGS	(FLAG_BITS - 1)
@@ -242,12 +243,15 @@ static void describe(const char *arg, int last_one)
 int cmd_describe(int argc, const char **argv, const char *prefix)
 {
 	int i;
+	int contains = 0;
 
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 
 		if (*arg != '-')
 			break;
+		else if (!strcmp(arg, "--contains"))
+			contains = 1;
 		else if (!strcmp(arg, "--debug"))
 			debug = 1;
 		else if (!strcmp(arg, "--all"))
@@ -272,6 +276,17 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
 
 	save_commit_buffer = 0;
 
+	if (contains) {
+		const char **nr = xmalloc((4 + argc - i) * sizeof(char*));
+		nr[0] = "name-rev";
+		nr[1] = "--name-only";
+		nr[2] = "--tags";
+		memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
+		nr[3 + argc - i] = NULL;
+		execv_git_cmd(nr);
+		die("unable to start %s", nr[0]);
+	}
+
 	if (argc <= i)
 		describe("HEAD", 1);
 	else
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index ef16385..a639e2f 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -83,6 +83,7 @@ copy_data:
 
 struct name_ref_data {
 	int tags_only;
+	int name_only;
 	const char *ref_filter;
 };
 
@@ -110,6 +111,10 @@ static int name_ref(const char *path, const unsigned char *sha1, int flags, void
 
 		if (!prefixcmp(path, "refs/heads/"))
 			path = path + 11;
+		else if (data->tags_only
+		    && data->name_only
+		    && !prefixcmp(path, "refs/tags/"))
+			path = path + 10;
 		else if (!prefixcmp(path, "refs/"))
 			path = path + 5;
 
@@ -149,7 +154,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
 {
 	struct object_array revs = { 0, 0, NULL };
 	int as_is = 0, all = 0, transform_stdin = 0;
-	struct name_ref_data data = { 0, NULL };
+	struct name_ref_data data = { 0, 0, NULL };
 
 	git_config(git_default_config);
 
@@ -165,6 +170,9 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
 			if (!strcmp(*argv, "--")) {
 				as_is = 1;
 				continue;
+			} else if (!strcmp(*argv, "--name-only")) {
+				data.name_only = 1;
+				continue;
 			} else if (!strcmp(*argv, "--tags")) {
 				data.tags_only = 1;
 				continue;
@@ -263,14 +271,17 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
 			struct object * obj = get_indexed_object(i);
 			if (!obj)
 				continue;
-			printf("%s %s\n", sha1_to_hex(obj->sha1), get_rev_name(obj));
+			if (!data.name_only)
+				printf("%s ", sha1_to_hex(obj->sha1));
+			printf("%s\n", get_rev_name(obj));
 		}
 	} else {
 		int i;
-		for (i = 0; i < revs.nr; i++)
-			printf("%s %s\n",
-				revs.objects[i].name,
-				get_rev_name(revs.objects[i].item));
+		for (i = 0; i < revs.nr; i++) {
+			if (!data.name_only)
+				printf("%s ", revs.objects[i].name);
+			printf("%s\n", get_rev_name(revs.objects[i].item));
+		}
 	}
 
 	return 0;
-- 
1.5.2.14.g45bde-dirty

-- 
Shawn.

Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> wouldn't this be useful?
>> 
>> $ git-describe --contains --tags 1b600e659
>> v1.5.0-rc3~34
>
> Like this?  ;-)

Yeah, something like that.

Now we need to make sure that the name of the option --contains
is sane, I guess.

Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> > Junio C Hamano <junkio@cox.net> wrote:
> >> wouldn't this be useful?
> >> 
> >> $ git-describe --contains --tags 1b600e659
> >> v1.5.0-rc3~34
> 
> Now we need to make sure that the name of the option --contains
> is sane, I guess.

I think its sane.  I wanted to do a --contains option to describe
a while back, for this reason, but just didn't get around to it.
You also suggested it.  Looks like at least two people came up with
that option independently.  That's not too bad.

Feel free to edit the patch if something else better comes up.

-- 
Shawn.

Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

[Matthieu Moy]

Junio C Hamano <junkio@cox.net> writes:

> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Junio C Hamano <junkio@cox.net> wrote:
>>> wouldn't this be useful?
>>> 
>>> $ git-describe --contains --tags 1b600e659
>>> v1.5.0-rc3~34

[ I didn't receive this message, and gmane doesn't seem to have it.
  Strange ]

>> Like this?  ;-)
>
> Yeah, something like that.
>
> Now we need to make sure that the name of the option --contains
> is sane, I guess.

It seems OK to me. Perhaps --forward (optionally with a --backward
overriding it) could do too.

-- 
Matthieu

Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Teach git-describe how to run name-rev
>
> Often users want to know not which tagged version a commit came
> after, but which tagged version a commit is contained within.
> This latter task is the job of git-name-rev, but most users are
> looking to git-describe to do the job.
>
> Junio suggested we make `git describe --contains` run the correct
> tool, `git name-rev`, and that's exactly what we do here.  The output
> of name-rev was adjusted slightly through the new --name-only option,
> allowing describe to execv into name-rev and maintain its current
> output format.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ...
> diff --git a/builtin-describe.c b/builtin-describe.c
> index 165917e..efbd43f 100644
> --- a/builtin-describe.c
> +++ b/builtin-describe.c
> ...
> @@ -272,6 +276,17 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
>  
>  	save_commit_buffer = 0;
>  
> +	if (contains) {
> +		const char **nr = xmalloc((4 + argc - i) * sizeof(char*));
> +		nr[0] = "name-rev";
> +		nr[1] = "--name-only";
> +		nr[2] = "--tags";
> +		memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
> +		nr[3 + argc - i] = NULL;
> +		execv_git_cmd(nr);
> +		die("unable to start %s", nr[0]);
> +	}
> +
>  	if (argc <= i)
>  		describe("HEAD", 1);
>  	else

Sorry for a belated question, but is there a reason not to do
this (on top)?

diff --git a/builtin-describe.c b/builtin-describe.c
index efbd43f..2a32af6 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -283,8 +283,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
 		nr[2] = "--tags";
 		memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
 		nr[3 + argc - i] = NULL;
-		execv_git_cmd(nr);
-		die("unable to start %s", nr[0]);
+		return cmd_name_rev(3 + argc - i, nr, prefix);
 	}
 
 	if (argc <= i)

Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Teach git-describe how to run name-rev
> 
> Sorry for a belated question, but is there a reason not to do
> this (on top)?

Nope, I just completely missed it.  Please make it so!  ;-)
 
> diff --git a/builtin-describe.c b/builtin-describe.c
> index efbd43f..2a32af6 100644
> --- a/builtin-describe.c
> +++ b/builtin-describe.c
> @@ -283,8 +283,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
>  		nr[2] = "--tags";
>  		memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
>  		nr[3 + argc - i] = NULL;
> -		execv_git_cmd(nr);
> -		die("unable to start %s", nr[0]);
> +		return cmd_name_rev(3 + argc - i, nr, prefix);
>  	}
>  
>  	if (argc <= i)
> 

-- 
Shawn.