Subject: Re: git describe/contains for submodule commits

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Thu, 23 May 2019 02:04:20 +0200

On Thu, May 23 2019, Jacob Keller wrote:

> Hi,
>
> I've had a few times where I was curious of when a submodule got set
> to a specific commit.
>
> I noticed that git describe has "blob" support, which outputs something like
>
> <commit>:/path/to/file
>
> using the revision walking machinery.
>
> I'm curious if anyone knows if that sort of revision walk could be
> expected to find the first treeish that had a submodule commit instead
> of a blob.
>
> I'm not that familiar with the revision walking, so I was hoping to
> get some pointers of whre to look before I began implementing.
>
> Ultimately, I'd like to have some sort of command like:
>
>   git submodule contains <submodule> <commit id>
>
> and have it try to figure out the most recent commit htat has a
> submodule change for which the submodule is a child of the specified
> submodule commit.
>
> I can sort of reverse engineer this through git log, but it's slow and
> tedious, so I was hoping to be able to implement it into a revision
> walk that did this.
>
> Once I know the commit that introduces the submodule change, I could
> feed that to git describe --contains to find the tag/version which
> included the change easily enough.
>
> Thanks,
> Jake

You can do this with --find-object, e.g. on git.git:

    git log --find-object=855827c583bc30645ba427885caa40c5b81764d2

Plugging that into describe.c should be fairly straightforward.