Use Build.ancestors to find replacement commit for rebased build

[tmeasday]

Fixes #375

If one of our baseline builds has a commit that is not in the repository, we cannot figure out the changedFiles via git.

So, instead, we coordinate with the index to find an (nearest) ancestor of that baseline build that does have a commit, and use that commit instead for calculating the changedFiles.

Then we send the replacementCommit information up to the index, and the index will use that information to augment the list of onlyStoryFiles with the stories that have changed in between each replacement commit and the original.

This PR doesn't currently include any UI. @ghengeveld what are your thoughts there? At the least we should log some debug messages, maybe you can guide me there?

This PR depends on various unreleased PRs to Chromatic:

• https://github.com/chromaui/chromatic/pull/6124
• https://github.com/chromaui/chromatic/pull/6123

[tmeasday]

Add an info message at the end telling them this happened.

[ghengeveld]

I was wondering whether you had considered this situation:

[A]-[B]- C     [main]
      \
       D -(E)  [feature]

Where B has been rebased and therefore doesn't exist in history anymore. How will we find A as ancestor of E if they're on a different branch? lastBuildOnBranch isn't going to help us.

[tmeasday]

Where B has been rebased and therefore doesn't exist in history anymore. How will we find A as ancestor of E if they're on a different branch? lastBuildOnBranch isn't going to help us.

This sounds like a question about baseline calculations? I think in the scenario you outlined, where the "true" ancestor commit was rebased and is on a different branch, we will not find it, and instead we'll use the previous commit that has a build and is a git ancestor. In your picture:

[A]-[B]- C     [main]
      \
       D -(E)  [feature]

If B has been rebased and A has not, then A will be an ancestor of E in a straightforward way. The main problem in this scenario (and it is a problem, although I've never noticed it in practice) would be approvals from B would get lost on E.

PS none of this is an issue for TurboSnap by the way. TS is just going to copy what snapshots it can from the ancestor builds, whether they are the right choices or otherwise. Thanks to this PR it should even handle ancestor builds that don't have a commit too 👍