7 ms·

It's almost as if only Git is distributed, but people sold out to Github for convenience. Too bad Git lacks a distributed bug tracker and wiki system like Fossi

by crest 2y ago

It's almost as if only Git is distributed, but people sold out to Github for convenience. Too bad Git lacks a distributed bug tracker and wiki system like Fossil. Guess Github has to fail a lot more for things to change.

bastardoperator 2y ago
It's this type of negativity ruining the internet. Nothing thoughtful to say, nothing to add, and hoping for failure. I hope everything is okay over there...
- liontwist 2y ago
  They are advocating for decentralized tools. That’s actionable and hoping to prevent failure.
  - vv_ 2y ago
    There is no reason to host 'decentralized' tools besides regulation. It's considerably cheaper to use GitHub (or other alternatives like GitLab) than hosting your own and hiring people to maintain and support the solution. Their issue tracking system is very convenient for small teams too.
    - bastardoperator 2y ago
      Exactly, hire a team of 3 and pay 500K in compensation, or spend 100K on a system that works and you get a support person to call in the event of an issue. The math is so simple.
      - liontwist 2y ago
        Except you’re not considering the cost of when you can’t deliver something on time for a customer because infrastructure you don’t control is down. You don’t outsource things that prevent you from doing your core competency.
        bastardoperator 2y ago
        And for most companies, building and managing an SCM is absolutely not their core competency. Your point is valid, but not in the way you're trying to convey it.
        liontwist 2y ago
        > building and managing an SCM is absolutely not their core competency. Building their software is - Github being down is currently preventing that for many companies.
        bastardoperator 2y ago
        Nope, sorry. Github offers cloud and on premise offerings. If you choose cloud and your company can't handle a 45 minute service outage, that's just a bad purchasing decision. You do realize they make most of their revenue from on premise enterprise customers and that none of those customers were impacted? The solution was there the entire time but they can't force people to use it.
        vv_ 2y ago
        It's surreal to imagine most companies not being able to handle a 45-min service outage of a VCS to begin with. Sounds to me like a GitHub mandated break for all SE 's.
        vv_ 2y ago
        The costs would be trivial for the vast majority of Software Engineering companies. Talking about corner cases is useless as they often need a custom specialized solution anyways and wouldn't be using GitHub in the first place.
    - liontwist 2y ago
      > It's considerably cheaper to us This is not true. The cheapest option is to not have services that require servers to maintain. Git continues to work if GitHub is down. So do shell scripts when CI is down. So why can’t we have an issue system where the underlying data is text files in a git branch? I understand at scale you can pay people to optimize a process for the larger team, but there is a ton of unnecessary fragility before getting to that scale.
      - vv_ 2y ago
        If you're collaborating with a small group of people (or you're not running a huge amount of CI/CD) then you can make almost anything work. Once you get big it's another story entirely.
- Over2Chars 2y ago
  You're quite a Mary Poppins for someone with the heavy handle of @bastardoperator. AFAICT the internet was built on negativity. Here's the 2nd post from a random USENET group I found: https://www.usenetarchives.com/view.php?id=comp&mid=PDQ5ajZpdSRhdWlAbmV0cG9ydC5jb20%2B https://www.usenetarchives.com/view.php?id=comp&mid=PDQ5ajZp...
- Dylan16807 2y ago
  They want people motivated to design systems that can handle github going down. That doesn't strike me as negativity, and especially not negativity ruining the internet. It's not the most thoughtful thing in the world but it's a reasonable opinion, and most comments are also not the most thoughtful things in the world.
sixo 2y ago
people could not be more clear that their preference is for reliable and easy-to-use centralized services maintained by professionals, and not decentralized systems that require a great deal of user expertise
- deleted 2y ago
  [deleted]
