Alternatives to Git? [closed]

Question

Is there any version control software with the functionality of Git, but which is not under a viral license? - A "viral license" being, by my definition, one which requires derived software to be under the same or an equally-restrictive license.

I'm not interested in an argument on or discussion about the GPL; it's outside the scope of this question and website.

Thanks.

Orchidectomy

have you considered using SVN? Is your issue with version control software, or integrating a version control software with your program, or are you talking about a host for the data? – Stupendous

Why is a "viral" license a problem? Using Git for your software does not require you to put your software under the GPL. – Hackathorn

Even the Apache Software Foundation itself encourages the use of git. – Thicket

@Delnan: It's a philosophical objection. I know it's not applicable to me, but I don't want to encourage the GPL to spread in any way, in somewhat of the same way I wouldn't walk around carrying an infectious virus I'm immune to. – Orchidectomy

I'm not enough of a religious warrior either to encourage the "let's give our buddies a headstart by disallowing everyone else to use out stuff" stance that those licenses basically are. However, there are lots of great applications under the GPL (do you use gcc? I bet you did, at least indirectly if you ever used a unix-ish enviroment) that I want to use despite and philosophical disagreements, partly because quite often, there's about no useful code that can be derived from them as they're standalone applications (and in many cases, e.g. Codelite plugins, there's an exception for them). – Hackathorn

I am using Git; I'd just rather not if I can find a good replacement. – Orchidectomy

Anti-Git-Jihad because of the GPL? You should mention the projects you are involved in somewhere so I can stay away from them as far as possible. – Bloater

If you didn't want discussion probably should have just asked for version control that isn't under GPL, instead of the additional adjectives. – Denyse

Thank you for this question, I was afraid to ask. – Channa

@NarftheMouse: thanks for this question. I'm also in the same boat looking for a non-GPL git replacement, although in my case it's not a purely philosophical issue, but also a practical one: If at some time in the future I need to have the freedom of packaging the SCM I use under permissive license terms, the choice of a GPLed one will be an obstacle. I choose all the tools I use trying to maximize my freedom at any future scenario. However, as of today, I still don't know of any git "clone" which is non-GPLed. – Involution

I use: gitlab.com/es20490446e/gitu – Sn

Answer 1

Fossil is (and Codeville was) a BSD-licensed distributed revision control system.

Note that unless you're actually modifying the version control software itself, the license doesn't affect you; you're free to develop non-GPL'ed software using a GPL'ed tool to manage revisions.

Battologize

Answer 2

The other options are:

1. Perforce
2. Bazaar
3. SVN
4. CVS

Indefatigable

Also got, "The software is freely usable and re-usable by everyone under a BSD license" – Gautama

Answer 3

UPDATE:

Since 2 years passed since started professionally working with git (after 20 years of not-git...) I can say this:

1. GIT has it's advantages when it comes to merging code bases between branches and multiple users. Once you master it, and learn to ignore its - sometimes utterly confusing command line UI - can be easy to work with.

2. On the downside, GIT IS complex to understand and LEARN. There is a long steep learning phase, especially if you work from the command line in multiply branched repository (the common and the recommended approach). Working with UI tools like InteliJ IDE's can hide some of the details, but these require their learning attention and time too + some not so basic GIT knowledge. And this knowledge is required by ALL members of your team.

OLD AND (not so) BELOVED ANSWER:

Forget the license... You want to NOT use GIT for so many other reasons...

If you want things to work faster for your team - stay away from GIT. Why not use SVN? It is supported by any service that supports GIT, and is the most popular alternative to GIT (as far as I know).

To commit/merge/manage a team in GIT it'll take you exponentially more time than other SVN/Fossil/... All in the name of advance "distributed" design, and a rich set of methods to kill your code, merge it wrongly, give you so many options to do horrible mistakes (that happen to pro's and newbies alike), and do simple things the HARD HARD way. Were in reality it only serves the ritual hungry souls of geeky programmers, who would otherwise have to go home late and face the empty walls of their houses... (poetic answer too).

REALLY - It would actually be funny if it wasn't the number one pain-in-the-arse time killer in the office. And once you go GIT you can never go back, so my advice, don't let the geeks have it. Keep it out or pay the price.

And, yeah, I know the crowd here, and I am more than willing to loose a few points. It's not like it means anything real.

Vaishnava

Downvoting due to complete inaccuracy. I switched from SVN to Git about 10 years ago and have been much happier and more productive as a result. – Dickinson

So, you did something 10 years ago and say I am completely inaccurate. Genius. I stand behind every word. Working with git is a nightmare. Hard to learn. Hard to work with. Sorry for not playing "follow the leader" on this one... I worked with a number of version control systems, and GIT is... not easy to work with. Without justification. Anyway, have fun down voting this answer, if it gets you happy :) – Vaishnava

It’s not that I “did something 10 years ago”, but rather that I have considerable experience (Git for the last 10 years, other VCSs before that) that contradicts your claims. Git is different from SVN and CVS, sure, and it takes a bit of learning. But I enjoy using it and would never willingly go back to what I had before—and it makes teams so much more productive than SVN. – Dickinson

