GitHub Community
Set release's associated branch #21761
-
|
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. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
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 I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it does. Thanks! The merges from 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. |
Beta Was this translation helpful? Give feedback.
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
masterto make changes and then merge them into alpha. Had you been making branches from alpha or usinggit cherry-pickto 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!