- ajross 2y ago
  Ironically github is sort of the exception that proves the rule: decentralized in the one way that really matters (decoupled development on individual systems), but centralized for easy interaction in the way the market demands.
  - TZubiri 2y ago
    Similar thing that happens with crypto exchanges, also swift transfers and federal states for that matter.
    - eru 2y ago
      Yes, subsidiarity is a great principle.. in-principle, but in practice it often gets the curb. See https://en.wikipedia.org/wiki/Subsidiarity https://en.wikipedia.org/wiki/Subsidiarity So far, having individual small countries seems to keep the centralisation at bay for longer than just having states in a federation. (Look at Germany, Austria, Australia, the USA for examples of the latter. Interestingly, the UK is legally not made of federal states, but in practice they have granted more autonomy to eg Scotland over the years. And everyone knows that Scotland would secede and get away with it, if there was a power grab by London. In that sense, they are more federal than the US, where secession is very much verboten.)
  - nine_k 2y ago
    But it demands both. The ability to develop in a parallel, decentralized way, and the ability to integrate things at a central point, an authoritative source and a blessed official destination. It's similar to how databases allow to begin parallel, concurrent, even contradictory transactions, and also guarantee serialized, consistent database state, and rejection of invalid updates, at commit time. Both aspects are utterly important.
koito17 2y ago
I've been keeping an eye on radicle[1] but the documentation for setting up a peer and web frontend is a bit complex. It seems to offer what you're describing: a "decentralized" Git frontend with issue tracking. Seems to be missing wiki functionality, however. [1] https://radicle.xyz/ https://radicle.xyz/
whalesalad 2y ago
The GitHub wikis are actually git repos.
- remram 2y ago
  I forgot about that, I wonder if they were broken too.
joecool1029 2y ago
> Too bad Git lacks a distributed bug tracker Email and mailing lists?
- Groxx 2y ago
  That's the same as not having one. Otherwise you can claim Facebook is distributed because you can email people links to Facebook pages.
  - TZubiri 2y ago
    But git has built in email features And it was developed itself by email.
  - lucasoshiro 2y ago
    > That's the same as not having one. That's the way the Linux kernel (the first Git repository) and Git [2] itself manage their codes. There's even a git send-email command, that prepare the commits as patches and send them following the using the correct template. [1] Linux kernel, IIO subsystem: https://lore.kernel.org/linux-iio/ https://lore.kernel.org/linux-iio/ [2] Git mailing list: https://lore.kernel.org/git/ https://lore.kernel.org/git/
    - Groxx 2y ago
      I agree that Git has more of a claim to this than Facebook, but that's kinda like saying a turtle is more of a car than a banana is a car. Like, yes, it's true. Unlike a banana, turtles have 4 movement-enabling things, they use them to move mostly forward and backwards and not sideways, and other things can ride on them. It's probably more of a car. But it's not a car. Git has no issue tracker. It's really not a controversial statement. The git community has common practices using something else to work around that, but if that's all you need to say "therefore git has X" then you can claim git has a CI framework because everyone and their dog uses GitHub. Which also has email integrations.
      - confooseddd 2y ago
tomnicholas1 2y ago
Is there a world in which GitHub used an open protocol for the social network part of their product like BlueSky's AT protocol[0]? [0] https://docs.bsky.app/docs/advanced-guides/atproto https://docs.bsky.app/docs/advanced-guides/atproto
- NetOpWibby 2y ago
  ...this is an interesting thought exercise, thank you.
- theultdev 2y ago
  not p2p, but federated: https://forgefed.org https://forgefed.org (ActivityPub extension) I believe Gitea has support for it, not sure to what extent.
  - codetrotter 2y ago
    Forgejo, a Gitea fork that I use, has support for it according to the page you linked. But the FAQ for Forgejo mentions it's on the roadmap so not sure how complete ActivityPub support is in Forgejo either. https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo I only use my Forgejo instance for myself currently so I haven't looked at the ActivityPub features of it before.
  - bramhaag 2y ago
    Forgejo (Gitea fork) has been working for multiple years to add support for this. It will still take a lot of effort to finish, I doubt we will see anything usable this year. Originally the plan was to PR the federation support to Gitea as well. I'm not sure if this is still the case, considering the rising tensions between the two projects and the fact that Forgejo is now a hard fork.
