On Sun, Nov 12, 2017 at 5:33 PM, Junio C Hamano <gits...@pobox.com> wrote:
> 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?
yes, we would exclude those refs. But the name alone (without reading the docs)
suggests anything given in --exclude is excluded, so what about the blob
$commit:path-wip/test1.c
which I might want to exclude from the search using the exclude pattern?
After reading the docs, this is silly of course, and the exclusion only applies
to the commit description part.
--all is an interesting case, as we pass --all to the revision walking machinery
for blobs, but that is slightly different than the --all flag given to describe,
which also only relates to the commit name that should be produced.
So, I'll go through all the options and see which we can drop.
Thanks,
Stefan
>
