11 ms·

I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed,

by SCdF 1y ago

I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back. Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)

littlestymaar 1y ago
> Everything surrounding code: issues, CICD, etc, is obviously another story That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.
- xboxnolifes 1y ago
  Sure, but then we are no longer talking about git.
- enos_feedler 1y ago
  And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.
  - groestl 1y ago
    > And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. That's how we started out.
    - baq 1y ago
      Maybe that's the reason everything tends to get centralized.
      - groestl 1y ago
        It's an emergent phenomenon, it requires less energy expenditure overall. It's also the way of the Dodo.
  - hnlmorg 1y ago
    As a GitHub user myself, I don’t disagree with your point. However I’d like to say that this isn’t quiet as different a problem to solve as it might first appear: The issue tracking can be a branch and then you just need a compatible UI. In fact some git front ends do exactly this. CI/CD does already exist in git via githooks. And you’re already better off using make/just/yarn/whatever for your scripts and rely as little on YAML as possible. It’s just a pity that githooks require users to set up each time so many people simply don’t bother.
  - int_19h 1y ago
    By storing issues etc in the repo itself. A git repo is just a generic object graph, after all, and objects don't necessarily describe files. There are several such solutions already. The problem is that neither of them is popular enough to become a de facto standard. And, of course, centralized git providers like GitHub have a vested interest in keeping in this way, so they are unlikely to support any such solution even if it does become popular enough.
    - enos_feedler 1y ago
      Wouldn’t it make economic sense for a git host to emerge that just did things this way and collect big pay for it? Gits been around forever and you’re idea sounds simple enough that a market of people would probably choose it on principle. There must be something more fundamental at play here.
- SCdF 1y ago
  Right, but distributed git As Torvalds Intended™ doesn't solve those problems, so it's not related. For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.
  - Flimm 1y ago
    It's impossible to disable PRs on GitHub, sadly. See https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84
    - SCdF 1y ago
      Interestingly mozilla has effectively done this here, by using a GitHub action that automatically closes any PR with a message explaining that PRs are not to be used. It's very silly they have to do this, but at least they can I suppose.