nine_k 2y ago
Yes, conveniences like: - A canonical name and place on the web; - Access policy enforcement (who can commit and when); - The whole pull request thing, with tags, issues, review, discussion, etc linked to it; - Code review, linked to said policy enforcement; - Issue tracking, even as basic as what GitHub offers; - A trusted store for signing keys, so commits are verified; - CI/CD triggers and runners; - A page with releases, including binary releases, and a CDN allowing to use the download links without fear. This is way more than distrusted version tracking. Actually the above is not even married to Git; it could be as valuable with Mercurial, or even Perforce. This is a large product, actually a combination of many potentially self-contained products. It should not be compared to Git, but rather to Gitea or BitBucket. Not all of this can be reasonably decentralized, though quite a bit can.
- eru 2y ago
  > - Access policy enforcement (who can commit and when); Interestingly, what GitHub mostly enforces is where your branches point to. Not who can make commits. That's mostly because of how git works, not because of any grand design on GitHub's part.
  - nine_k 2y ago
    It controls who can push commits to the main branch hosted by GitHub (and other branches if you want to configure that). You can have OWNERS files to control who can push commits touching particular parts of the tree, or who must approve such a push / merge (see "pull request"). Out of the box, git does not offer that, and this does require a single point of enforcement.
    - eru 2y ago
      My point is that in git branches are just mutable pointers to commits. Tags are internally nearly the same, but socially they are meant to be immutable. Anyone can make any commit they want in git. That includes merge commits, too. GitHub mostly lets anyone push any commits they feel like, too. (What restrictions are there on pushing commits is mostly to deal with denial of service and people being a nuisance.) Where the policing comes in is in giving rules for how these pointers (aka branches) can be mutated. OWNERS files, PR reviews, CI automation etc is all about controlling that mutation. See also the new-ish merge queues[0], which really bring out that difference: the merge queue machinery makes the merge commit of your approved PR branch with 'main', runs the CI against that, and iff that passes, moves the pointer that is 'main' to point to the newly created commit. It's exactly the same commit (with exactly the same hash), whether it passes the CI or not. The only difference is in whether it gets the official blessing of being pointed to by the official 'main'. It really speaks to the design of git, that conceptually the only thing they need to lock down is who can mutate this very small amount of data, these handfuls of pointers. Everything else is (conceptually) immutable, and thus you don't need to care about who can eg make commits. [0] Really a re-implementation of bors-ng.
tokioyoyo 2y ago
People said that when GitHub got bought out, and only more people ended up moving there. It's really not fun to manage your own Git servers, and when things go down, they get fixed much slower than in-house hosted version of it.
adamtaylor_13 2y ago
I don’t know anyone beyond hobbyist hackers who want to set up and maintain this stuff for themselves. As a professional software developer, I want tools that just work that I can rely on. GitHub 99.99% uptime is something I can rely on.
- TZubiri 2y ago
  As a professional software developer, you rely on software written by those hobbyist hackers. Whenever you do a clone or an npm install or apt get or pip install, etc... You choose github because your dependencies chose git
  - eru 2y ago
    Sure, but as you say those hobbyist developers aren't responsible for keeping a specific server up. They are 'just' writing some software. (And even among professionals, there's a big difference between Site Reliability Engineering and Software Engineering.)
    - deleted 2y ago
      [deleted]
- fragmede 2y ago
  It was down for ~45 mins according to the linked page page, which would put it at 99.897% uptime for the month, assuming no other downtime.
  - eru 2y ago
    They had some more downtime a few days ago, too. And that's just the one I happened to notice.
  - ikiris 2y ago
    And if your central hub for your distributed vcs needs more than 2-3 9s of uptime for your service to be reliable, honestly you’ve done something really wrong in the design phase like using version control as a database.
TZubiri 2y ago
Contrary to popular belief, sarcasm makes you harder to understand and is no longer cool
kspacewalk2 2y ago
Counterpoint: it's a 45 minute outage once in a blue moon. Very small price to pay for the convenience of a centralized VCS with many features that aren't easy to reliably set up in standalone installations.
- vrosas 2y ago
  Once in a blue moon? It’s like, monthly at best.
  - Idneedagun 2y ago
    Well, despite our intents, we may have established the moon might be blue then.
  - kspacewalk2 2y ago
    When was the last time you noticed? Not saw a HN post, but it actually stopped you from pushing commits or commenting on an issue or whatever?
    - saagarjha 2y ago
      Today ;)
  - doublepg23 2y ago
    Once a full moon maybe? There's one tonight.
freewizard 2y ago
Git is distributed. Distributed system does not guarantee 100% uptime or real time consistency. You can take the whole history with you and push to a different remote.
xelxebar 2y ago
> Too bad Git lacks a distributed bug tracker Not your point, really, but fortunately, git is easily extensible. This in-repo issue tracker is surprisingly feature complete: https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug. Anyone else given it a whirl?
nextaccountic 2y ago
> Too bad Git lacks a distributed bug tracker Well there is https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug
evbogue 2y ago
Makes me wish for the good old days of git-ssb
tracerbulletx 2y ago
I mean I could very easily still push to another remote until it comes back? I do not feel locked in at all.
paulddraper 2y ago
Convenience is nice.
XorNot 2y ago
git was never really decentralized though. The whole system is aggressively a funnel towards central repositories, it's just that because it deals in whole repos, every git repo has the potential to be promoted to that role. Nothing is built into git to let it actually run decentralized: there's no server or protocol where someone can register say, an identifying public key and then just have a network of peers all communicate updates to each other. It's even pretty damn unsafe to just run a repo through basic file-sync (I do this for myself with syncthing with bare repos in a special folder, which seems to work fine but I'm hardly loading it up to chase down why it doesn't).
never_inline 2y ago
If you have a local development setup, few hours of not being able to push should be a not problem most devs. Except if you have a release planned but most don't at that time, statistically. Problem is that people get comfortable with pushing to branch -> deploying in dev and testing from there.

by crest 2y ago

bastardoperator 2y ago

It's this type of negativity ruining the internet. Nothing thoughtful to say, nothing to add, and hoping for failure. I hope everything is okay over there...

liontwist 2y ago
They are advocating for decentralized tools. That’s actionable and hoping to prevent failure.
- vv_ 2y ago
  There is no reason to host 'decentralized' tools besides regulation. It's considerably cheaper to use GitHub (or other alternatives like GitLab) than hosting your own and hiring people to maintain and support the solution. Their issue tracking system is very convenient for small teams too.
  - bastardoperator 2y ago
    Exactly, hire a team of 3 and pay 500K in compensation, or spend 100K on a system that works and you get a support person to call in the event of an issue. The math is so simple.
    - liontwist 2y ago
      Except you’re not considering the cost of when you can’t deliver something on time for a customer because infrastructure you don’t control is down. You don’t outsource things that prevent you from doing your core competency.
      - bastardoperator 2y ago
        And for most companies, building and managing an SCM is absolutely not their core competency. Your point is valid, but not in the way you're trying to convey it.
        liontwist 2y ago
        > building and managing an SCM is absolutely not their core competency. Building their software is - Github being down is currently preventing that for many companies.
        bastardoperator 2y ago
        Nope, sorry. Github offers cloud and on premise offerings. If you choose cloud and your company can't handle a 45 minute service outage, that's just a bad purchasing decision. You do realize they make most of their revenue from on premise enterprise customers and that none of those customers were impacted? The solution was there the entire time but they can't force people to use it.
        vv_ 2y ago
        It's surreal to imagine most companies not being able to handle a 45-min service outage of a VCS to begin with. Sounds to me like a GitHub mandated break for all SE 's.
      - vv_ 2y ago
        The costs would be trivial for the vast majority of Software Engineering companies. Talking about corner cases is useless as they often need a custom specialized solution anyways and wouldn't be using GitHub in the first place.
  - liontwist 2y ago
    > It's considerably cheaper to us This is not true. The cheapest option is to not have services that require servers to maintain. Git continues to work if GitHub is down. So do shell scripts when CI is down. So why can’t we have an issue system where the underlying data is text files in a git branch? I understand at scale you can pay people to optimize a process for the larger team, but there is a ton of unnecessary fragility before getting to that scale.
    - vv_ 2y ago
      If you're collaborating with a small group of people (or you're not running a huge amount of CI/CD) then you can make almost anything work. Once you get big it's another story entirely.
