Reconsider GH-NNNN vs #NNNN in commit log

We decided using GH-NNNN in commit log since we moved to Github.
But there are still some #NNNN. It’s difficult to use GH-NNNN consistently. (see here)

Additionally, GH-NNNN makes commit log page on Github fork ugly.
See here

  • #12518” becomes “python#12518”.
  • “GH-12531” becomes “pythonGH-12531”.

How do you think about stop using GH-NNNN in commit log and just use #NNNN instead?

We need to be able to know which numbers reference github items after we move to the next version control system/service.

CPython has already lasted longer than Mercurial, SVN, and at least two others older than I am. It’s fair to expect that it’ll outlast git and Github too.


When GH-xxx is used, GitHub UI renders it directly as a link which is convenient.

Example: you can click on “GH-14504” and “GH-14515”. Sadly, GitHub is unable to recognize “bpo-37467”.

Our Roundup instances recognizes bpo-xxx and GH-xxx, but recognizes #xxx as a bpo number:

New changeset ebe709dc1d7c1f9f07dc7d77e53674d2500b223e by Jason R. Coombs (Anthony Sottile) in branch '3.7':
bpo-36853: Fix to actually print the unused rules (#13579) (#15653)

#13579” and “#15653” link to the bug tracker, not to GitHub.

It’s more a practical issues.

Maybe migrating bugs to GitHub will solve some of these problems, but I also expect it will not magically solve all identifiers problems :slight_smile:

I expect that “prefix-identifier” reduces the risk of confusion.

A few years ago, Python bugs were hosted on SourceForge. Hopefully, the migration to Roundup succeeded to keep existing identifier. It’s quite common that I have to dig into very old bugs with bug identifier near 1 000 000: likely old SourceForge identifiers.

Aaaaaaah, migrations :slight_smile:

Note: I will not comment sha1 which may be Mercurial or Git commit identifier…

1 Like

The “automerge” label on GitHub replaces #xxx with GH-xxx in the PR title for you, but I dislike automerge because it produces bad commit messages :frowning:

Only if you don’t edit the opening comment first, which is usually forgotten :slight_smile:


I created RFE automerge enhancements to explain my concerns about automerge.