search

maciejczyzewski / libchaos

Advanced library for randomization, hashing and statistical analysis (devoted to chaos machines). :microscope:
Other
1.61k stars 162 forks source link

Possible GitHub bug affecting this repo. #10

Closed Maikuolan closed 7 years ago

Maikuolan commented 8 years ago

Hi,

I've found a possible GitHub bug affecting this repo (I can confirm the affects, but I haven't yet confirmed whether it's actually a bug or something else): When forking this repo (it likely won't affect the parent) and then downloading it via the GitHub Desktop Client, there is a discrepancy between the content of the repo as per shown when browsing the repo using a browser and the content of the repo as per shown by the GitHub Desktop client. This discrepancy results in the GitHub Desktop Client showing uncommitted changes to the fork where there shouldn't be any (uncommitted changes appear immediately upon completing download of the repo to the GitHub Desktop Client, without any changes actually being made).

The discrepancy in question is that %repo%/B.B.S./ doesn't exist in the GitHub Desktop Client listing, but rather, the files contained by that directory are showing as uncommitted new files contained by %repo%/B.B.S/ (via the browser, the directory contains a trailing decimal, whereas via the GitHub Desktop Client, the directory doesn't contain any trailing decimal).

I've already contacted GitHub support about this, to get their opinion, to see if they think it's a bug or something else.

Just posting this issue here so that you're aware of it. I'll reply later, when I've heard back from them about it, to confirm whether or not this is actually a bug or just something else. :-)

maciejczyzewski commented 8 years ago

Actually this is a bug in Github Desktop Client. However I shouldn't name it like this. Try to create from your terminal prompt file named as ".." or "--"... http://www.cyberciti.biz/faq/linuxunix-rules-for-naming-file-and-directory-names/

Maikuolan commented 8 years ago

A very odd bug, at that.

Sorry for my slow reply! I've been in communication with GitHub support over the past 24 days, trying plenty of different ways to resolve the problem using PowerShell and some other tools; Unfortunately, none of these things seem to have worked.

After downloading the most recently released version of the client earlier today, deleting my fork, reforking and then recloning again, the problem still persisted, so, it seems to still be persistent, even to this latest client version.

Ultimately, what I've done (this is rather messy and it doesn't fix the bug, but, it seems to be working as a work-around for it) is (from a fresh fork) just download the "uncommitted" files via my browser to my desktop, delete them from the fork via my browser, reclone the fork, move the downloaded files to the local copy of the fork, but into a differently named directory (BBS instead of B.B.S.) and then recommit them via the GitHub client; They seem to now be no longer showing as "uncommitted" (although, of course, it means I have 5 additional commits on my fork, that, aside from one directory being named differently, is essentially identical to the parent repo).

I'm not really sure if I can call the issue "closed" (because the source of the bug hasn't been addressed), but, at least, it shouldn't affect my fork anymore.

I'll keep you posted here in this issue if anything changes. :-)

maciejczyzewski commented 8 years ago

Therefore it is worth to keep in mind how carefully files should be named. Soon it will be a new version of Retter, where many things will be improved and updated.

Thank you for your explanation and effort! :+1: