A better way to get deterministic branch name

[gasinvein]

Currently we rely on git commit hash to identify the changes we make. Problem with it is that it changes when the updates we've got didn't change - e.g. when there were commits to the default branch after we've submitted a PR.
How can we produce a deterministic branch name (i.e. an update identifier) without relying on git?

[takluyver]

The extra-data usually (always?) has a sha256 hash associated with the download. Where there's only one source being updated, would using this hash instead of the commit hash work?

Where there are multiple sources to update, you could stick the hashes together in a deterministic order and make a new hash from them. But I also don't know how valuable combining updates is on average - you can be inviestigating an update to one package, and then a new PR turns up with that same update again plus a separate package. On the other hand, maybe there are cases where you have a group of dependencies that are released together, and then I can see it might be useful.

[wjt]

Hmm, interesting idea!

TuxPaint is one trivial example where the grouped behaviour is useful: the main app is almost always released simultaneously with a new pack of "stamps".

[takluyver]

That makes sense. Maybe the x-checker-data section could have a key like 'update group', so entries with same group name would be updated together? This is getting a bit off-topic, though.

[wjt]

My original goal in using deterministic commit hashes was to avoid having to save any state from the checker, but still not open duplicate PRs. (In particular I wanted it to be possible to decline an update and not have the PR get reopened.)

I learned today that GitHub Actions can read and store persistent variables on the repo:

https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#about-variables

so you could imagine using this as a way to save some state rather than needing deterministic branch names.