Set release's associated branch

I tagged a couple pre-releases of a side project today, after noticing that they had not been tagged at the time.

Here they are: release 1, release 2

They were created by using git tag  locally, then pushing those tags to GitHub and editing the tags there to add release notes.

With the understanding that the timestamps can be wonky when a release is created this way (I’ve spoken with support about that before), I’m confused that the “base” branch is considered to be master when the tagged commits do not exist on that branch. I’m releasing from an “alpha” branch that diverged quite some time ago.

Ultimately, it’s not that big a deal. I’m probably not even going to keep the pre-releases around anywhere (they’re only uploaded to PyPI so I can easily install test builds on remote systems), but it’s weird that the release UI shows a comparison to master in this case.

Thanks for reaching out.

Looking at your repository’s history, it seems that tag 0.2.0a0 shows “17 commits to alpha since release”, which is I suspect what you’re expecting from the other two releases that you linked to. However, tag 0.2.0a1 is the first to show “2 commits to master since release”. It appears that after tag 0.2.0a0, you began creating new branches  from master to make changes and then merge them into alpha. Had you been making branches from alpha or using git cherry-pick to move the changes from master to alpha, I suspect you would have gotten the behavior you expect on the successive tags.

I hope that helps!

1 Like

Yeah, it does. Thanks!

The merges from master are because I’m using alpha and its pre-releases to test upcoming changes “in production” on a dog-food instance before merging them into upcoming releases. When one of the PRs is updated, I merge again from that branch to pull in the newer changes.

There’s probably a better workflow to use the next time I need a pre-release branch, but for now I’ll just ignore this display issue.

2 Likes