rybak/copy-commit-reference-userscript

Userscripts to add a "Copy commit reference" button to commit pages of Git hosting providers.

copy-commit-reference-userscript's Issues

Add support for Gogs

Overview

Development of Gogs is done on GitHub. A public-ish mirror is available at https://try.gogs.io/gogs/gogs. Gitea and Forgejo are forks of Gogs.

Public instances

• https://try.gogs.io
  • Unfortunately, even the explore tab requires an account. Thankfully, the registration is open.

Example URLs for testing

• Regular commit: https://try.gogs.io/gogs/gogs/commit/1112a71ea5279a29666d54f07ef101480519fd16
• Commit without body in the commit message: https://try.gogs.io/gogs/gogs/commit/3be3ae500b4b4792db94f4a8d46943b783400681
• Tagged commit:
• Commit at the tip of a branch:
• Commit with issue number in the subject line: https://try.gogs.io/andrybak/copy-commit-reference-userscript/commit/a227145e015904bcc9dea3855fbd4a2297bef9b9
• Commit with PR number in the subject line:

Screenshot

The button should be placed to the left of the "Browse Source" button, similar to implementation for GitHub and Gitea:

Add support for Forgejo

Overview

Forgejo is a fork of Gitea, with their own commits being continuously rebased on top of Gitea. Unlike Gitea, which is hosted on GitHub (they are working toward self-hosting, see pinned issues), Forgejo seems to be self-hosted: https://codeberg.org/forgejo/forgejo, since Codeberg runs Forgejo.

This was initially tracked under #4.

Public instances

• https://codeberg.org
  • Self-hosted: https://codeberg.org/forgejo/forgejo
• https://git.disroot.org/

Example URLs for testing

• Regular commit: https://codeberg.org/forgejo/forgejo/commit/d63c5b18a78ecf6a57e2d479b7a9d968feff68c9
• Commit without body in the commit message: https://codeberg.org/forgejo/forgejo/commit/f578279cfe85d4e23b83d3759ec782790fed869d
• Tagged commit: https://codeberg.org/forgejo/forgejo/commit/b63df8b5c491729f557fd8076b44f9df1d00eec1
  • No special handling needed, tag is out of the way of the commit message.
• Commit at the tip of a branch: https://codeberg.org/forgejo/forgejo/commits/branch/forgejo
• Commit with issue number in the subject line: https://codeberg.org/forgejo/forgejo/commit/e35d92de1f37bea0a593093678f093845955e3fc
• Commit with PR number in the subject line: https://codeberg.org/forgejo/forgejo/commit/a4369782e1cfbbc6f588c0cda5776ee823b0e493

Screenshot

The button should be added to the left of "Browse Source", same as for Gitea, similar to GitHub.

Add support for Sourcehut

Overview

• Home page: https://sourcehut.org/

Is UI of this hosting provider a SPA?

No.

Public instances

• https://sr.ht/
  • Self-hosted repository: https://git.sr.ht/~sircmpwn/git.sr.ht

Example URLs for testing

• Regular commit: https://git.sr.ht/~sircmpwn/git.sr.ht/commit/b063dbda6eac780045180030878d27ad39498ec4
• Commit without body in the commit message: https://git.sr.ht/~sircmpwn/git.sr.ht/commit/b063dbda6eac780045180030878d27ad39498ec4
• Tagged commit: https://git.sr.ht/~sircmpwn/git.sr.ht/commit/a99fda3715f188b0cb1f7d72d231f20a3874ad08
• Commit at the tip of a branch: https://git.sr.ht/~sircmpwn/git.sr.ht/log/master
• Commit with issue number in the subject line: N/A
• Commit with PR number in the subject line: N/A

Screenshot

The userscript's button should go in the column of buttons on the right hand side:

Add support for Phorge

Overview

https://we.phorge.it/source/phorge/repository/master/

Phorge is a collection of web applications which help software companies build better software.

Phorge is a community-maintained fork of Phabricator.
...
Phorge is developed and maintained by The Phorge Team.