- tigroferoce 1y ago
  GitHub is about the community. There are others alternatives, more in line with what Mozilla claim to be their view (I'm thinking to GitLab, for instance), but nothing gives you visibility like GitHub. Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
- arp242 1y ago
  GitHub has a fairly extensive API without too many limits AFAIK. You can definitely migrate all your data to $something_else if you want to.
- LtWorf 1y ago
  I managed to move to codeberg all my projects. There's everything except the secret deals with pypi to directly publish from github. Which is massively insecure anyway.
sublinear 1y ago
IIRC Phabricator stored most of it's metadata in git-notes. In theory we could have been making tools compatible with such a format all this time.
sshine 1y ago
> if github goes down you could still generate patches and email them around, and then push back to github when it's back. You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository. > Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git) Radicle offers one. CLI-based, too.
- lucianbr 1y ago
  People could learn, if there was suddenly a need. Just like they learned the narrow workflows they use now.
- flohofwoe 1y ago
  > They learn a set of narrow workflows and never explore beyond. And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem. I don't need to know how a filesystem works internally to be able to use it. And having a centralized store and history helps a lot to keep a version control system conceptually simple.
  - vishnugupta 1y ago
    svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.
    - flohofwoe 1y ago
      This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back. Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.
account-5 1y ago
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
- int_19h 1y ago
  The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that. If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
  - account-5 1y ago
    I can certainly see the appeal of having neat commits but I tend not to worry about them. On a couple of occasions, with my university writing, having a immutable history helped me figure out, for example, how something had ended up in a final draft without citation. I'd deleted the citation which was a quick URL paste in a comment block in an earlier draft, and I'd never saved it to zotero. If I'd been able to tidy up my commits I'd likely have lost it completely.
    - int_19h 1y ago
      The appeal depends on how messy your commits are to begin with. When you know that commit history can be rewritten later, it suddenly becomes okay to commit incomplete code that doesn't properly run or even build, effectively using git as an undo system with branching. But the resulting history is completely unsuitable for any future attempt to use `git blame` and such.
frizlab 1y ago
Like fossil?
- kaichanvong 1y ago
  while --it-is possible seeing how fossil confuses, for the Github conversation, it's not really in the same category, conversation, some clever happenings happening within fossil-scm, however, it's not really the same as the problem design-led github solves given people saying downtimes; sure, git, github; however how people using github, different–similar, git, however, github. However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no. Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
  - frizlab 1y ago
    I don’t get any of that. I tried, but no, it just makes no sense.
    - kaichanvong 1y ago
      ;( I feel for you, hopefully–you can get more out from things in the future.
dijit 1y ago
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git) Embrace, Extend.. (largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
- wordofx 1y ago
  Build a bridge and…
- blueflow 1y ago
  Lets pray that Microsoft won't use Github to find new ways to extract money.
rablackburn 1y ago
>> I would love a good issue tracking system that is done entirely inside git You might like git-bug: https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug
- sublinear 1y ago
  Why bury this in the documentation if it's the sole feature its users would care about? https://github.com/git-bug/git-bug/blob/master/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/master/doc/design/da... This should be one of the very first links in the readme.
  - rablackburn 1y ago
    >> ...if it's the sole feature its users would care about? The tag-line covers it pretty well I thought? "git-bug is a standalone, distributed, offline-first issue management tool that embeds issues, comments, and more as objects in a git repository (not files!), enabling you to push and pull them to one or more remotes." That tells you what the feature is - if you need/want a more technical overview you can still get from the `README` to `entity data model` in two clicks (Documentation > Data model).
  - sudoforge 1y ago
    hey there! i maintain git-bug, and recently trimmed down the README, which was, in my opinion, a bit too dense prior to this recent change (https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5ce485f709c3eb82da121a50 https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5c...). i rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc. if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.
Sander_Marechal 1y ago
Gitlab is working on using ActivityPub for interoperability between instances. See: https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/activity_pub/ https://handbook.gitlab.com/handbook/engineering/architectur...
nextaccountic 1y ago
Unfortunately the project is not just code. It also has issues, PRs and other stuff. Github has two kinds of lock in, a) your stuff is there and if you move elsewhere you probably will wipe your issues etc (huge loss of institutional knowledge), and b) there is a network effect because everyone has a github account and people are used to just hop on a repository and file an issue (rather than being greeted by a log in page), cross-reference issues between repositories (hard to make work if repos aren't in the same site, unless both sites use some interop thing like activitypub which github will never use), etc > Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git) There is https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge. Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
- SCdF 1y ago
  > Unfortunately the project is not just code. The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled. https://github.com/mozilla-firefox/firefox https://github.com/mozilla-firefox/firefox
  - elAhmo 1y ago
    What you are referring to is more of a mirror-like approach usage of GitHub. Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.
nicoburns 1y ago
> It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back. You can also quite easily set up a temporary remote (this can be as simple a directory on an SSH server), or if you're on the same local network, pull and push directly from each others' local copies.

by SCdF 1y ago

littlestymaar 1y ago

> Everything surrounding code: issues, CICD, etc, is obviously another story That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.

xboxnolifes 1y ago
Sure, but then we are no longer talking about git.
enos_feedler 1y ago
And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.
- groestl 1y ago
  > And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. That's how we started out.
  - baq 1y ago
    Maybe that's the reason everything tends to get centralized.
    - groestl 1y ago
      It's an emergent phenomenon, it requires less energy expenditure overall. It's also the way of the Dodo.
- hnlmorg 1y ago
  As a GitHub user myself, I don’t disagree with your point. However I’d like to say that this isn’t quiet as different a problem to solve as it might first appear: The issue tracking can be a branch and then you just need a compatible UI. In fact some git front ends do exactly this. CI/CD does already exist in git via githooks. And you’re already better off using make/just/yarn/whatever for your scripts and rely as little on YAML as possible. It’s just a pity that githooks require users to set up each time so many people simply don’t bother.
- int_19h 1y ago
  By storing issues etc in the repo itself. A git repo is just a generic object graph, after all, and objects don't necessarily describe files. There are several such solutions already. The problem is that neither of them is popular enough to become a de facto standard. And, of course, centralized git providers like GitHub have a vested interest in keeping in this way, so they are unlikely to support any such solution even if it does become popular enough.
  - enos_feedler 1y ago
    Wouldn’t it make economic sense for a git host to emerge that just did things this way and collect big pay for it? Gits been around forever and you’re idea sounds simple enough that a market of people would probably choose it on principle. There must be something more fundamental at play here.
SCdF 1y ago
Right, but distributed git As Torvalds Intended™ doesn't solve those problems, so it's not related. For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.
- Flimm 1y ago
  It's impossible to disable PRs on GitHub, sadly. See https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84
  - SCdF 1y ago
    Interestingly mozilla has effectively done this here, by using a GitHub action that automatically closes any PR with a message explaining that PRs are not to be used. It's very silly they have to do this, but at least they can I suppose.
tigroferoce 1y ago
GitHub is about the community. There are others alternatives, more in line with what Mozilla claim to be their view (I'm thinking to GitLab, for instance), but nothing gives you visibility like GitHub. Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
arp242 1y ago
GitHub has a fairly extensive API without too many limits AFAIK. You can definitely migrate all your data to $something_else if you want to.
LtWorf 1y ago
I managed to move to codeberg all my projects. There's everything except the secret deals with pypi to directly publish from github. Which is massively insecure anyway.

sublinear 1y ago

IIRC Phabricator stored most of it's metadata in git-notes. In theory we could have been making tools compatible with such a format all this time.

sshine 1y ago

> if github goes down you could still generate patches and email them around, and then push back to github when it's back. You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository. > Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git) Radicle offers one. CLI-based, too.

lucianbr 1y ago
People could learn, if there was suddenly a need. Just like they learned the narrow workflows they use now.
flohofwoe 1y ago
> They learn a set of narrow workflows and never explore beyond. And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem. I don't need to know how a filesystem works internally to be able to use it. And having a centralized store and history helps a lot to keep a version control system conceptually simple.
- vishnugupta 1y ago
  svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.
  - flohofwoe 1y ago
    This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back. Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.

account-5 1y ago

This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.

int_19h 1y ago
The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that. If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
- account-5 1y ago
  I can certainly see the appeal of having neat commits but I tend not to worry about them. On a couple of occasions, with my university writing, having a immutable history helped me figure out, for example, how something had ended up in a final draft without citation. I'd deleted the citation which was a quick URL paste in a comment block in an earlier draft, and I'd never saved it to zotero. If I'd been able to tidy up my commits I'd likely have lost it completely.
  - int_19h 1y ago
    The appeal depends on how messy your commits are to begin with. When you know that commit history can be rewritten later, it suddenly becomes okay to commit incomplete code that doesn't properly run or even build, effectively using git as an undo system with branching. But the resulting history is completely unsuitable for any future attempt to use `git blame` and such.

frizlab 1y ago

Like fossil?

kaichanvong 1y ago
while --it-is possible seeing how fossil confuses, for the Github conversation, it's not really in the same category, conversation, some clever happenings happening within fossil-scm, however, it's not really the same as the problem design-led github solves given people saying downtimes; sure, git, github; however how people using github, different–similar, git, however, github. However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no. Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
- frizlab 1y ago
  I don’t get any of that. I tried, but no, it just makes no sense.
  - kaichanvong 1y ago
    ;( I feel for you, hopefully–you can get more out from things in the future.

dijit 1y ago

> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git) Embrace, Extend.. (largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).

wordofx 1y ago
Build a bridge and…
blueflow 1y ago
Lets pray that Microsoft won't use Github to find new ways to extract money.

rablackburn 1y ago

>> I would love a good issue tracking system that is done entirely inside git You might like git-bug: https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug

sublinear 1y ago
Why bury this in the documentation if it's the sole feature its users would care about? https://github.com/git-bug/git-bug/blob/master/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/master/doc/design/da... This should be one of the very first links in the readme.
- rablackburn 1y ago
  >> ...if it's the sole feature its users would care about? The tag-line covers it pretty well I thought? "git-bug is a standalone, distributed, offline-first issue management tool that embeds issues, comments, and more as objects in a git repository (not files!), enabling you to push and pull them to one or more remotes." That tells you what the feature is - if you need/want a more technical overview you can still get from the `README` to `entity data model` in two clicks (Documentation > Data model).
- sudoforge 1y ago
  hey there! i maintain git-bug, and recently trimmed down the README, which was, in my opinion, a bit too dense prior to this recent change (https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5ce485f709c3eb82da121a50 https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5c...). i rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc. if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.

Sander_Marechal 1y ago

Gitlab is working on using ActivityPub for interoperability between instances. See: https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/activity_pub/ https://handbook.gitlab.com/handbook/engineering/architectur...

nextaccountic 1y ago

Unfortunately the project is not just code. It also has issues, PRs and other stuff. Github has two kinds of lock in, a) your stuff is there and if you move elsewhere you probably will wipe your issues etc (huge loss of institutional knowledge), and b) there is a network effect because everyone has a github account and people are used to just hop on a repository and file an issue (rather than being greeted by a log in page), cross-reference issues between repositories (hard to make work if repos aren't in the same site, unless both sites use some interop thing like activitypub which github will never use), etc > Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git) There is https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge. Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs

SCdF 1y ago
> Unfortunately the project is not just code. The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled. https://github.com/mozilla-firefox/firefox https://github.com/mozilla-firefox/firefox
- elAhmo 1y ago
  What you are referring to is more of a mirror-like approach usage of GitHub. Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.

nicoburns 1y ago

> It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back. You can also quite easily set up a temporary remote (this can be as simple a directory on an SSH server), or if you're on the same local network, pull and push directly from each others' local copies.