Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
replies(29):
Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email 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)
Everything is fully and completely explained, in terms which mean nothing.
It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.
Didn't all this start with Linus getting into a spat with the bitkeeper dev involving some sort of punitive measure as a response to somebody making a reverse-engineered FOSS client? I don't remember the details and I'm sure I have at least half of them wrong, but that's easily one of the most disastrous decisions in the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
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.
Also, git store the files in a smarter way so file size won't explode like zip versioning.
Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
I am contributing to a few open source projects on GitHub here and there though.
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.
People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.
And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally and committing locally and preparing the change set for review. In the CVS/SVN days one had to commit to the ce teal branch way sooner and more direct.
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.
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.
Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.
It wont be free software and, likely, it will be Microsoft.
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).
You might like git-bug:
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
Edit: ripgrep was just a test
More: https://github.blog/engineering/the-technology-behind-github...
That's the default. But git would work just as well, if by default it was only cloning master, or even only the last few commits from master instead of the full history.
You can get that behaviour today, with some options. But we can imagine an alternate universe were the defaults were different.
Most of what you say, eg about not needing lockfiles and being able to make independent offline commits, still applies.
And I am one of the people saddened by the convergence on a single platform.
But you can't deny, it's always been pretty great.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
From what I use composer and brew relies on GitHub to work.
> 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 - 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
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!
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
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.
The thing is, we could have done better (and have been) since before git even existed.
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.
https://github.com/git-bug/git-bug/blob/master/doc/usage/thi...
I have not tried it.
It's very silly they have to do this, but at least they can I suppose.
We used TortoiseSVN as UI which worked well both for devs and non-devs.
With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).
I store my code in a completely distributed fashion, often in several places on different local devices (laptop, build server, backup, etc) not to mention on remote systems. I use github and gitlab for backup and distribution purposes, as well as alternative ways people can share code with me (other than sending patch emails), and other people use git to get and collaborate on my work.
distributed version control system doesn't mean distributed storage magically happens. You still need to store your code on storage you trust at some level. The distributed in DVCS means that collaboration and change management is distributed. All version control operations can be performed on your own copy of a tree with no other involvement. Person A can collaborate with person B, then person B can collaborate with person C without person A being in the loop, etc.
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.
Note we’re talking about the GitHub UI mostly. Pulling and merging a remote branch is a basic git operation, almost a primitive.
And it was actually part of git. Even back in 2005, git included a script git request pull that generated these pull request emails. I'm pretty sure people called these emails "pull requests" before GitHub came along.
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.
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.
Not only results are incomplete but it seems once they went into training LLMs on all code they host they made sure no one else can do the same easily and so now everything is madly rate limited.
Every time I just clone and grep.
The general issue that git has is making them interact with each other, I would love for git to get distributed issues, and a nice client UI that is actually graphical and usable by non-terminal users.
There were some attempts to make this distributed and discoverable via similar seed architectures like a DHT. For example, radicle comes to mind.
But staying in sync with hundreds of remotes and hundreds of branches is generally not what git is good at. All UIs aren't made for this.
I'm pointing this out because I am still trying to build a UI for this [1] which turned out to be much more painful than expected initially.
"In astronomy, declination (abbreviated dec; symbol δ) is one of the two angles that locate a point on the celestial sphere in the equatorial coordinate system, the other being hour angle. The declination angle is measured north (positive) or south (negative) of the celestial equator, along the hour circle passing through the point in question."
Anyone who doesn't know what declination is, know from reading the introductory paragraph of this scientific Wikipedia article?
Anyone? no? :-)
I rest my case, m'lud.
Why should this be a metric one would want Wikipedia to meet? It's an encyclopedia, not an astronomy course.
Of course, the brilliance of Wikipedia is that if you think you can write a clearer intro, you can do so! You could even add it to the simple language version of the page - https://simple.wikipedia.org/wiki/Declination
But GH's PR process is broken anyways. I miss Gerritt.
It's not my favourite process, but...
This should be one of the very first links in the readme.
2006 appears to be the year that SVN finally became somewhat mainstream, which is interesting because git was released in 2005. Github launched in 2008 and by 2009, everyone seemed to be abandoning SVN.
It feels like SVN was only really "mainstream" for about 3 years, Maybe 5 years at most; There was some early-adopter lead-up and then a long tail of repos refusing to switch to git.
On a celestial sphere (planet, star, etc) the declination angle (being 0 is at the equator, being 90 degrees is the north pole of the sphere, being -90 degrees, is at the south pole).
You also need another angle known as the "hour angle" to locate a point on the sphere. It doesn't explain what that is, but as can be seen on Wikipedia, you can easily click on that word to go to the entire page that explains what it is.
What don't you understand?
And as I can see here, no one else did ...
This is what I don't get ... what is the alternative to GitHub?
Hardly surprising, though, social networks are prone to centralization (due to network effect), and GitHub & its competitors (anything that offers git repos + issue tracking + fork-ability, really) are social networks.
Also, GitHub offering private repos for free right after they got acquired by Microsoft helped a lot. A lot of people, myself included, were using gitlab.com for private repos at that time
Squashed commits are strictly worse than plain, non-fast-forwarded merges from rebased branches.
It was instantaneous. But where do I go from there? I cannot navigate through the code. It shows me where I can find that string, but that's it. I also cannot look at blame to see when that line got edited.
Though thanks a lot for bringing this onto my radar.
And those updates are properly tracked by your version control, not done jankily by editing a commit and rebasing and force pushing.
Funny enough, this is more or less exactly the architecture some of those Haskell-weirdos would come up with. It's essentially a copy-on-write filesystem.
(Haskell people are weirdos compared to good old fashioned operating system people who use C as God intended.)
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).
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.
Once again, not so difficult to figure out even if you have no experience in the specific technical field of a Wikipedia article. So I have no idea what /u/casenmgreen's problem is.
It's a recipe for disaster.
Unless you mean squashing commits, which I don't consider rewriting history, just a retelling of the fact. Still, it's something one can only do very sporadically, or at known periods of time. I
'm sure others would be more pedantic about it and this wasn't clear above.
GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.
You can exercise distributed nature of git with GitHub quite well.
Though your 'stack of commits' is more like a 'stack of diffs' (at least in the Git sense of commit-is-a-snapshot-of-the-whole-repo.)
And actually, for better or worse, a PR branch is more expressive than a 'stack of commits', exactly for the reason you suggest: a PR branch can also contain merge commits, it doesn't have to be a linear chain.
What you'd need to do to support 'stacked diffs' or 'stacks of commits' is to keep a history of what you mutable pointers were doing. It's a 'meta-git'.
Once you have that, you could build all the convenient operations on top of that abstraction.
Btw, if memory serves right, git has some plugins (or whatever these things are called, plugins or so?) for implementing the stack of commits concept.
I don't know whether they go the 'meta-git' route that I sketched, or whether they do something less abstract.