Is UI of this hosting provider a SPA?

No.

Public instances

• https://we.phorge.it/

Example URLs for testing

• Regular commit: https://we.phorge.it/rP69c64c1e83e23f11a594686d0abb3f1a74c8d4b1

• Commit without body in the commit message: https://we.phorge.it/R6:4322021080d4f0a39ae16ec594b7da7bf7ca6452

• Tagged commit: https://we.phorge.it/rP56789a2fa68167b4af49c1b1e0a502f49caeb126

• Commit at the tip of a branch: https://we.phorge.it/source/phorge/history/stable/

• Commit with issue number in the subject line: the repositories at we.phorge.it don't seem to use this style of commit messages. The format of referring to tickets/issues is T<number>. For example, in commit https://we.phorge.it/rHP065aaa664276b4363b62342e7872a533c114ebf0:

  Ref T15005

  links to https://we.phorge.it/T15005

  Commit messages can also reference "questions" in format Q<number>. For example, https://we.phorge.it/rP69c64c1e83e23f11a594686d0abb3f1a74c8d4b1 links to Q68

• Commit with PR number in the subject line: N/A

Screenshot

The userscript's button would fit well in the right hand sidebar:

Add support for GitLab

Example URLs for testing:

• gitlab.com:
  • https://gitlab.com/andrybak/resoday/-/commit/b82824ec6dc3f14c3711104bf0ffd792c86d19ba
• separate instance:
  • merge commit: https://invent.kde.org/neon/neon-packaging/bonsai/-/commit/9aa800ffdbf850ca71d54a5e3422fef2d2a5ae4a
  • regular commit: https://invent.kde.org/education/kturtle/-/commit/8beecff6f76a4afc74879c46517d00657d8426f9

Add support for Bitbucket Server

Overview

• Official documentation
• Atlassian no longer sells licenses to Bitbucket Server.

Is UI of this hosting provider a SPA?

No.

Public instances

There are none, as far as I am aware.

Example URLs for testing

N/A

Notes

Alpha version has a bunch of leftover code from bitbucket-copy-commit-reference.user.js of Atlassian Tweaks. Most of this leftover code is specific to supporting Bitbucket Server and Bitbucket Cloud.

We shall expand class BitbucketServer to fully implement support Bitbucket Server by reusing this leftover code.

Screenshots

v0.10-alpha, as of 2023-08-21. The button is on the left, near the permalink to the commit.

v0.17-alpha, as of 2023-08-25. The button is moved to the right, the checkmark tooltip is clipping out of page on the right.

v2.0, as of 2023-09-14. The tooltip is moved to the left and is now styled as some other native tooltips.

Extract common code into a library + Split into separate userscripts per Git hosting

Context

Long and boring historical context (click to expand)

