30

I have a perfectly valid repository which doesn't display correctly on GitHub. How do I report this to GitHub to get them to fix it?

This also affects the git command line tool, unfortunately.

If you want to know what's going on, look at the 'encoding' attribute of the commit.

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
  • 2
    It isn't official, but lots of people use https://github.com/isaacs/github/issues – tehp Jun 12 '18 at 23:50
  • 5
    This is ridiculous. Ever since MicroSoft took over the github UX has decreased (as always expected). But now we can't even find a way to report bugs. One of which is that *pasting* UTF-8 text with `\n` in it, gets removed. Whoot!? – not2qubit Dec 06 '18 at 20:01
  • 1
    @not2qubit - Well, I reported this before Microsoft took over. – Omnifarious Dec 06 '18 at 22:32
  • 4
    @not2qubit "...the github UX has decreased" -- what do you mean, what exactly has decreased? I'm no GH guru, and I've only noticed improvements and new features so far, not counting the removal of direct feedback channels. (OTOH I know what you're talking about reg. MS, they used to religiously gut anything they took over, but a) that was in the past (the new era under Nadella is different), b) accordingly, GH also seems markedly different to me, in that it's still as wonderful as before, and even improving steadily.) – Sz. Jan 31 '23 at 17:17

8 Answers8

16

See:

Stian Jørgensrud
  • 662
  • 6
  • 14
Greg Veres
  • 1,770
  • 19
  • 28
  • 2
    Just as an FYI to anyone that comes across this, GitHub (aka Microsoft) will kick back an email to support@github.com with a declined message. They don't allow that option anymore. – ke4ktz May 26 '21 at 13:55
  • 2
    The github.com/isaacs/github repository is closed, so that is not useful any more either. The first link now routes to a Github Discussions page with very appropriate-looking categories but which is utterly swamped by spammy postings, and hence does not actually seem at all useful. Hence I am at a loss as to how actually to provide constructive feedback. – Glen Whitney Aug 03 '22 at 23:55
  • 2
    @linuxUser123, https://github.com/github/feedback also just redirects to https://github.com/community/community now (more precisely its repo, where the Issues feature is disabled). – Sz. Jan 31 '23 at 17:11
  • 1
    Note that as of 2023 the only valid link for filing a proper bug report is https://support.github.com/contact/bug-report. Just make sure you are _really_ filing a bug in github itself, after verifying it exists for at least _several_ different browsers, on new profiles without extensions. Support is a finite resource, don't bog it down for the rest of us. – Mike 'Pomax' Kamermans Aug 19 '23 at 17:05
8

The only way I know is to fill out the form at https://support.github.com/contact as far as I know they don't have a public issue tracker.

stevec
  • 41,291
  • 27
  • 223
  • 311
JWilliams
  • 128
  • 6
8

If someone encounters a bug with one of GitHub's products, they can submit it to the below URL. It creates a ticket to track the correctness of a bug.

https://support.github.com/contact/bug-report

Dhaval L.
  • 319
  • 5
  • 7
5

According to the GitHub community site, currently the best location is https://support.github.com/contact/feedback but they do listen to feedback on any channel that you contact them on.

Marc Durdin
  • 1,675
  • 2
  • 20
  • 27
3

See JWilliams' answer for where to report bugs to GitHub. [Edit: perhaps this should be an answer to your other question.]

For what it's worth, it's not a good idea to use anything other than UTF-8 for the author and committer name encoding—the encoding field of the header is too difficult to apply to the pre-body part of the header, since it comes at the end of the lines:

>>> import subprocess
>>> p = subprocess.Popen(['git', 'cat-file', '-p', 'HEAD'], stdout=subprocess.PIPE)
>>> o = p.stdout.read()
>>> hdr, body = o.split('\n\n', 1)
>>> hdr = hdr.splitlines()

The header lines are long, even after splitting:

>>> import pprint
>>> pprint.pprint(hdr)
['tree 79036d838fc5ce13e849949d02e6048c2d33c561',
 'author \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 1528844508 -0700',
 'committer \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 1528844508 -0700',
 'encoding cp037']

