Stefan Beller <sbel...@google.com> writes:
> Sometimes users are given a hash of an object and they want to
> identify it further (ex.: Use verify-pack to find the largest blobs,
> but what are these? or [1])
Thanks for finishing the topic you started.
> @@ -11,6 +11,7 @@ SYNOPSIS
> [verse]
> 'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
> 'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
> +'git describe' <blob>
OK.
> diff --git a/builtin/describe.c b/builtin/describe.c
> index 9e9a5ed5d4..acfd853a30 100644
> --- a/builtin/describe.c
> +++ b/builtin/describe.c
> ...
> static void describe(const char *arg, int last_one)
> {
> ...
> @@ -445,11 +497,18 @@ static void describe(const char *arg, int last_one)
> ...
> + cmit = lookup_commit_reference_gently(&oid, 1);
> +
> + if (cmit)
> + describe_commit(&oid, &sb);
> + else if (lookup_blob(&oid)) {
> + if (all || tags || longformat || first_parent ||
> + patterns.nr || exclude_patterns.nr ||
> + always || dirty || broken)
> + die(_("options not available for describing blobs"));
> + describe_blob(oid, &sb);
I am not sure if I agree with some of them.
> + } else
> + die(_("%s is neither a commit nor blob"), arg);
This side I would agree with, though.
The caller of the describe() function is either
* 'git describe<RETURN>' makes a single call to it with "HEAD" and
exits; or
* 'git describe A B C...' makes one call to it for each of these
command line arguments.
And 'git describe <blob>' code is most likely trigger from the latter,
as it is not likely for HEAD to be pointing at a blob.
$ blob=$(git rev-parse master:Makefile)
$ git describe --always master $blob
and trigger the above check. Is the check against "always" useful,
or is it better to simply ignore it while describing $blob, but
still keeping it in effect while describing 'master'?
The 'dirty' and 'broken' check is redundant because we would have
already errored out if either of them is set before calling describe()
on user-supplied object names.
If I understand the way "describe <blob>" works correctly, it
traverses the history with objects, doing a moral equivalent of
"rev-list --objects", stops when it finds the blob object with the
given name, and when it stops, it knows the commit object that
contains the blob and path in that commit to the blob. Then the
commit is described to be a human-readable string, so that the path
can be concatenated after it.
Aren't these options that affect how a commit object is described in
effect and useful when you do the "internal" describe of the commit
you found the blob object in? IOW, wouldn't this
$ git describe --exclude='*-wip' $blob
make sure that in its output $commit:$path, $commit is not described
in terms of any "wip" refs?
