On Wed, May 22, 2019 at 5:04 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

On Thu, May 23 2019, Jacob Keller wrote:

quoted

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.

Thanks, I'll take a look at this.

Regards,
Jake