A collection of Bugs and Feature-Requests

This is a collection of bugs and feature-requests which affect github.com

I’m posting this as a collection as I’m not sure what the specific rules are, for posting more than 1 Bug / Feature-Request.

I only checked for duplicates for some of these. I have seen that these are being moved to an internal list anyway (s the check for duplicates would be repeated anyway).

Bug: “Wiki” link on repository does nothing for non-owners if wiki is empty

Steps to reproduce

  1. Create a new repository
  2. Tell another user to view the repository and click on “Wiki”

Faulty behaviour

Nothing will happen. It’s as if they didn’t click on the button.
This is confusing.

Expected behaviour

If the wiki allows outside contributions, the tab should be shown.
The user should have the option to start a new wiki (“Create the first page”-button).
However, this option is only shown if the owner presses the link.

If the wiki does not allow outside contributions, the tab should be hidden until at least one article exists.


This bug has existed for years.

I once thought it was fixed; it is possible that this sporadically works (specific settings?).
This bug does not exist for guests (without GitHub account): the “Wiki” tab is hidden instead.

I’ve created an empty repository for people to test this at https://github.com/JayFoxRox/github-bug-test
I intended to delete that repository soon.

Bug: “Projects” link on repository is confusing advertisement for non-owners

Steps to reproduce

  1. Create a new repository
  2. Tell another user to view the project and click on “Projects”

Faulty behaviour

The user will see an advertisement / description of GitHub Projects (“Organize your issues with project boards”).
This is useless to them.
They are not the owner, so they can’t create a new project.
So it’s impossible for them to do anything in this tab.
This is confusing.

Expected behaviour

I’m unsure as I don’t use GitHub Projects myself.
I believe the tab should always be hidden until at least one project exists.
It should only be shown to owners.


This bug has existed for years.
This bug does also exist for guests (without GitHub account).

I’ve created an empty repository for people to test this at https://github.com/JayFoxRox/github-bug-test
I intended to delete that repository soon.

Bug: “force-pushed” is not displayed as link

In PR reviews, log messages are shown about force-pushes.
The message currently looks like this:

> <User> force-pushed the \<user\>:\<branch\> branch from <old-rev> to <new-rev>

The “force-pushed” can be clicked to get a compare between <old-rev> and <new-rev>.
This is extremly hard to tell as there’s no visual hint for this useful feature.

Due to the impact of his feature and how well-hidden it is, I consider this a bug.

I’d recommend to somehow make it obvious that this word is clickable (underline? dots?) or appending a “Compare” (button or link) somewhere in that line…

Feature-Request: “ahead” / “behind” message should link to comparison

When viewing a fork, GitHub prints a message (above file-list) like:

> This branch is 3 commits ahead, 5 commits behind upstream:branch.

On the right side, it allows to “Pull Request” and “Compare”.
However, those buttons only allow comparing the HEAD against the upstream:branch.

It would be nice if the “ahead” and “behind” were clickable to serve a similar purpose:

  • Clicking “ahead” would act like “Compare”
  • Clicking “behind” would act like a compare in the other direction. This would be useful when trying to find out which commits are missing from a feature-branch (as it potentially affects testing).

Feature-Request: Allow PR author to "request changes"

Currently, it’s impossible for a PR author to use the review tool to review their own PR.
This is a bad limitation because the PR author might still want to signal that there’s an issue with the PR.
Allowing “Request Changes”-reviews (and to dismiss it later), provides more context than just leaving a “Comment”.

However, I don’t think that the author should be allowed to make an “Approve”-review (potentially biased).

So that restriction is fine.

Feature-Request: Display all PRs in branch list

The branch list in https://github.com/<user>/<repository>/branches currently only show PRs to <user>/<repository>.
It does not show PRs to <upstream>/<repository> or any other repository in the network.

Ideally, the list would be able to show all PRs that this branch is involved in.
As there’s potentially multiple PRs to different upstreams, this needs to display in a vertical list probably.

Feature-Request: Display merge conflicts in PR overview

If there’s a merge conflict, it is not shown in https://github.com/<user>/<repository>/pulls
This leads to frustrating delays in review.

This is a problem for authors, as their code can get outdated without their knowledge.
This is a problem for maintainers as it’s hard to see which branches need review (after rebase) and which don’t.

I currently resort to manually leaving a “Request changes” review.

Ideally, there’d be a visual indicator in the PR overview.
(Additionally, consider a notification for the author of a PR if their branch has a new merge conflict)

Feature-Request: Display list of “forked to” when viewing upstream

When viewing a fork, it displays “forked from <upstream>/<repository>” below the repository name.
This makes it easy to switch to upstream from a fork.

To go to a fork from the upstream, it is usually recommended to use the “Fork” button.
This is problematic:

  • It is elsewhere in the layout, so this is not intuitive.
  • It doesn’t inform the user if a fork already exists.
  • It shows a menu if the user is member of organizations (which means more clicks).
  • There’s a high risk of accidental forks by clicking any of the “Fork again to a different account” links (instad of “You’ve already forked <repository>”).

I’d like to see a “forked to <user>/repository, <org1>/<repository> and <org2/repository>” (for all organizations that the user is a member of) when viewing upstream.

Feature-Request: Ability to remove outdated deployments / environments

We have an outdated deployment on https://github.com/xqemu/xqemu/deployments (shown from repository view as “1 environment”).

  • The list of deployments only shows ancient changes.
  • None of the “View Deployment” buttons work anymore (404).
  • The github-pages branch (/ environment) mentioned in the activity log doesn’t even exist anymore.

It would be nice if these were either auto-removed, or if there was an option to manually delete those entries.
Another solution could be to give the option to disable “Deployments” / “Environments” in the repository settings.

I’d almost consider this a bug as none of the buttons work anymore, and we don’t even want that feature.

Feature-Request: Allow guests to view “/pulls” and “/issues” search

Guests (without GitHub account) can’t access https://github.com/pulls or https://github.com/issues.

This is bad design, because users can still perform the same search using https://github.com/search.
The major difference is that the results will be displayed differently.
The “/pulls” and “/issues” display is more useful for many purposes.

The motivation for this change is, to show my activity or specific bug groups to non-developers.

Feature-Request: Display git blame in “Files Changed” of PR

During PR reviews, I often care if changes are in the right commit (like fixups).

It would be nice to have a “Blame” option which shows what commit is responsible for each diff.

I believe this would be helpful for spotting some issues quicker.

I think this could be integrated with the “Unified” display mode.

Feature-Request: Detect rebase in “force pushed” comparison

When clicking the “force-pushed” in a PR log (to get a comparison between 2 revisions), it shows all changes including changes done by a rebase.
Unfortunately, this makes this feature less useful.
A rebase should be displayed in 2 steps so reviewers can see:

  1. Mention of old base and new base (the rebase).
  2. The changes from the new base to new-revision, compared to old base to old-revision (changes to PR).

I’m not sure wether this is even feasible to do with git (there might be interactions which make this impossible); but it would be worth trying.


Hello @jayfoxrox

Thank you for your feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion/feedback we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.

Once again, thank you for your input!

Greatly appreciated