Over2Chars 2y ago
You're quite a Mary Poppins for someone with the heavy handle of @bastardoperator. AFAICT the internet was built on negativity. Here's the 2nd post from a random USENET group I found: https://www.usenetarchives.com/view.php?id=comp&mid=PDQ5ajZpdSRhdWlAbmV0cG9ydC5jb20%2B https://www.usenetarchives.com/view.php?id=comp&mid=PDQ5ajZp...
Dylan16807 2y ago
They want people motivated to design systems that can handle github going down. That doesn't strike me as negativity, and especially not negativity ruining the internet. It's not the most thoughtful thing in the world but it's a reasonable opinion, and most comments are also not the most thoughtful things in the world.

sixo 2y ago

people could not be more clear that their preference is for reliable and easy-to-use centralized services maintained by professionals, and not decentralized systems that require a great deal of user expertise

deleted 2y ago
[deleted]
ajross 2y ago
Ironically github is sort of the exception that proves the rule: decentralized in the one way that really matters (decoupled development on individual systems), but centralized for easy interaction in the way the market demands.
- TZubiri 2y ago
  Similar thing that happens with crypto exchanges, also swift transfers and federal states for that matter.
  - eru 2y ago
    Yes, subsidiarity is a great principle.. in-principle, but in practice it often gets the curb. See https://en.wikipedia.org/wiki/Subsidiarity https://en.wikipedia.org/wiki/Subsidiarity So far, having individual small countries seems to keep the centralisation at bay for longer than just having states in a federation. (Look at Germany, Austria, Australia, the USA for examples of the latter. Interestingly, the UK is legally not made of federal states, but in practice they have granted more autonomy to eg Scotland over the years. And everyone knows that Scotland would secede and get away with it, if there was a power grab by London. In that sense, they are more federal than the US, where secession is very much verboten.)
- nine_k 2y ago
  But it demands both. The ability to develop in a parallel, decentralized way, and the ability to integrate things at a central point, an authoritative source and a blessed official destination. It's similar to how databases allow to begin parallel, concurrent, even contradictory transactions, and also guarantee serialized, consistent database state, and rejection of invalid updates, at commit time. Both aspects are utterly important.

koito17 2y ago

I've been keeping an eye on radicle[1] but the documentation for setting up a peer and web frontend is a bit complex. It seems to offer what you're describing: a "decentralized" Git frontend with issue tracking. Seems to be missing wiki functionality, however. [1] https://radicle.xyz/ https://radicle.xyz/

whalesalad 2y ago

The GitHub wikis are actually git repos.

remram 2y ago
I forgot about that, I wonder if they were broken too.

joecool1029 2y ago

> Too bad Git lacks a distributed bug tracker Email and mailing lists?

Groxx 2y ago
That's the same as not having one. Otherwise you can claim Facebook is distributed because you can email people links to Facebook pages.
- TZubiri 2y ago
  But git has built in email features And it was developed itself by email.