but we can see that the encoding comes last. If the encoding were something that had byte-codes that resembled newlines (cp037 doesn't, fortunately) we would not be able to parse the header itself.

For the body, however, it's a good idea to use the header's encoding information. If we work in something that does have the encoding available, well:

>>> body.decode('cp037')
u'Well, this should be interesting.\x8e'

(Python 2.7 here of course).

Obviously neither GitHub nor my Git on this machine can do this for cp037, but on this particular host, that's not surprising:

$ iconv -f cp037
iconv: conversion from cp037 unsupported

On another machine that has the character set installed, iconv does work. I did not try this commit in Git there, but I did feed a header-line byte string through it; the result was:

>>> import subprocess
>>> p = subprocess.Popen(['iconv', '-f', 'cp037'], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
>>> so, se = p.communicate(s)
>>> so
'Eric Hopper\xc2\x80\x14hopper@omnifarious.org\xc2\x9e'

As you can see, the angle brackets have been damaged in translation (because the parse here was overly simple—we'd have to carefully avoid translating them). Again, though, the hazards are obvious: what if the encoding produces >?

torek
  • 448,244
  • 59
  • 642
  • 775
  • The conclusion I've come to is that everybody who uses git should have commit hooks that refuse to allow encodings other than nothing or UTF-8, and also refuse to allow authors or commit messages cannot be decoded into a valid set of Unicode codepoints using UTF-8. :-) I have no idea what git does to handle filename encoding. I was frankly a bit surprised because I was involved in Mercurial development when the decisions were being made there about canonical repository formats for such things. – Omnifarious Jun 13 '18 at 01:38
  • 1
    Git does absolutely nothing about file name encoding other than to depend on the fact that UTF-8 does not encode anything into slash or NUL. Well, that's not 100% true: it has *some* hacks to deal with OS X normalization. But mostly it just assumes that the OS encoding is whatever it is—file `schön` spelled with s+c+combining diaeresis+o+n is a different file from one spelled with s+c+diaereses-o+n. Since OS X guarantees you'll only have one of these, well, if you made *both* files on a Linux box, uhh.... (See Ch.3 in my sadly neglected [book](http://web.torek.net/torek/tmp/book.pdf).) – torek Jun 13 '18 at 01:59
  • (You might have information I should incorporate, by the way. I've looked deeper into Git's in-repo storage format for path names than I have into Mercurial's.) – torek Jun 13 '18 at 02:01
  • Well, Mercurial absolutely had to deal with it because the commit history of a file is stored in a file with the same path inside the `.hg/data` folder. Now, that is no longer strictly true, but it was at the very beginning, and so Mercurial had to be really on top of filename encodings or end up with corrupt repositories. I actually know a ton about how those files were structured up until about 2008. I presume it's similar now. The filename encodings, not quite so much. Mostly just stuff I remembered from IRC and the mailing list. – Omnifarious Jun 13 '18 at 02:04
1

https://github.com/orgs/community/discussions

https://github.com/orgs/community/discussions appears like the best public place at this time.

That repo appears to have some very confusing magic/hardcoded redirects so I'm unable to understand very well what is a repo, what is an organization:

but hey, it wouldn't be GitHub if they finally managed to make a fully sane public feedback mechanism.

https://github.com/isaacs/github/issues was killed by orgs/community/discussions in 2021. Or more precisely the mess of official things that preceded it, such as a Discourse instance at https://github.community created in late 2017: http://web.archive.org/web/20190601000000*/https://github.community/ which as of 2023 redirects to https://github.com/orgs/community/discussions/

https://support.github.com/contact/feedback also redirects to https://github.com/orgs/community/discussions now.

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
0

In connection with the actual title, I'm getting spammed by a project because its repo includes the same name as my user name. Tercioo / Plater-Nameplates At https://support.github.com/request I found "report abuse or spam" and reported the issue making sure they understand that it comes from github due to a problem with their notification bots. Dave Plater

Dave
  • 11
  • 1
  • 3
0

Tickets can be created via https://support.github.com/tickets/personal/0 which also shows the tickets you created.

Georg Ringer
  • 7,779
  • 1
  • 16
  • 34