github VS git-issue

While looking for solutions, I realized that many developers face similar challenges. This issue is widely discussed, particularly in a GitHub thread: Track traffic to GitHub repo longer than 14 days #399.

Probably the older email address is still the primary one for the GitHub account.

GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See <https://github.com/isaacs/github/issues/1368> for the tedious details.

Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).

Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.

I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.

However, there is a massive issue. Github by default truncates insights to t-14 days (where t = today). This is super annoying as there is a discontinuity in data. There is also an archived issue on Github regarding this. The issue has a whopping 119 comments and has been around for over 8 years now. Basically, from the discussions there - Data you don't persist today will be gone 14 days from now. And looks like Github hasn't done anything about it.

> Hi, people have made money using my code and I also don’t care

looks like everyone's missing the point.

> I understand this is upsetting to you

Again, maybe I am on another level of comprehension, so I don't understanda why it is so hard for someone to get it, but I am not upset by that, at all.

I simply know that those who think "it will be fine" are delusional and don't know what they are talking about!

So I just will paste some link to relevant news here, maybe it will make things clearer.

It includes the opinion of Antirez, father of one of the most successful OSS ever: Redis. Maybe his words will open your eyes and tear the veil of Maya.

(spoiler ahead alert!)

Basically you work for free and people don't even thank you and the maintainer ends up being doxed or blamed or pushed aside and in the long term the only solution to keep sanity is to resign

https://www.jeffgeerling.com/blog/2022/burden-open-source-ma...

https://www.theregister.com/2022/01/13/opensource_apacheplc4...

https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-...

https://old.reddit.com/r/linux/comments/z14tt2/reason_why_op...

https://github.com/isaacs/github/issues/167

http://web.archive.org/web/20221217180915/http://antirez.com...

I don't know what the fuss is all about. It was publicly known that Github was breaking automatic git archives consistency for many years. Here is a bug on a project to stop relying on fake github archives (as opposed to stable git-archive(1)):

https://bugzilla.tianocore.org/show_bug.cgi?id=3099

At some point it was impossible to go a few weeks (or even days) without a github archive change (depending on which part of the "CDN" you hit), I guess they must have stabilized it at some point. Here is an old issue before GitHub had a community issue tracker:

https://github.com/isaacs/github/issues/1483

Hello, I see you stepped on my favourite personal soapbox! :)

https://github.com/isaacs/github/issues/1017

I really, really like semi-linear branching/merging. I.e. always rebase-merging, but with a merge commit.

Reasons, in comparison to Github's "rebase merge" which doesn't produce a merge commit:

1. It makes it clear which commits were part of one PR

2. It makes it clear who did the merge

3. It's okay to not have every commit build. but the one being merged will.

4. Still pretty bisectable. You'll narrow things down at least to the PR that caused an issue, and from there it's usually quite simple.

5. Looks very tidy in gitk & Co

Not to say that the feature isn't coming to FOSS git services.. Just that even proprietary organizations have had issues with taking a while to implement them.

Oh this is cool actually! Nice! One of the grievances I have with github commit signing is this issue https://github.com/isaacs/github/issues/1099

In addition, you probably want to read this discussion. https://github.com/isaacs/github/issues/1138

Note that if you just want to provide a issue tracker within Git rather than relying on centralized web services like Github or Gitlab, there is

https://github.com/MichaelMure/git-bug

https://github.com/dspinellis/git-issue

https://sciit.gitlab.io/sciit/ (this one has a list of alternatives here https://sciit.gitlab.io/sciit/#other-distributed-issue-track...)

Overall it's very disappointing that Github didn't decide to embed issue tracking (and also PR discussions) inside the repository (in another branch perhaps). Issue discussion is part of documentation IMO, and not distributing it alongside the repository causes lock-in

> but that is for the development of the platform and network of Gitopia. For the end user the workflows remain almost the same for collaboration.

I have to disagree here. Accidental complexity in a system can have severe downstream impacts on end users, whether that be in the form of poor performance, unreliability, or just slow update cycles. It's not something you can paper over and completely hide from the user.

> Along with this the blockchain layer layer offers immutable, transparent and tamper proof versioning of code

Tamper-proof can be accomplished natively by signing [0]. receive.denyNonFastForwards and receive.denyDeletes[1] can be used to make a git repository immutable. Git commits are also already content-addressable. And transparency is achieved by just having the repo available for people to clone.

> along with the collaboration meta and augments the current collaboration flow

