zlacker

Kind of funny that despite its users using a DVCS, a huge swath of developers can't VCS because a single point of failure they've opted into.

>>pengar+(OP)
Github is more than a Git repository host. It provides other services for coordinating software development as well as a continuous integration service.

>>pengar+(OP)
I hear what you're saying, and probably a large number of developers are just shrugging and thinking, "let me know when it's back up".

But remember, that also a large part of what github offers is not directly available in git. e.g. pull requests, issues, wiki, continuous xyz, etc. A lot of planning activities and "tell me what I need to do next" kind of things are not tracked in git itself (of course).

So there's more to it than just the quip, "git is a distributed version control system". The whole value of github is more than just git commits.

>>neodyp+M
I actually don’t know how they do continuous integration during the collaborative Kernel development process. I’d guess there would be some thrifty pop/imap Perl hacks involved on random machines all across the globe?

No clue at all, just some romantic fantasy I just concocted.

>>pengar+(OP)
I'd say the git part is doing it's job exactly as intended. Everyone still has their local copies and can even keep working while the site is down. They are VCSing just fine.

Although you are right in that they would be VCSing even better if they were using email as originally envisioned.

>>neodyp+M
So outages, which are recurring more and more often, adversely effects not just the DVCS, but also now CI/CD, and another things which used to be done with emails or chat rooms. Where there were multiple options for each, we now have a bunch of people handicapped because the One True Way to integrate under MSFT's watchful gaze is lost... Basically, those additional services are a bit like the offer to chew up the meat for "avid" eaters.

>>musha6+i2
Greg Kroah-Hartman had a great interview on the Linux Foundation youtube channel about CI and other related development topics:

https://www.youtube.com/watch?v=YhDVC7-QgkI

One site that he mentioned was https://kernelci.org/ and the dashboard https://linux.kernelci.org/

>>barkin+B4
Thanks for the resources, looking very interesting and will get into right after I sent out some patches via email ;)

>>pengar+(OP)
IMHO, most users of git don't care about the D, they just want a VCS that does network operations faster (CVS and SVN are painful when your server is on the wrong continent) and/or supports a better fork/merge flow.

Centralized VCS makes a lot of sense in a corporate flow, and isn't awful for many projects. I haven't seen a lot of projects that really embrace the distributed nature of git.

>>taftst+C1
Fossil (from sqlite ppl) has it.

[0] https://fossil-scm.org

>>pengar+(OP)
Meh. We can all keep committing/branching/etc locally. Tons of other options to work around it to keep collaborating, too, but ramp-up time is likely to exceed the duration of the outage. Less "can't" than "isn't worth bothering".

>>toast0+d8
Git was a lot better than svn when working on the train. Create some commits while riding to the job, and push them while in meetings

>>toast0+d8
I figure plenty of people wouldn't really mind if you left out the decentralized part specifically, but I assumed a bunch of nice things about git are there because they were basically required for a decent decentralized workflow.

>>taftst+C1
> But remember, that also a large part of what github offers is not directly available in git. e.g. pull requests [...]

Some of the earliest features and subcommands in Git were for generating and consuming patches sent and received via e-mail. Git can even send e-mail messages itself; see git-send-email(1). On open source mailing-lists when you see a long series of posts with subject prefixes like '[foo 1/7]', it's likely that series is being sent by the send-email subcommand, directly or indirectly.

While I've long known that Git has such capabilities, was originally designed around the LKML workflow, and that many traditionally managed open source projects employ that workflow on both ends (sender and receiver), I've never used this feature myself, even though I actually host my own e-mail as well as my own Git repositories.[1] In fact it was only the other day while reading the musl-libc mailing list when it clicked that multiple contributors had been pushing and discussing patches this way--specifically using the built-in subcommands as opposed to manually shuttling patches to and from their e-mail client--even though I've been subscribed to and following that mailing list for years.

The open source community has come to lean too heavily on Github and Gitlab-style, web-based pull request workflows. It's not good for the long-term health of open source as these workflows are tailor made for vendor lock-in, notwithstanding that Github and Gitlab haven't yet abused this potential. Issue ticket management is a legitimate sore point for self hosting open source projects. But Git's patch sharing capabilities are sophisticated and useful and can even be used over channels like IRC or ad hoc web forums, not simply via personal e-mail or group mailing-lists.

[1] Little known fact: you can host read-only Git repositories over HTTP statically, without any special server-side software. The git update-server-info subcommand generates auxiliary files in a bare repository that the git client automatically knows to look for when cloning over HTTP. While I use SSH to push into private Git repositories, each private Git repository has a post-receive hook that does `(cd "${M}" && git fetch && git --bare update-server-info)`, where '${M}' is a bare Git mirror[2] underneath the document root for the local HTTP server. (I would never run a git protocol daemon on my personal server; those and other niche application servers are security nightmares. But serving static files over HTTP is about as safe and foolproof as you can get.)

[2] See git clone --mirror (https://git-scm.com/docs/git-clone#Documentation/git-clone.t...)

EDIT: Regarding note #1, in principle one could implement a web-based Git repository browser that is implemented purely client-side. Using WASM one could probably quickly hack pre-existing server-side applications like gitweb to work this way, or at least make use of libgit2 for a low-level repository interface. If I could retire tomorrow, this is a project that would be at the top of my list.

>>wahern+gr1
Thank you for the thorough and enlightening reply. I should have revised my statement to be something more like, "... what github offers is not traditionally utilized in git", because you're right, git doesn't need github, even for workflow related things. It's just that not too many teams utilize a pure git solution, probably just because it's not visual enough perhaps. Thanks again for your thoughts.