From: Jacob Keller <jacob.keller@gmail.com>
Date: Wed, 29 May 2019 17:32:27 GMT
Subject: Re: git describe/contains for submodule commits
Message-ID: <CA+P7+xovDWswGpM-E4tc2AmHsnpwRzK57Zs27bm-itjwrdehhg@mail.gmail.com>
In-Reply-To: <8736l6ujcr.fsf@evledraar.gmail.com>

On Wed, May 22, 2019 at 5:04 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> 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.

Thanks, I'll take a look at this.

Regards,
Jake