- lucasoshiro 2y ago
  > That's the same as not having one. That's the way the Linux kernel (the first Git repository) and Git [2] itself manage their codes. There's even a git send-email command, that prepare the commits as patches and send them following the using the correct template. [1] Linux kernel, IIO subsystem: https://lore.kernel.org/linux-iio/ https://lore.kernel.org/linux-iio/ [2] Git mailing list: https://lore.kernel.org/git/ https://lore.kernel.org/git/
  - Groxx 2y ago
    I agree that Git has more of a claim to this than Facebook, but that's kinda like saying a turtle is more of a car than a banana is a car. Like, yes, it's true. Unlike a banana, turtles have 4 movement-enabling things, they use them to move mostly forward and backwards and not sideways, and other things can ride on them. It's probably more of a car. But it's not a car. Git has no issue tracker. It's really not a controversial statement. The git community has common practices using something else to work around that, but if that's all you need to say "therefore git has X" then you can claim git has a CI framework because everyone and their dog uses GitHub. Which also has email integrations.
    - confooseddd 2y ago

tomnicholas1 2y ago

Is there a world in which GitHub used an open protocol for the social network part of their product like BlueSky's AT protocol[0]? [0] https://docs.bsky.app/docs/advanced-guides/atproto https://docs.bsky.app/docs/advanced-guides/atproto

NetOpWibby 2y ago
...this is an interesting thought exercise, thank you.
theultdev 2y ago
not p2p, but federated: https://forgefed.org https://forgefed.org (ActivityPub extension) I believe Gitea has support for it, not sure to what extent.
- codetrotter 2y ago
  Forgejo, a Gitea fork that I use, has support for it according to the page you linked. But the FAQ for Forgejo mentions it's on the roadmap so not sure how complete ActivityPub support is in Forgejo either. https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo I only use my Forgejo instance for myself currently so I haven't looked at the ActivityPub features of it before.
- bramhaag 2y ago
  Forgejo (Gitea fork) has been working for multiple years to add support for this. It will still take a lot of effort to finish, I doubt we will see anything usable this year. Originally the plan was to PR the federation support to Gitea as well. I'm not sure if this is still the case, considering the rising tensions between the two projects and the fact that Forgejo is now a hard fork.

nine_k 2y ago

Yes, conveniences like: - A canonical name and place on the web; - Access policy enforcement (who can commit and when); - The whole pull request thing, with tags, issues, review, discussion, etc linked to it; - Code review, linked to said policy enforcement; - Issue tracking, even as basic as what GitHub offers; - A trusted store for signing keys, so commits are verified; - CI/CD triggers and runners; - A page with releases, including binary releases, and a CDN allowing to use the download links without fear. This is way more than distrusted version tracking. Actually the above is not even married to Git; it could be as valuable with Mercurial, or even Perforce. This is a large product, actually a combination of many potentially self-contained products. It should not be compared to Git, but rather to Gitea or BitBucket. Not all of this can be reasonably decentralized, though quite a bit can.

eru 2y ago
> - Access policy enforcement (who can commit and when); Interestingly, what GitHub mostly enforces is where your branches point to. Not who can make commits. That's mostly because of how git works, not because of any grand design on GitHub's part.
- nine_k 2y ago
  It controls who can push commits to the main branch hosted by GitHub (and other branches if you want to configure that). You can have OWNERS files to control who can push commits touching particular parts of the tree, or who must approve such a push / merge (see "pull request"). Out of the box, git does not offer that, and this does require a single point of enforcement.
  - eru 2y ago
    My point is that in git branches are just mutable pointers to commits. Tags are internally nearly the same, but socially they are meant to be immutable. Anyone can make any commit they want in git. That includes merge commits, too. GitHub mostly lets anyone push any commits they feel like, too. (What restrictions are there on pushing commits is mostly to deal with denial of service and people being a nuisance.) Where the policing comes in is in giving rules for how these pointers (aka branches) can be mutated. OWNERS files, PR reviews, CI automation etc is all about controlling that mutation. See also the new-ish merge queues[0], which really bring out that difference: the merge queue machinery makes the merge commit of your approved PR branch with 'main', runs the CI against that, and iff that passes, moves the pointer that is 'main' to point to the newly created commit. It's exactly the same commit (with exactly the same hash), whether it passes the CI or not. The only difference is in whether it gets the official blessing of being pointed to by the official 'main'. It really speaks to the design of git, that conceptually the only thing they need to lock down is who can mutate this very small amount of data, these handfuls of pointers. Everything else is (conceptually) immutable, and thus you don't need to care about who can eg make commits. [0] Really a re-implementation of bors-ng.

