5 ms·

Fossil is an alternative to both git (source control) and github (issues, etc). I think its brilliant having issues tracked in fossil. Part of the promise of g

Fossil is an alternative to both git (source control) and github (issues, etc). I think its brilliant having issues tracked in fossil. Part of the promise of github is that the user is in control, since your computer is a first-class citizen of a repository. You have all the code, and all the history on your computer. You can use github, but you don't need github, since its just another node in git's distributed network. But that promise falls apart with issues and pull requests. Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations. Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre - You can have a project on both github and gitlab. And you can replicate commits to both. But you can't replicate issues using the same mechanism. Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant.

benatkin 5y ago
That's true. People imagine GitHub provides git, but that's the wrong way of seeing it. They do provide it on your server but the git running on your own computer is from the git project. GitHub does help significantly with the git project, though. Here's git's official website, which is very good, and was started by a GitHub cofounder, but is run by the git project rather than GitHub: https://git-scm.com/ https://git-scm.com/
Jach 5y ago
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 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/ 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.
theamk 5y ago
"If [...] you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations." Github has a nice, documented API to export issues, including issue history. Many open source tools, including Gitlab, are happy to import that list into their own database: https://docs.gitlab.com/ee/user/project/import/github.html https://docs.gitlab.com/ee/user/project/import/github.html Granted, this has a problem if Github suddenly, without any warning, decides to turn off that API. Or if it goes down and loses data permanently. I find both of those scenarios pretty unlikely, but it you are worried about them, it should be pretty straightforward to have some sort of export script in cronjob, to keep a local copy of issue database.
- josephg 5y ago
  Sure; github has the ability to export its data via centrally managed APIs. My point is that tying a bunch of centralized data (access control, issues, discussions, PRs, wiki, etc) to the decentralized data store of git's source control undermines many of git's best features. It makes git a de-facto centralized system. Centralized systems aren't bad per se, but the combination is incoherent. Github's architecture has some of the worst parts of decentralization, combined with some of the worst parts of centralization. Eg, Git's decentralized nature makes it extremely hard to evolve. (See: the desire to move from SHA1 to something more modern.) And we don't really get the benefits of a decentralized system, because I can't interact with issues while I'm offline, or while github is offline. And we're all locked in to github's ecosystem. We can only fully interact with our opensource projects on github with permission, ironically, from Microsoft. And I don't know if I trust any big tech company enough to assume they'll remain a good stewardship over the world's opensource code. The decentralized data store is right there in the middle of every github project. I wish github thought to use it.
  - theamk 5y ago
    Well, Github did use decentralized data storage -- the wikis are implemented as directories full of markdown files. You can clone it to your PC and view locally, push/pull the changes, etc... In addition, you can use your repository as wiki directly -- with markdown rendering, and "edit" button in web UI, just having "docs/" full of .md files gives you pretty passable wiki. But it seems that very few people care. How many people mirror wikis of their favorite projects, or backup their issues? I know only one such person, myself. I think that for some types of data, distributed model with operations like "clone with full history", "pull", "merge", etc... makes very little sense. For example access control -- why would you ever want to clone this? If I set up a mirror of repo, I don't want to give their authors access by default. Same goes for discussions -- for a good discussion you want all members to see their own replies. Having original post appear on sites A, B, C; and reply 1 on sites A, B while reply 2 appears on sites B, C will be super confusing to users, and will likely just cause platform to be abandoned. And a lot of times, ticket list is better off shared, so people can coordinate the work they do even if they have their own fork. Once you realize a lot of supporting services need to be centralized, all you can use "git" for is for data distribution. Is git better than SMTP for mailing list discussions? Is git better that SMTP / REST API for ticket list? Maybe, maybe not. But ultimately it does not matter, because most people do not care about mirroring stuff locally, and those who do care, can already achieve it.

benatkin 5y ago

That's true. People imagine GitHub provides git, but that's the wrong way of seeing it. They do provide it on your server but the git running on your own computer is from the git project. GitHub does help significantly with the git project, though. Here's git's official website, which is very good, and was started by a GitHub cofounder, but is run by the git project rather than GitHub: https://git-scm.com/ https://git-scm.com/

Jach 5y ago

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 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/ 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.

theamk 5y ago

"If [...] you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations." Github has a nice, documented API to export issues, including issue history. Many open source tools, including Gitlab, are happy to import that list into their own database: https://docs.gitlab.com/ee/user/project/import/github.html https://docs.gitlab.com/ee/user/project/import/github.html Granted, this has a problem if Github suddenly, without any warning, decides to turn off that API. Or if it goes down and loses data permanently. I find both of those scenarios pretty unlikely, but it you are worried about them, it should be pretty straightforward to have some sort of export script in cronjob, to keep a local copy of issue database.

josephg 5y ago
Sure; github has the ability to export its data via centrally managed APIs. My point is that tying a bunch of centralized data (access control, issues, discussions, PRs, wiki, etc) to the decentralized data store of git's source control undermines many of git's best features. It makes git a de-facto centralized system. Centralized systems aren't bad per se, but the combination is incoherent. Github's architecture has some of the worst parts of decentralization, combined with some of the worst parts of centralization. Eg, Git's decentralized nature makes it extremely hard to evolve. (See: the desire to move from SHA1 to something more modern.) And we don't really get the benefits of a decentralized system, because I can't interact with issues while I'm offline, or while github is offline. And we're all locked in to github's ecosystem. We can only fully interact with our opensource projects on github with permission, ironically, from Microsoft. And I don't know if I trust any big tech company enough to assume they'll remain a good stewardship over the world's opensource code. The decentralized data store is right there in the middle of every github project. I wish github thought to use it.
- theamk 5y ago
  Well, Github did use decentralized data storage -- the wikis are implemented as directories full of markdown files. You can clone it to your PC and view locally, push/pull the changes, etc... In addition, you can use your repository as wiki directly -- with markdown rendering, and "edit" button in web UI, just having "docs/" full of .md files gives you pretty passable wiki. But it seems that very few people care. How many people mirror wikis of their favorite projects, or backup their issues? I know only one such person, myself. I think that for some types of data, distributed model with operations like "clone with full history", "pull", "merge", etc... makes very little sense. For example access control -- why would you ever want to clone this? If I set up a mirror of repo, I don't want to give their authors access by default. Same goes for discussions -- for a good discussion you want all members to see their own replies. Having original post appear on sites A, B, C; and reply 1 on sites A, B while reply 2 appears on sites B, C will be super confusing to users, and will likely just cause platform to be abandoned. And a lot of times, ticket list is better off shared, so people can coordinate the work they do even if they have their own fork. Once you realize a lot of supporting services need to be centralized, all you can use "git" for is for data distribution. Is git better than SMTP for mailing list discussions? Is git better that SMTP / REST API for ticket list? Maybe, maybe not. But ultimately it does not matter, because most people do not care about mirroring stuff locally, and those who do care, can already achieve it.