The userscript copy-commit-reference.user.js originates from a userscript for Bitbucket Server. Bitbucket Server is the hosting that I use at $dayjob. That userscript is/was part of Atlassian Tweaks, where it is natural to also want to support Bitbucket Cloud, which it did since version 2, which was actually the initial commit for the userscript in that repository (version 1 supported only Bitbucket Server, but wasn't published).

For personal projects, I mostly use GitHub, so I've created a separate userscript for it as well.

Merging the two userscripts seemed like a good idea, because

1. it allows for easier code re-use between the two userscripts, which was mostly done by copy-pasting
2. it forces to come up with a better architecture for separating the common code from code specific to a particular Git hosting – this separation in the Bitbucket script between Cloud and Server versions was implemented terribly.

Once I had implementation for GitHub and Bitbucket Cloud (Bitbucket Server had to wait a bit), it was natural to want to add more. I started by adding GitWeb and Gitiles, because I was aware of repo.or.cz through its mirror of git.git (uses GitWeb) and I was aware of kernel.googlesource.com (uses Gitiles).

During development of copy-commit-reference.user.js, I've also figured out how to publish and use libraries for userscripts in a way that is compatible with rules of Greasy Fork.

---

As of version 2.3, the userscript supports eight different hostings, and there are plans to add seven more (15 in total, if all are implemented).

Problem

As of version 2.3, the userscript has size of 1.5K lines of code at roughly 54 kilobytes of JS. This seems like a bit of an overkill, if a user wants support for only one of the 8-15 supported hostings.

On the other hand, worrying about the code size is probably a premature optimization. For example, a fairly popular userscript – Stack Overflow Extras – is over 160 KB of JS, with 46+ KB of JSON, CSS, and HTML on top of that.

Solution

It might be a good idea to extract the common code of the userscript into a library, and replace the big userscript with 8-15 smaller separate userscripts, one userscript per Git hosting.

Pros

• Smaller footprint, possibly leading to faster execution.
• During publishing of a new version, users only need to update the userscripts relevant to them. For example:
  • updating from 2.1 to 2.2 was only relevant for GitHub
  • from 2.2 to 2.3 – Gitiles
  • from 1.2 to 1.3 – GitLab
• More obvious/readable applicability to the user – each of the separate userscripts will just have the hosting in the name instead of the generic Git: copy commit reference.
• Code simplification: a userscript for a single hosting doesn't need methods getLoadedSelector and isRecognized in the class GitHosting. This reduces the number of required methods from six to four.
  • For context, the current code for detecting which GitHosting needs to be used is heavy operation. For example, on GitHub pages, the listener inside waitForElement with the big selector from getLoadedSelector gets called ~12 times.
• Contributors, who want to work on existing support of a particular Git hosting need to edit a small file, unencumbered by all other irrelevant Git hostings.
• It is an opportunity to get more experience for maintenance of libraries for userscripts.
• A separate userscript could be in a different repository (how bitbucket-copy-commit-reference.user.js was/is in Atlassian Tweaks, see context above). A separate userscript could be even maintained by another person. This solves the problem of availability of the hostings for testing – a separate maintainer would be responsible for testing their userscript on the instances that they have access to themselves.
• Easier to maintain up-to-date screenshots (cf. 52b8135 and 54d6c4a).
• Git tags no longer need to be created in the main repository for the userscript (might still make sense to do it for the library).

Cons

• If a user uses many hostings (as an example, I use Bitbucket Server, GitHub, and GitLab regularly) they have to install many userscripts
  • This also leads to multiple userscripts getting updated, if a change in the common code was published to all userscripts.
• Harder to add support for new hostings. It would require creating infrastructure for a whole new userscript, which not all developers might be familiar with. This could be solved with some kind of template file.
• More complicated and slower iteration, when changes in the common code are needed (add new feature to library > publish library > migrate userscript to new version of library > use new feature of library in userscript)
• Support for userscript libraries in code editors is lacking. This means less information about types, worse auto-completion, etc.
  • However, this issue can be worked around at least in VS Code.
• Increased maintenance burden for managing:
  • metadata of userscripts (the // ==UserScript== section at the top) (solvable with shell scripts)
  • documentation on Greasy Fork (solvable by storing it in the repo)
  • separate changelogs
• Git tags will no longer be able to be created in a sensible manner – some users coming to a GitHub repo pay attention to presence or absence of recent releases/tags. Though this could be solved by introducing per-hosting tags: github-1.2, gitweb-3, bitbucket-server-4 etc.

Add support for Gitea

Overview

Gitea is a fork of Gogs (#8).

Is UI of this hosting provider a SPA?

No.

Public instances

• List of public repositories
  • https://git.plastiras.org/
  • https://opendev.org/
  • https://gitea.com/explore/repos

Example URLs for testing

• Regular commit: https://git.plastiras.org/MadeOfJelly/MushMachine/commit/f27300a8fa2cda354b83604eb67f6b674f4f05cb
• Commit without body in the commit message:
• Tagged commit:
• Commit at the tip of a branch:
• Commit with issue number in the subject line: https://gitea.com/gitea/awesome-gitea/commit/4b7744b8cc9ba631038da1d30d7b14473791316a
• Commit with PR number in the subject line:

Screenshot

TODO

• Fix on https://projects.blender.org/blender/blender/commit/f25418b7305ca6a4b44a7b18f954718e94eccf86

Add support for Pagure

Overview

• https://pagure.io/
  • Self-hosted at https://pagure.io/pagure.

Is UI of this hosting provider a SPA?

No.

Public instances

• https://pagure.io/pagure

Example URLs for testing

• Regular commit: https://pagure.io/pagure/c/4b3799013f4ee4f69e7a4497fcf36f3cc60224ee
• Commit without body in the commit message: https://pagure.io/pagure/c/97801374678beeb30a792b929d7b3e86de32c373
• Tagged commit: https://pagure.io/pagure/c/a67e5bdc9ff4ad1679b880fd388e873161b13cd6
• Commit at the tip of a branch: https://pagure.io/pagure/branches
• Commit with issue number in the subject line: TBD
• Commit with PR number in the subject line: TBD

Screenshot

Not a lot of room on the right side, but it will fit if a simple icon is used. A mockup with clipboard emoji:

Font Awesome icons are also available, i.e. with HTML <span class="fa fa-copy"></span>, it looks like this:

GitHub: design change idea

Context

There are three components to the commit reference: hash, subject, and date. On GitHub, two of the are at the bottom of the commit's view (date and hash), and one is at the top (subject). On GitHub, as of version 0.8-alpha, the userscript puts the button (technically) in the bottom left corner, next to author information, which includes the date. The commit's hash is in the bottom right corner, next to a link to the parent commit.

Putting the button on the left (but not necessarily at the bottom) also mimics GitHub's own "Copy path to the file" button:

Idea

What if the button was on the left of the subject, next to the "Browse files" button?

Add support for GitBucket

Overview

• Home page: https://gitbucket.github.io/
• Development is on GitHub: https://github.com/gitbucket/gitbucket

Is UI of this hosting provider a SPA?

No.

Public instances

• https://git.findnothing.cyou/
  • Might need to find more examples, I just stumbled upon this one in GitBucket's issues
• Unfortunately, "Official demo site" is dead: https://gitbucket.herokuapp.com/

Example URLs for testing

• Regular commit:
• Commit without body in the commit message: https://git.findnothing.cyou/ZhuningOS/bash/commit/6054d0e506aa4549bc5a6b6d40c2ec76a6ef0bb3
• Tagged commit:
• Commit at the tip of a branch: https://git.findnothing.cyou/zyppe/document/commits/master
• Commit with issue number in the subject line:
• Commit with PR number in the subject line:

TODO

• find a commit page with a body in the commit message

Screenshot

Not sure about the location yet, because of lack of a commit with a body in the commit message => I have no idea how the UI displays it. However, the button should probably be added to the left of button "Browse code":

Add support for RhodeCode

Overview

• Documentation
  • https://code.rhodecode.com/
  • https://en.wikipedia.org/wiki/RhodeCode

We might also consider supporting Kallithea, which is a fork of RhodeCode.

Public instances

• https://code.rhodecode.com
  • Self-hosted: https://code.rhodecode.com/rhodecode-enterprise-ce

Example URLs for testing

• Git: https://code.rhodecode.com/ci-notify/changeset/4adc29a0bea2578f923cddef339d0528edf73d45
• Mercurial: https://code.rhodecode.com/ci-notify/changeset/4adc29a0bea2578f923cddef339d0528edf73d45
• SVN: https://code.rhodecode.com/svn-doc/changeset/1

Screenshot

The button might fit well in the right hand side cluster of buttons, near the button "Copy the full commit id" and the permalink.

Put Markdown content into the clipboard

Many of the Git hostings support editing comments, issues, PR descriptions in Markdown syntax. It might be useful for the userscript to put content with type text/x-gfm into the clipboard.

• GitLab's text editor automagically detects pasted Markdown and chooses it over plain text content.
• Blocked by a bug in GitHub's text editor, which cannot handle text/x-gfm correctly: https://github.com/orgs/community/discussions/65235