What does HackerNews think of git-issue?

> 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 and tamper-protection, too!

And to be clear, I'm not suggesting we should just tell people to use these tools instead of giving them a good UI for it, I'm suggesting we should use these tools as the underlying mechanism for a decentralized GitHub. Build a great UX on top of git instead of embedding git in a blockchain.

> 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

Maybe this? https://github.com/dspinellis/git-issue. I've always wanted to give it a spin.

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 accounts 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-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or 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 again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something.

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

There is this: https://github.com/dspinellis/git-issue

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

Sure, one executable is nice, that might be enough of a payoff for some people to overlook the rest. I think you may be underestimating the amount of choice that's out there though. For documentation alone there's countless options that don't require a centralized online thing. Three I'd use over Fossil again are 1) simple project doc/ folder with .md files inside (which you can render locally to look just like github with https://github.com/joeyespo/grip) 2) Doxygen or a language-specific equivalent if it's better 3) libreoffice docs stored either in the same repo or another one (perhaps a submodule).

For project management I'm less familiar with the options out there but I'd be surprised if there was nothing that gives a really stellar offline experience. I'd give a preemptive win to Fossil on the narrow aspect that your issue tracking changes can be synced and merged automatically with a collaborative server when you come back online, whereas if you stood up your own instance of Trac for instance I'm not sure if they have any support for syncing. If you're working by yourself, though, then there's no problem, Trac and many others work just like Fossil and stand up a local server (or are dedicated standalone programs) and work the same whether you're offline or online. But when I'm working solo I prefer low-tech over anything that resembles Jira (and I don't even really dislike Jira) -- I've played with https://github.com/dspinellis/git-issue as another offline/off-platform option but in my most recent ongoing solo project I'm quite happy with a super low-tech issues text file that has entries like (easy to make with https://github.com/dhruvasagar/vim-table-mode)

    +--------------+
    | Add thing    |
    +==============+
    | Done whens / |
    | other info   |
    +--------------+

and when I'm closing one I just move it to the issues-closed file as part of the closing commit. I might give it an identifier if I need to reference it in the code/over multiple commits.

Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them:

* Some of them make a mess of some part of git; one of them put its info in separate git branches you couldn't delete without breaking it, to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker.

* At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view.

* The rest effectively ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues.

* Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker.

Sibling mentions git-bug, a few others I recalled/quickly found:

https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones)

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

https://github.com/neithernut/git-dit

https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)

There are some approaches, e.g. https://github.com/dspinellis/git-issue

But I don't think there's much standardization around this type of git usage, and I'm not sure how efficient it would be for large repos.

There are some experimental tools for distributed code review and issues.

https://github.com/google/git-appraise

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

Would be nice to have something more polished though.

And perhaps ditz¹ [+ pyditz²], BugsEverywhere³, git-issue⁴.

As someone who -- I guess obviously -- cares about distributed issue tracking, I really like the direction and implementation of git-bug. The termui subcommand is really cool, and it appears to be enough to push co-workers to try it when they normally push back on "weird" tools.

I think the closest we had to user friendly before was the read-only web interfaces in ditz and BE, but user friendly isn't all that friendly if it is read-only.

1. https://rubygems.org/gems/ditz

2. https://pypi.org/project/pyditz

3. http://www.bugseverywhere.org/

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

I suppose it depends on how far you trust your ability to keep everything in your head, and reload everything coming back, and follow through on notes to self. I make todos too, but I try to honor a self-agreement that they be short lived and ideally not make it very far beyond my machine.

I linked https://github.com/dspinellis/git-issue in another comment but it gives a sense of the command line experience. I've also at times hacked up various scripts to create or modify items in github/jira/our internal POS, it can make things more likely to hit the tracker than to be met with a shrug. (It's so odd how sensitive programmers can be to even minor blocks in flow like a few seconds waiting for a webpage, or avoiding refactoring a method / class because in Java a new method might best belong to a new class which to do things 'proper' often entails a new file and then another new file for unit tests, adding them to version control, and all that takes like 30 seconds even with IDE support and is annoying.) I've at times thought about a small vim command that would call one of those scripts to create a new issue pre-templated with the file and location I was on, create, then insert the work item id, but never got around to it. As a pre-commit hook something to look for TODOs explicitly might be interesting, though I generally dislike hooks.

Might I suggest you give a chance to having separate TODO and WISHLIST and TASKS text files in the root folder that use whatever id scheme you like and point to the code, with the code referring back to those ids only rarely? Or even a single file with sections for those things and more, perhaps called PLAN? Keeping things separate keeps the code tidier, gives you license to put more details than you're likely to put in a one or two line comment, lets you refer to multiple code points instead of the local comment area, can be given to a high school student temp worker, and so forth.

For personal projects I've used https://github.com/dspinellis/git-issue a few times for a local command line issue tracker, it's not bad. I've got a longstanding mental TODO to try out Fossil one of these days though with all that and more integrated...

I was thinking of something that wouldn't be affected by the git history. There's no point in having branches for issue comments.

Something like:

  $ git issue add "foo doesn't work"
  Created issue ece5591: foo doesn't work
  $ git issue comment ece5591 "the problem might be with bar"
  Created comment 0191fa1 on issue #10.
  $ git issue comment --reply 0191fa1 "or with baz"
  Created comment f98e783 on issue #10.
  $ git issue show ece5591
  foo doesn't work -- ece5591 Your Name 
    the problem might be with bar -- 0191fa1 Your Name 
      or with baz -- f98e783 Your Name 
  $ git issue push
  Pushed issues ece5591.
  $ git issue pull
  Pulled issues 3ebdc7e, 24cdb90.

EDIT: I just gave myself a clue:

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

Actually the code review / issues are not necessarily non-dvcs. For example https://github.com/dspinellis/git-issue

And there are several distributed issue trackers, all with various problems:

https://github.com/dspinellis/git-issue https://github.com/keredson/distributed-issue-tracker https://github.com/duplys/git-issues

Somewhere around 2009-2012 there was also a lot of experimenting going on with distributed issue tracking, such as with Bugs Everywhere [0] (and like 3 or 4 others I tried some time ago that I can't find now).

That said, it seems like there was a resurgence - I found two, git-issue [1] and git-dit [2], that have both had activity this year. And git-dit has shown up on here at least once before, as well [3].

[0] https://github.com/aaiyer/bugseverywhere

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

[2] https://github.com/neithernut/git-dit

[3] https://news.ycombinator.com/item?id=13732598