tokioyoyo 2y ago

People said that when GitHub got bought out, and only more people ended up moving there. It's really not fun to manage your own Git servers, and when things go down, they get fixed much slower than in-house hosted version of it.

adamtaylor_13 2y ago

I don’t know anyone beyond hobbyist hackers who want to set up and maintain this stuff for themselves. As a professional software developer, I want tools that just work that I can rely on. GitHub 99.99% uptime is something I can rely on.

TZubiri 2y ago
As a professional software developer, you rely on software written by those hobbyist hackers. Whenever you do a clone or an npm install or apt get or pip install, etc... You choose github because your dependencies chose git
- eru 2y ago
  Sure, but as you say those hobbyist developers aren't responsible for keeping a specific server up. They are 'just' writing some software. (And even among professionals, there's a big difference between Site Reliability Engineering and Software Engineering.)
  - deleted 2y ago
    [deleted]
fragmede 2y ago
It was down for ~45 mins according to the linked page page, which would put it at 99.897% uptime for the month, assuming no other downtime.
- eru 2y ago
  They had some more downtime a few days ago, too. And that's just the one I happened to notice.
- ikiris 2y ago
  And if your central hub for your distributed vcs needs more than 2-3 9s of uptime for your service to be reliable, honestly you’ve done something really wrong in the design phase like using version control as a database.

TZubiri 2y ago

Contrary to popular belief, sarcasm makes you harder to understand and is no longer cool

kspacewalk2 2y ago

Counterpoint: it's a 45 minute outage once in a blue moon. Very small price to pay for the convenience of a centralized VCS with many features that aren't easy to reliably set up in standalone installations.

vrosas 2y ago
Once in a blue moon? It’s like, monthly at best.
- Idneedagun 2y ago
  Well, despite our intents, we may have established the moon might be blue then.
- kspacewalk2 2y ago
  When was the last time you noticed? Not saw a HN post, but it actually stopped you from pushing commits or commenting on an issue or whatever?
  - saagarjha 2y ago
    Today ;)
- doublepg23 2y ago
  Once a full moon maybe? There's one tonight.

freewizard 2y ago

Git is distributed. Distributed system does not guarantee 100% uptime or real time consistency. You can take the whole history with you and push to a different remote.

xelxebar 2y ago

> Too bad Git lacks a distributed bug tracker Not your point, really, but fortunately, git is easily extensible. This in-repo issue tracker is surprisingly feature complete: https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug. Anyone else given it a whirl?

nextaccountic 2y ago

> Too bad Git lacks a distributed bug tracker Well there is https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug

evbogue 2y ago

Makes me wish for the good old days of git-ssb

tracerbulletx 2y ago

I mean I could very easily still push to another remote until it comes back? I do not feel locked in at all.

paulddraper 2y ago

Convenience is nice.

XorNot 2y ago

git was never really decentralized though. The whole system is aggressively a funnel towards central repositories, it's just that because it deals in whole repos, every git repo has the potential to be promoted to that role. Nothing is built into git to let it actually run decentralized: there's no server or protocol where someone can register say, an identifying public key and then just have a network of peers all communicate updates to each other. It's even pretty damn unsafe to just run a repo through basic file-sync (I do this for myself with syncthing with bare repos in a special folder, which seems to work fine but I'm hardly loading it up to chase down why it doesn't).

never_inline 2y ago

If you have a local development setup, few hours of not being able to push should be a not problem most devs. Except if you have a release planned but most don't at that time, statistically. Problem is that people get comfortable with pushing to branch -> deploying in dev and testing from there.