Could this augmentation not be accomplished by storing the collaboration information in the repo under a set of special-purpose branches? Like git-bug[2] or git-issue[3]? Coupled with GPG signatures and you've got your immutability, too!

> Along with this it enables us to provide a novel means to incentivize open-source contributions along with fostering a more decentralized approach for governance (even for projects), every token holder could have a say in the decision making, reducing the risk of undue influence by a single party, hence eliminating centralized control.

This one I'll grant you, but it's by far the least compelling aspect of the project to me. I don't think we're going to solve the centralization of GitHub by centralizing on a new plutocracy, I'd much rather see efforts towards full decentralization. There's nothing inherent to Git that requires that we all use the same set of servers.

[0] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

[1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura...

[2] https://github.com/MichaelMure/git-bug

[3] https://github.com/dspinellis/git-issue

A quick search for 'issue tracker stored in git repository' brings up this Stackoverflow post, which points to git-bug and git-issue. Those look closer to what you're asking for, thought I haven't used them.

You're overstating the risks a bit and it's not great to posit implausible motives and means for bad outcomes... Like, Fossil devs could "turn evil", and ship an update that destroys your museum and any copies it can find. Github could "turn evil" without notice, and permanently nuke all of someone or some org's repos for no good reason and yes, that'd catch a lot of people with their pants down. It's better to first focus on outcomes, not means. Of course anyone actually concerned about losing their github issue data (or having their museums corrupted) should at least be making backups. (And it's not exactly an implausible outcome on its own, you can think of a variety of means that achieve it and discover one may be rather more likely for your situation, like if I was a Russian in Russia right now I'd have already made arrangements in case GH changes their mind or is legally forced to drop the ban hammer.)

The desire to move off github (and therefore any additional services besides hosting you were using, which issues are just one -- new ones keep getting added to try and cement your dependence) is something more worthwhile of thought than the idea of github turning evil. Fortunately that desire is an actual thing that's very common, or at least the desire to not be wholly dependent, and is why many people don't even use github issues to begin with even if they use github itself for hosting (or some other non-issues features). So there's not a big problem, and even if you start with using github issues, there are various migration tools to move github issues out to [alternative]. (And of course github issues have their own merits, people frequently want to switch to them! So similar migration tools exist to move from [alternative] to github issues, I wrote one for Jira years ago.)

It is brilliant to integrate things with the decentralized source control itself, you get free backups and deciding to migrate to something different in the future is easy, I think it's an overlooked approach for a lot of people. (It seems less overlooked when it comes to documentation in various forms like developer-focused .md files, or broader full static html websites which github can conveniently host for you.) Fossil is well-worth investigating for this free integration to see if it meets one's needs. But of course nothing stops you from doing it with git yourself in various ways. For personal projects, I'm pretty satisfied with being as minimal as having an issues.md file and moving things to an issues-closed.md file when I close one. I've also used the git-issue extension (https://github.com/dspinellis/git-issue -- see also its bottom section of Related Work).

But despite its brilliance it's not always the right approach. It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. There are very good reasons to have entirely separate (and even multiple partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, forums (internal, external, partner), wikis, public websites, docs (various audiences, public or not, team-level spikes or plannings or retrospectives)... One aspect of Fossil I found weak was its user capabilities (https://fossil-scm.org/home/doc/trunk/www/caps/ -- no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for someone.

I think he meant just the network effects of a social platform. Github has more people in them so there are more people interacting with repositories hosted on Github.

I wish that somehow people carried identity across Github / Gitlab / Gitea / other services. Like, a federated issue tracker. Or otherwise that the issues themselves were easily movable between platforms, with no lock-in. But the incumbent platforms rarely want something like this.

An alternative is to eschew platform issues entirely, and use decentralized issue comments hosted as Git repositories, like https://github.com/dspinellis/git-issue or https://github.com/neithernut/git-dit or https://github.com/MichaelMure/git-bug - I think that Gitlab should offer integration with one of them. I mean: both allowing to export issues and PRs into a Git branch, and allowing people to comment on issues and PRs by pushing to a Git branch.

git-bug, the one mentioned in the article here, has some documentation on its README of how well its importer/exporter tools support Github, Gitlab, Jira, and Launchpad: https://github.com/MichaelMure/git-bug

Most of the other such tools I've seen barely have the resources to import/export a single such API. git-issue only has Github import it looks like. https://github.com/dspinellis/git-issue

There's perceval which is designed to be a generic archival tool and supports lots of APIs, but only dumps them to source-specific formats and would still need a lot of work if you tried to use issues from different APIs together: https://github.com/chaoss/grimoirelab-perceval