Re: Finding a tag that introduced a submodule change

From: Stefan Beller <sbeller@google.com>
Date: Mar 15, 2017, 17:10 UTC
Message-ID: <CAGZ79ka56DtHeAMVK7T-voXm3aRrGvUPNYW9MC1YR+kcGriWJw@mail.gmail.com>
In-Reply-To: <CAHd499CfJnPtLmi8qzr=_jrfCgMw85MOUv-wPKmAHFUyDFXhRA@mail.gmail.com>

On Fri, Mar 3, 2017 at 7:40 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:

Show 29 quoted lines

> I have a repository with a single submodule in it. Since the parent
> repository represents the code base for an actual product, I tag
> release versions in the parent repository. I do not put tags in the
> submodule since multiple other products may be using it there and I
> wanted to avoid ambiguous tags.
>
> Sometimes I run into a situation where I need to find out which
> release of the product a submodule change was introduced in. This is
> nontrivial, since there are no tags in the submodule itself. This is
> one thing I tried:
>
> 1. Do a `git log` in the submodule to find the SHA1 representing the
> change I want to check for
> 2. In the parent repository, do a git log with pickaxe to determine
> when the submodule itself changed to the value of that SHA1.
> 3. Based on the result of #2, do a `git tag --contains` to see the
> lowest-version tag that contains the SHA1, which will identify the
> first release that introduced that change
>
> However, I was not able to get past #2 because apparently there are
> cases where when we move the submodule "forward", we skip over
> commits, so the value of the submodule itself never was set to that
> SHA1.
>
> I'm at a loss here on how to easily do this. Can someone recommend a
> way to do this? Obviously the easier the better, as I have to somehow
> train my team how to do this on their own.
>
> Thanks in advance.

I cannot offer an easy way. However I can come up with a proposal how to make this easy in the future. ;)

"git-{branch,tag} --contains" currently only takes a commit id as that is easy to check for. (Just a revwalk from all commits, as we walk over the commits in the graph)

We should extend the possible arguments to --contains, such that you can do

    # check that a given path had this exact tree/blob id
    git tag --contains <path>:<tree/blob-id>
    # check if the given tree/blob was at any path
    git tag --contains <tree/blob id>
    # generalizing from above:
    git tag --contains [<pathspec>:]<blob/tree id>

With this designed API you could ask for

    git tag --contains submodule:<sha1 from step 2>

For the implementation of this feature the revwalk would also need to walk the object graph (as restricted by the pathspec) and see if there is the given object for each tag.

Thanks, Stefan