A tool like git could make operations such as branching and merging easier, and allowing developers to collaborate more. It also has a global revision identifier (instead of file based revisions) and signed commits which may increase security.
Also, git on the server seems to use less resources (which is one of the reasons git "won")
I disagree. Github arrived in 2008, soon after many DVCS options arrived. Mercurial and git were developed at very near the same time in 2005, Bazaar was developed around then too. I don't believe that git had anywhere near the market share back in 2008 that it enjoys now.
When github arrived, git's biggest win was the kernel. But that was kinda a given if you consider its genesis. Granted, it's a noteworthy project that helps prove git's scaling capability. But IMO git didn't win until years later when folks who had adopted the other DVCS engines started switching to git.
Don't know about the rest, but I switched from SVN to git before I even heard of Github for my personal project and also in the company I was CTO at the time.
Two things were decisive: being able to commit and browse the whole history while offline and the fact that my main dev machine was Linux so it worked faster than anything else.
And git won because hands down it was the fastest and most flexible, albeit most horrible UX. Also unlike something like say bzr, the core on disk git format has stayed relatively unchanged since it was first written. The architecture is simply the best in git compared to most other vcs software.
Actually, there was one big disk format change early in git history: the object id changed from the SHA1 of the compressed object to the SHA1 of the uncompressed object. All three projects using git back then (Linux, sparse, and git itself) had to convert to the new format (since the object ids changed, every tree and commit object had to be rewritten).
> Sure, and I said relatively unchanged compared to bzr. Looking up in bzr, the ondisk format changed several times in incompatible ways.
But bzr always had the ability to read and write repositories written using older formats. Each on-disk repository format is implemented as a set of separate Python classes, all exposing the same interface.
Git thought it could do without a "repository format version identifier" and a strategy for multiple on-disk formats until version 2.7 (2015). Bzr had everything well planned out since the beginning.
> IMO git won due to github more than anything else.
You're reversing the causes and consequences.
Git was awesome from the start, and asn an over-night success due to linux.
Github's contribution, and role in git's success, was only one: providing a free hosting service that presented a usable and user-friendly alternative to sourceforge.
There are plenty of hosting companies that support Git, and some even supported competing decentralized version control systems from the start. Yet, none of them worked so well as git.
Basically, it's to make all OpenBSD developers participate in the release process. There's no dev and stable team - everyone is in the same tree, makes breaking changes early, spends months stabilizing. CVS helps force developers to participate, because branches can't exist for long before the resulting merge is too painful to be worth it.
Although, they are careful to say that, just because it works for them, doesn't mean it will work for you. As well, your other points are still valid. (My personal gripe is that CVS over the net is so slow that I have to use an external tool like CVSync.)
I had to use their "ancient CVS system" once in order to submit a patch. As usual with OpenBSD, documentation was superb and the setup was very user friendly.
To this day, the navigation in their OpenCVS web interface beats most of the alternatives.
Really, learning git and GitHub requires much more effort. Heck, you can't even attach a PR to an open GitHub issue. That's progress, I guess.
You are correct. To avoid a common misunderstanding I'd like to note that GNU people have no problem using software that has been released under the Expat license. It doesn't have to be copyleft software to be free/libre.
GNU grades hosting services based on different sets of criteria. GitLab gets a C, "acceptable hosting for a GNU package", but not "good enough to recommend" because the JavaScript on the website is free but doesn't work with analyzers like LibreJS, and because GitLab doesn't discourage bad licensing practices. GNU Savannah, of course, gets an A.
Things that prevent GitLab from moving up to the next grade, B:
All JavaScript code served to the client is free, but does not work with LibreJS enabled. (B0)
Encourages bad licensing practice, including no license; failure to state the license on each source file; and failure to say which GPL versions apply. (B2)
---
I think at least B2 is a reasonable request, although this may have already been fixed (sorry, I use gitlab but barely visit the site itself).
45 comments
[ 3.6 ms ] story [ 81.4 ms ] threadI wish GNU people could clean up Savannah and use it as their main distribution point.
Well, at least they are not OpenBSD with their ancient CVS system.
Also, git on the server seems to use less resources (which is one of the reasons git "won")
Jokes aside, github won because - unlike sourceforge and gitorious - their web interface did not suck.
When github arrived, git's biggest win was the kernel. But that was kinda a given if you consider its genesis. Granted, it's a noteworthy project that helps prove git's scaling capability. But IMO git didn't win until years later when folks who had adopted the other DVCS engines started switching to git.
Two things were decisive: being able to commit and browse the whole history while offline and the fact that my main dev machine was Linux so it worked faster than anything else.
But bzr always had the ability to read and write repositories written using older formats. Each on-disk repository format is implemented as a set of separate Python classes, all exposing the same interface.
Git thought it could do without a "repository format version identifier" and a strategy for multiple on-disk formats until version 2.7 (2015). Bzr had everything well planned out since the beginning.
You're reversing the causes and consequences.
Git was awesome from the start, and asn an over-night success due to linux.
Github's contribution, and role in git's success, was only one: providing a free hosting service that presented a usable and user-friendly alternative to sourceforge.
There are plenty of hosting companies that support Git, and some even supported competing decentralized version control systems from the start. Yet, none of them worked so well as git.
OpenBSD has been traditionally anti-branch.
Theo de Raadt's 2009 presentation: https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
Ted Unangst's blog, email: http://www.tedunangst.com/flak/post/branchless-development https://marc.info/?l=openbsd-misc&m=134419365218558&w=2
Basically, it's to make all OpenBSD developers participate in the release process. There's no dev and stable team - everyone is in the same tree, makes breaking changes early, spends months stabilizing. CVS helps force developers to participate, because branches can't exist for long before the resulting merge is too painful to be worth it.
Although, they are careful to say that, just because it works for them, doesn't mean it will work for you. As well, your other points are still valid. (My personal gripe is that CVS over the net is so slow that I have to use an external tool like CVSync.)
To this day, the navigation in their OpenCVS web interface beats most of the alternatives.
Really, learning git and GitHub requires much more effort. Heck, you can't even attach a PR to an open GitHub issue. That's progress, I guess.
Fixes #42
Where the issue is number 42.
https://help.github.com/articles/autolinked-references-and-u...
https://github.com/blog/957-introducing-issue-mentions
https://help.github.com/articles/closing-issues-via-commit-m...
Why don't they use GitLab CE? It's under the GPL
"GitLab Community Edition (CE) is available freely under the MIT Expat license."
I don't see GPL mentioned there.
https://www.gnu.org/software/repo-criteria.html
https://www.gnu.org/software/repo-criteria-evaluation.html
How hard would it be for GNU to maintain a fork of that instead of maintaining their own codebase?
>GitLab doesn't discourage bad licensing practices
If they host it, they can discourage whatever they want
If the gitlab people could fix these minor issues and receive the blessing of RMS I think they could get some exposure outside their usual market.
(whether that gets them more paying costumers is a whole different discussion)
Sorry, dropping in here while working on our release of today. Could you clarify what issues?
We're always excited to help projects move to GitLab.
---
Things that prevent GitLab from moving up to the next grade, B:
---I think at least B2 is a reasonable request, although this may have already been fixed (sorry, I use gitlab but barely visit the site itself).