You didn't use any other CVS for the last 10 years, hence my comment. But regardless of this futile discussion. GIT requires too many steps to be "productive". It takes too long to learn. Many of my expert team-mates have little clue on how to manage different situations driven to by GIT's 7 layer scheme... All this while other VCS's provide similar features without the hassle. Very simple. It's a pain in the arse... that's all. But it's so complex to deal with, that everybody want to say that they master the beast, hence, they are genius... NOT. – Vaishnava

I actually have used SVN a few times since I switched to Git, which has convinced me that I never want to use SVN again if I have a choice—SVN actually makes things that are easy in Git much harder. And no, Git doesn’t have to take long to learn. I’ve trained co-workers in it quite quickly. • “everybody want to say that they master the beast, hence, they are genius” No, quite the reverse. I’m saying that it’s not hard to master Git, and you don’t have to be a genius to do it. I’m not claiming any special ability here; you’re the one saying that. – Dickinson

Lets agree we disagree. Each and his own experience... – Vaishnava

When you make claims in an insulting tone that are pretty clearly false, and don’t provide any evidence for them, I’m not sure that you then have any standing to “agree to disagree”. – Dickinson

Well don't get insulted, but I really don't mind if you think I have a stand or a sit, or well anything else... – Vaishnava

Agreed. Git is a pain. Nobody wants to change history: why is that option even there? Why dozens of commands with as many options? Why distributed repositories? Why staging? Nobody needs that. – Radiosensitive

@PerdiEstaquel I hope you’re being sarcastic. :) Staging and embracing the distributed nature of Git are fundamental parts of my workflow, at least. I miss both when I have to use something like SVN. I agree that changing history is evil, though. – Dickinson

@MarnenLaibow-Koser Now that I'm a git expert in a number of different workflows, I can say that GIT MAY have some extra functionality over other VCS's. However, the need to learn a whole new, highly opinionated language just to save/merge the team's code is not the way I would go. Yet, everybody do so, and I have to go with the flow on that one. My experience with SVN was that it was way more fluent and easy to work with. And best: I didn't have to keep an open CMD/BASH window just so I can use the command line... GIT has brought me back to DOS times, which I wanted to forget... – Vaishnava

@Vaishnava SVN is perhaps a bit simpler than Git, at least if you started with it (although I’ve heard people who started on Git say they can’t understand SVN!), but it’s missing many features that make life easier. You can use Git without the command line through a client such as SourceTree; however some features work better from the command line (and that’s true of SVN too!). I find that I usually have a command line window open for other reasons anyway, so that’s no big deal for me. – Dickinson

It's not just the window. It's understanding the 3 stages of committing code that can get you really frustrated as a newbie, especially if you come from SVN/Fossil, where committing is one stage... Still didn't find why it is needed. Probably meant for IDE's and Code management tools like JetBrain's and SourceTree. SVN works as a simple windows explorer extensions, without the need to use the command line EVER, which is way cooler in my opinion. Yet, some people find VI convenient. Go figure people :) – Vaishnava

@Vaishnava The fact that you speak of the “3 stages of committing code” makes me think that someone taught you Git in a way that encouraged you to develop a poor mental model of how it works. I assume you’re referring to staging, committing, and pushing, which are different operations with different purposes. Each one is individually useful, but if you just think of it as “3 stages of committing”, then it’s probably harder to see that than if you’d been taught to understand each operation on its own. (I can explain the latter if you want, but it seems like excessive detail here.) – Dickinson

@Vaishnava And no, SVN doesn’t work as a Windows Explorer extension. You’re thinking of TortoiseSVN, which is a particular client just as SourceTree is (and BTW, TortoiseGit also exists). – Dickinson

Somebody has flagged this comment for review incorrectly - it is an answer. It is saying "use SVN" - which answers the question. – Preceptor

This discussion has become long (no I don't flag as inapropriate anyone's commment... not that bored :) and yes, the "staging" stage is redundent in my opinion. Would live without it... – Vaishnava

@Vaishnava You’re not the first person I’ve heard say that they don’t understand staging, and in fact there are some UIs for Git (such as Gitless) that make the staging area vanish. For myself, though, I really love the staging area. I like being able to build up a changeset incrementally, and only commit it when I’m ready to do so. – Dickinson

Downvoted as the answer is just a rant without arguments/examples/explanations why git is bad, touching the question from OP just slightly – Allseed

@Vaishnava one criticism of your answer: you can go back once you went with Git. In fact the format defined by git-fast-import is the way to go that route. Personally I consider it the only aspect of "core Git" (going by gitglossary) - other than some abstract ideas - which would be worth having around even if Git ever went the way of the dodo. Reposurgeon, originally written in Python now Go, is the tool to do it, unless you want to put up with the rough edges of auto-converted repos. – Tutti

Git is designed so badly that I cannot imagine something worse. The argument of downvoting is: Linus found a way to create super-complexity within a simple task. Git sees conflicts where no any conflicts. Merging is pain. Interactive rebase uses extraterrestrial logic. "Snapshots"-states (vs rcs/cvs/darcs delta) are completely counter-intuitive. Command line is crazy. Copying of tree is pain (vs 1 fossil file), internal structure is crazy (vs fossil's SQL), etc, etc. What's good in git? Brutal promotion. – Erechtheus