Re: [PATCHv2 6/7] builtin/describe.c: describe a blob

[Jacob Keller <jacob.keller@gmail.com>]

On November 1, 2017 10:59:08 AM PDT, Stefan Beller <sbeller@google.com> wrote:
>>> Does the code describe a9dbc3f12c as v2.15.0:GIT-VERSION-GEN, or
>>> would it always be <commit>:<path>?
>>
>> As the blob is described using this function:
>>
>> static void process_object(struct object *obj, const char *path, void
>*data)
>> {
>>        struct process_commit_data *pcd = data;
>>
>>        if (!oidcmp(&pcd->looking_for, &obj->oid) && !pcd->dst->len) {
>>                reset_revision_walk();
>>                describe_commit(&pcd->current_commit, pcd->dst);
>>                strbuf_addf(pcd->dst, ":%s", path);
>>        }
>> }
>>
>> i.e. as `describe_commit()` is used on the commit part, the answer to
>your
>> question is: the former. I guess that is why Stefan wrote
>`commit-ish`
>> instead of `commit` ;-)
>
>$ ./git describe a9dbc3f12c
>warning: reflog of 'HEAD' references pruned commits
>v2.15.0-7-g980e40477f:GIT-VERSION-GEN
>
>So as noted below, this output is less than ideal, but technically
>correct as
>v2.15.0-7-g980e40477f contains that blob as well (you don't have these;
>it is this very series consisting of 7 patches on top of 2.15, none of
>them
>touching GIT-VERSION-GEN, hence that blob stays intact.)
>
>The way Junio asked, we actually may prefer the commit-ish to give
>that commit that introduced the blob for the first time, i.e. add the
>--reverse to the graph walking.

I know id prefer the first commit that introduced the blob. That's what describing a commit does, it finds the oldest tag prior to the commit, while --contains finds the first tag that contains the commit as an ancestor.

Neither of these things is a perfect match for blobs since we want to only find an exact commit that still has that blob. I think finding the first commit to introduce a blob is generally more useful. Finding the last commit from some branch before the blob was changed also might be useful but I don't know if that's exactly what you implemented here...

In either respect, unless it's super easy to implement, going with what you have now is better than nothing and we can improve it in the future should someone wish to take up the work.

-Jake
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.