Re: Finding a tag that introduced a submodule change

From: Jacob Keller <jacob.keller@gmail.com>
Date: Mar 3, 2017, 16:39 UTC
Message-ID: <CA+P7+xr=RmPy45DL_Qc2LcWKS-3AzVcPXqQaosZdf4jhnRp1TQ@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 6 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.
>

Hi,

I agree you shouldn't use tags in the submodules.

Show 5 quoted lines

> 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:
>

I've run into this exact problem at $DAYJOB.

Show 18 quoted lines

> 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.

So there's better ways to do this, but I do think there would be value in adding some plumbing to make it easier.

Here is how I would do this, best if written into a shell script or similar to automate the tricky part of #2

1. Do a git-log of the *parent* project, filtering out to show only
the path to the submodule

2. For each commit here, you find the new and old values of the
submodule pointer.

3. Use git merge-base --is-ancestor to ensure that "old" is an
ancestor of "submodule sha1id" and then

4. Use git-merge-base to ensure that "submodule sha1id" is an
anscestor of "new".

If both these are tree, then you know that the commit was included into the parent project at this point.

I've had to do this once or twice, but I don't actually remember exactly how I did 3. One sneaky way would be to add new tags for each submodule change something like the following might work and be more efficient. I'm not really sure but here's how I would go that route:

1. git log <limiting revision selection if you dont' want the entire
history> <path-to-submodule> --pretty=%h | parallel git ls-tree {}
path-to-submodule

The above more or less prints every submodule value as it changed over time in the parent project.

Next, for each submodule change:

2. git -C <submodule> tag parent/<sha1id> <submodule change>

Create a new tag prefixed by "parent" that includes the sha1id of the parent commit, and create it inside the submodule

3. git -C submodule describe --contains --match="parent/*" <submodule sha1id>

Once you're done you can also delete all the tags that are in the "parent" prefix if you dont' really wanna see them again.

Basically, re-use the machinery to tag and then use describe --contains to find the commit.

I *really* think a similar algorithm could be embedded as a plumbing subcommand, since I think this is tedious to do by hand.

I'm not really sure if this is the "best" algorithm either, but it's pretty much what I've used in the past. Either the tag way or the log yourself one at a time way.