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