11 Years After Git, BitKeeper Is Open-Sourced (phoronix.com) 197
An anonymous reader writes: Eleven years after Linus Torvalds developed Git after a falling out with BitKeeper for managing the Linux kernel source code, BitMover Inc has finally decided to open-source the BitKeeper VCS. The latest BitKeeper release has made the code open-source under the terms of the Apache 2.0 license. The community edition code is available from BitKeeper.org. Does BitKeeper now stand a chance against free software systems like Git and SVN?To offer some context, Larry McVoy, the CEO of BitMover -- the company that makes BitKeeper -- offered free BitKeeper licenses to various open source projects -- Linux kernel utilized it as well. However, later, Australian computer programmer Andrew Tridgell reverse engineered BitKeeper protocol in an attempt to make his own client. Torvalds didn't like this practice, and accused Tridgell of "playing dirty tricks with his proprietary source code tool of choice," and as a result, he wrote Git.
Too late (Score:5, Insightful)
If BitKeeper had done that in the first place they'd still be relevant, possibly even the market leader.
Do they stand a chance now? Not without some killer new features that can't trivially be copied and pasted into Git.
Re:Too late (Score:4, Insightful)
Maybe not immediately. The Internet was sort of in its infancy, at least compared to now, when all of this went down. But it's true that if Bitkeeper had been made Open Source then, there would probably be no Git or anything like it. Bitkeeper would be the dominant source-code control system today. Given the way that several companies seem to have made money on Git, Larry might have made that money.
There are a lot of ifs though. We all have 20-20 hindsight but we can't really say that things would have worked out better for Larry. At the time he had a conventional software company and salaries to pay. It would have been difficult for him to get over the economic hump to where things are today.
Re:Too late (Score:5, Informative)
The Internet was sort of in its infancy
No web 2.0 was already a thing. We had already seen other VCS stuffs like CVS and SVN rise and fall in favor before. Most of us had been use VSS for years at work by then.
BK was adopted by a then 15+ year old Linux kernel project because it was better than CVS and SVN that had come before it. People were upset it was not OSS and it got replaced mostly because that was preventing people from contributing to Linux and making the management processes harder. BK would be today's Git, pretty clearly if it had been open sourced at the time. What isn't clear is if it could have been monetized effectively.
Re: (Score:3)
They could have done like Github and provide an infrastructure.
As BK's developers, they would have been ideally suited to provide an infrastructure not easily matched by competitors.
Re: (Score:3)
Perforce to stay relevant had to create a p4 git fusion and created a Web UI called git swarm. I still think it's a terrible VCS that breaks every tool that you try to integrate with it, but at least they have a solution for those hardcore perforce guys who won't give up the reigns who need to work with real developers.
Re: (Score:3)
Today it is entirely clear how it could have been monetized as hosted software as a service. I don't think the users would have believed in it as such back then.
Hard to bite concept (Score:2)
I don't think the users would have believed in it as such back then.
Yup indeed. Github is best described as "source repository combined with a *social* hub for coding geeks", and you can plainly see all the elements which would have had raised eyebrows back then :
- *repository* and *social hub* ? Why would people want a Facebook- / Myspace- clone slapped onto their Sourceforge- / Google Code- clone ?
- *social anything* for developers ? Geeks are the demographic which most viscerally hates social networks !
Nope, never gonna work !
In that alternative history of a Bitmover ope
Re: (Score:3)
What isn't clear is if it could have been monetized effectively.
Git has been monetized effectively, and it is open source. I have my doubts that anything involving Larry McVoy can be monetized effectively, judging from his behavior in the whole sad tale (with a happy ending for the good guys).
Not even upset (Score:3)
People were upset it was not OSS and it got replaced mostly because that was preventing people from contributing to Linux and making the management processes harder.
Not even. According to several of Linus' keynote/speeches (to lazy to google them, but it should be trivial to look for them on Youtube), bitkeeper was maybe available for free for Linux kernel development, but the license came with a clause forbidding reverse engineering/rewriting a clone of bitkeeper.
Nonetheless, several hacker started building their own tools interacting with the various bitkeeper databases.
Apparently at that point, Linus decided it would be better to drop bitkeeper before it becomes to
Re:Not even upset (Score:5, Insightful)
So, you, Linus, and Larry were annoyed with Tridge for doing exactly what he did to create Samba. He figured out the over-wire protocol without ever looking at the software of the server. But nobody seemed to object to his work on Samba. At the time, every big corporation was using it, and IBM, Apple, and HP were building it into products. Maybe they still are.
Re: (Score:2)
1) Microsoft does not have a no-reverse-engineering clause related to the SMB protocol.
2) LM was annoyed because Tridge was breaking an agreement, even if that agreement had no legal strength. Reverse-engineering software that was made available to you on the specific condition that you not do that is being a complete and total asshole, even if it's within your rights. MS didn't care on a personal level.
Re: (Score:2)
No, but they do regarding any software that would have been a client or a server, and this potentially applies to the over-wire protocol. It doesn't restrict reverse engineering to decompilation-like acts on the software itself. Tridge was within his rights because reverse engineering for purposes of compatibility is protected in many jurisdictions.
Re: (Score:3)
You are assuming falsely that Tridge had entered into some sort of agreement to not reverse engineer the BitKeeper protocol and write an open source client. That was simply not the case so while LM was annoyed that someone was reverse engineering his software Tridge was not breaking any agreements.
Re: Not even upset (Score:3)
Microsoft told an HP VP that they would sue the Samba project, and I got the internal memo after that meeting. They ended up backing SCO instead because they had to allow Samba as a term of the of the anti-trust settlement.
I looked at Sega v. Accolade and contractual pre-emption regarding fair use in copyright. I don't believe the reverse engineering term was enforcible.
Re: Not even upset (Score:3)
The resounding boom and development of git was a godsend.
Re: (Score:2)
BK existed definitely not before CVS, and I doubt it existed before SVN.
BK would be today's Git, pretty clearly if it had been open sourced at the time.
OSS has nothing to do with it. The Linux folks wanted features BK did not have. The company producing BK did not add them, and then came the OSS question: if it was OSS we could add the features ourselves, but we can't.
So Linus decided to craft git. Bottom line git and BK are now completely different beasts with a different workflow.
Re: (Score:2)
The Internet was its infancy in 2005? lolwut? That's one of the dumbest things I've read on Slashdot in years.
Re: (Score:2)
Larry had great ideas. It's hard to share with the Open Source community while still insisting on holding the same property close. If you don't want to go open all the way, it is better not to approach them at all. And it's just fatal to piss off an Open Source developer. They really can make a free competitor to your software.
Not Quite as Described (Score:5, Informative)
Andrew did not reverse-engineer the Bitkeeper transfer protocol. What Andrew did was to telnet to the Bitkeeper's server port, and type "HELP". Bitkeeper then obligingly told Andrew what its commands were, in the exact style used by all early TCP daemons like FTP, SMTP, etc.
The problem was that Larry and Linus were good friends, and Larry had convinced Linus to use Bitkeeper even though Bitkeeper was under something less than an Open Source license. Larry had this odd license requirement that if you wanted to use Bitkeeper for free, you had to tolerate it making its logs public, and at some time added a requirement that you not use it to develop competing software. Larry promoted these requirements as a means to make money with Open Source, but his license wasn't really compliant with the Open Source Definition.
Larry also got really nonlinear and pissed off a lot of the kernel developers. Which was probably the fatal step. Linus got tired of trying to hold two things together that did not want to stay together, and wrote git. This eventually destroyed Larry's company.
It remains a lesson regarding how not to work with the community.
Re: (Score:3)
This, I find, is the oddest part of all this. I support my friend, so much that I'd rather write a competing product than allow his servers to keep running and a thousand clients bloom. I forgot all about bitkeeper.
Re:Not Quite as Described (Score:4, Informative)
Re: (Score:2)
Almost right, Bruce. It is engraved on the Internet that Linus actually was a real dick [theregister.co.uk] to Andrew. I hope Linus was never great friends with him because that would make it all the more perverse.
Re:Not Quite as Described (Score:5, Informative)
I had something to say about that [theregister.co.uk].
Re: (Score:2)
Priceless comeback :)
Re: (Score:3)
Andrew did not reverse-engineer the Bitkeeper transfer protocol. What Andrew did was to telnet to the Bitkeeper's server port, and type "HELP". Bitkeeper then obligingly told Andrew what its commands were, in the exact style used by all early TCP daemons like FTP, SMTP, etc.
I believe trying commands to see what they do is still called "reverse engineering", despite being ethical, legal and not involving any decompiling.
Re: Not Quite as Described (Score:4, Insightful)
Re: (Score:3)
Oh, I totally agree here. I also assume he did a little more digging than just typing HELP. Things like trying the commands listed in the HELP to see what they do and/or trying some variants. Again, entirely reasonable things to do, no matter what the author thinks or likes. The vast majority of reverse engineering techniques are still legal (as it should be).
Re: Not Quite as Described (Score:4, Informative)
Here is a contemporary account based on Tridge's talk at linux.conf.au in 2005 [lwn.net]
The help command showed that there was a clone command.
"Tridge concluded that perhaps the clone command could be utilized to obtain a clone of a repository. Sure enough, it returned a large volume of output. Even better, that output was a simple series of SCCS files. At that point, the "reverse engineering" task is essentially complete. There was not a whole lot to it. "
Re: (Score:3)
http://sourcepuller.sourceforg... [sourceforge.net]
Re: (Score:2)
It makes perfect sense because Larry's help command was really just an abbreviation for helpmegetrich.
Re: (Score:2)
Larry also got really nonlinear
Which, ironically, was one of BitKeeper's primary strengths.
Re:Not Quite as Described (Score:4, Funny)
Re: (Score:2)
It takes two things. Any remaining owners must write off the property or the entire business, or otherwise authorize the release. Then one person releases the software.
Of course lots of Open Source is released by people working in their spare time, so no way is an operational company required at this point.
I also acknowledge that legacy software businesses can last a long time. I could not believe how long HP was still supporting MUMPS, t
Re:Not Quite as Described (Score:5, Insightful)
No. Linus would have been happy to continue to use Bitkeeper. What Linus did not understand was the developer community's commitment to Open Source and that they would rebel. I am sure he would have rather spent that time working on the kernel instead of making Git.
Re: (Score:2)
True, but it took him what, all of two weeks?
Re: (Score:3)
It was not just that the community rebelled, it was that the free to use deal got steadily more oppressive as things progressed, just as those so called rebels knew it would.
Re: (Score:2)
So, do you suggest that I tell Matthew Garrett not to look at how Windows speaks to the ACPI and secure boot software any longer?
The big difference seems to be the personal relationship between Larry and Linus, because the license terms aren't that different from the proprietary software we absolutely need to reverse engineer to keep Linux and BSD talking to devices. And obviously Tridge was not part of that relationship, and wasn't even a kernel developer.
a bold move... (Score:4, Insightful)
11 years too late.
Too little, too late (Score:4, Interesting)
It's a perfect *NIX source control system, doing one thing and doing it well.
To those who don't mind Linus's typical arrogance and want to see his side of the whole story, I recommend the following talk he gave at Google: https://m.youtube.com/watch?v=... [youtube.com]
Re:Too little, too late (Score:5, Interesting)
I remember him taking around 5 weeks off from kernel development. So, 2 weeks for the core is plausable. It proved that he's no one-hit wonder.
Re: (Score:2)
No it isn't. Everyone Knows that any major software system can be designed and written complete from scratch in no more than 48 hours by a 10-year old kid.*
After all, "All You Have To Do Is..."
====
* Or, failing that, the cheapest outsourced labor you can find. They even have certs in it!
Re: (Score:3)
Shame he didn't think about the user interface before he started coding.
Git Interface (Score:4, Funny)
Like he said, it's the perfect *NIX source control system...
Re: (Score:2)
Re: Too little, too late (Score:3)
Re: (Score:2)
Nothing at all wrong with the user interface. "git clone", "git add", "git commit", "git push" ... how hard is that?
If you must have a GUI, there are several of them out there. It's a hell of a lot easier to write a GUI (or web) interface for a CLI tool than vice versa.
Re:Too little, too late (Score:5, Informative)
That's thinking as a developer. And git is great... if you're a developer.
But it's confusing if you're not - and it's even worse if you don't understand the underlying data model (i.e., how stuff is stored in git) because without understanding the internal data model, a lot of things become very strange.
Stuff like staging files for commits, for example - most other VCS stage files, and if you change the file later while it's stage, the updated version is automatically included. But with git, you have to re-add it to the staging index again. And it's possible to orphan changes if you're not careful.
Git's not perfect, the only real reason everyone's comfortable with it is well, you sorta grew with it and you forget about its idiosyncrasies. And the fact the developers have really fixed up the more confusing aspects of git to be simpler and less tricky to do. I still have issues with format-patch and am because if you fail to rebase your tree when merging branches, you can end up with duplicate patches - one from the branch, one from the merge into mainline.
The only thing BitKeeper has these days is its underlying data model is based on SCCS
We used BitKeeper at one point in time with our open-source products, but when they yanked all the free licenses away, we migrated to perforce We've since moved onto Git since that's what Android uses internally
But it's good that what's effectively a dead product is being open-sourced - BitKeeper was quite nice back in the day and they could've just died and abandoned it, but instead just letting it go open-source and hopefully someone will continue development. If not, someone will learn from it.
Re: (Score:3)
That's thinking as a developer. And git is great... if you're a developer.
That seems like a fairly positive thing...for a developer tool!
(If you want to argue that git could be more useful in more fields than software development if it were...something else, well, that might be true, but it was developed by developers for developers, and seems to be doing quite well in its intended role.)
Re: Too little, too late (Score:2)
This actually sounds better to me. Filesystem mods are side effects rather than commands. The orphan issue I shall not defend.
Re: (Score:2)
> But it's confusing if you're not - and it's even worse if you don't understand the underlying data model
The basics of git aren't that difficult as this post [ycombinator.com] points out. Even this git tutorial [github.io] walks one though the basics.
Searching images for git model [google.com] shows everyone loves to over-complicate git. Here is one example [googleusercontent.com] or the popular A successful git branching model [nvie.com]. How many freaking arrows do you need?? K.I.S.S. and add *layers* to explain the more complicated git stuff.
Do you need to understand git's
What's the best manual for Git? (Score:2)
It seems to me that Git demonstrated a li
Re: (Score:2)
It winds up being pretty useful for more than just UNIX. I've found it a useful tool for checking out day to day work documents (spreadsheets, etc), because it gives version control, as well as a decent hedge against ransomware (well, until there a variant starts purging Git repos.) It also is useful for syncing with a master server, so regardless if one is on their desktop or laptop, they would have a recent working copy of their files... all they need to do is commit and push the repo when done with an
Re: (Score:2)
Re: (Score:3)
Git still has terrible command-line tools, where the meaning or all the arguments is very obscure and non-intuitive. The only thing that makes git tolerable is a good GUI. And there isn't one included.
Someone bad mouthed Perforce earlier. For sure it's a previous generation of SCM, which requires a central server, so people have moved on. But what it did have were command-line tools that were easy to use, with arguments that made sense, and a good IDE included - though with far less reason to use it than wi
Re: (Score:2)
A good GUI is required for ease of visualization (branching, merging, pretty diffs), but for actually getting work done, git rocks on the command line.
Typical workflow:
git pull
git add .
git commit -am "name: some message"
git push
Lather, rinse, repeat.
Anything more obscure, just look it up in the book: https://git-scm.com/book/en/v2 [git-scm.com]
Favorite git GUI? sourcetreeapp.com
Git's terrible command interface. (Score:2)
I'd mod you up if I could. I understand and use git, but its command interface is a usability nightmare for just about everything beyond the most trivial operations, and its documentation isn't much better. If not for github, I'd be happily using mercurial instead.
Re: (Score:2)
Torvalds claims, somewhat exaggeratedly, that he did write the core of git in two weeks, and, for any software developer, it's easy to see that git is a far more valuable tool to developers than any of its predecessors. After initial issues with bad command-line tools and crappy mswin compatibility, I think there are few reasons to complain about git nowadays.
I don't agree, I think there are valid reasons to complain about Git. The issue I have with Git is that it forces you into Torvalds' work flow model. You have to do things generally his way or Git is a pain in the...Where I see that the work flow he designed into Git is well suited for the work flow used by the Linux kernel project (and many similar projects) it is not usually the right work flow for other kinds of things.
Also, what Git is actually *doing* under the covers may not be obvious when you cons
Re: (Score:2)
Re: (Score:2)
Torvalds claims, somewhat exaggeratedly, that he did write the core of git in two weeks
Well, only April 6th 2005 he wrote [lwn.net]:
NOTE! BitKeeper isn't going away per se. Right now, the only real thing that has happened is that I've decided to not use BK mainly because I need to figure out the alternatives, and rather than continuing "things as normal", I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world ;) (...) PS. Don't bother telling me about subversion. If you must, start reading up on "monotone". That seems to be the most viable alternative
On April 21st he announced [slashdot.org] git.
Seems to me like the "I #Â%#&Â give up, none of these alternatives work I'll just write my own SCM system" phase was 15 days, that's close enough to two weeks for me. Of course I'm sure a lot of the mental churning on what such a system should be like was already done but in terms of coding it seems like he knocked out an initial version in that timeframe.
Too late (Score:2, Insightful)
Re: (Score:2)
"The world has already moved on to Git which is essentially perfect nowadays."
What????
https://xkcd.com/1597/ [xkcd.com]
Re: (Score:2)
It is but you can still get errors that the best solution is to rename the old repo and pull down a fresh copy.
Re: (Score:2)
GP was I believe a reference to xkcd.
Re: (Score:2)
Yes, it's hard to imagine how anything could be better - until someone invents it.
Here's my wish list: wouldn't it be nice if Git had some mechanism for ad-hoc sharing of individual files? Where I work, we replaced an older commercial version control system that was excellent at that with Git a couple of years ago. Git is an improvement overall, but we still lost something significant along the way. Git's submodules are a great design for sharing large blobs of code but they don't serve quite the same need
Re:Too late (Score:4, Funny)
The world has already moved on to Git which is essentially perfect nowadays.
Want to know how I know you've never used submodules or subtrees?
Re:Too late (Score:4, Informative)
Many large companies have a lot of trouble with git. It's not a coincidence that Facebook and Google have been working on Mercurial backends: For their needs, Git is absolutely insufficient. You also won't catch a videogame company using git either. And that's discounting all of git's problems with documentation, or the cli becoming nonsense very quick after you leave the most basic commands.
So yes, the world has moved on, but git is very far from perfect.
Re: (Score:2)
The world has already moved on to Git which is essentially perfect nowadays.
Wait a min... You are trying to be funny right? I think the author of git puts it this way, "it does exactly the opposite of CVS whenever possible..." We all know everybody hated CVS.
Top Something (Score:2)
When discussing what source control system to use for any new project, how often does BitKeeper even come up as a suggestion?
In my experience, most conversations of that nature start out with git versus Subversion. Mercurial might get thrown in if git is "too hard." Microsoft's solution might get suggested if it's a Microsoft-centered project. CVS might get brought up by the C-level who read about it in a magazine in the 90's and/or is a year or two from retirement. But BitKeeper? Never even seems to come c
Re: (Score:2)
The wars between git and perforce are eternal. But I haven't seen SVN come up in a while.
Migrated to SVN a few years back... (Score:3)
The wars between git and perforce are eternal. But I haven't seen SVN come up in a while.
I migrated the company I work for to SVN just a few years back now. Some of the programmers expressed worry that we were jumping on "the latest bandwagon", but I reassured them that if Subversion was a bandwagon, it was a bandwagon abandoned in a ghost town. Change-adverse as engineers are, they found that reassuring. And I mean hey, at least it isn't CVS anymore!
When I first came in as the sysadmin I found out the company was using CVS (specifically cvsnt running on an old CentOS box), which the lead pro
Re: (Score:2)
I came across an article where even MS recommends moving to git from TFS, and IIRC, TFS also functions as a git server.
If MS double-downs on an OSS technology, that definitely means something.
Way too late... (Score:3)
The infrastructure around Git is just too large and has too many large adopters. And it's not like there aren't open source alternatives (Mercurial) that people would shift in the unlikely case that Git imploded. Also, I doubt any remember, but SourceGear tried to make it's own open source DVCS (darcs) that is still going on too.
But, you never can tell who will be at the top of the hill. I remember when ClearCase was considered to be the top notch VCS, and it did have some very nice features in the day. But, things change.
The only game changer I can see is tools that know what it is tracking has structure beyond files. For example, it'd be nice to track changes to the level of a block in a function in a class in a project, not just file changes. And tools that allow for queries on that structure (show me every class method you can find with more than six parameters on it, for example). But, code repositories are hard to do in the general case.
Re: (Score:2)
I assume you have heard of git blame?
ClearCase was marvelous. But at $3k/seat ... (Score:3)
I remember when ClearCase was considered to be the top notch VCS, and it did have some very nice features in the day.
It was a top-notch VCS. It would still be a top-notch VCS (in an environment where you have continuous access to the repository).
In particular, the ability to construct "views" of the code base with a simple language, specifying, in a few lines, what versions of things you wanted, was invaluable for diverge-converge development in an environment that had to maintain several production thread
BitKeeper is Irrelevant (Score:2)
The space for source code version controls is covered fine with SVN and Git, there is zero need to use of or move to a commercial tool, regardless of it being Open Source or free for some uses. Sure, some companies are still using them, but even very large customers I have been working for are using SVN or even Git these days, and often not even via a commercial front-end.
That ship has sailed, for almost all uses this problem is now FOSS solved and likely will stay that way. This, incidentally, is what FOSS
Re: (Score:2)
That actually works reasonably well with subversion as well. You may have to invest part of the money you safe into storage though. My employer does it to simplify storage and backup, i.e. everything worth keeping goes into SVN. We do not have really large things in there (like videos) though, but we have encrypted blobs up to around 100MB, for example. Supposedly, SVN has problems when you get into the GB-range for single files, but we never encountered any.
My guess would be that this is more of a case of
BitKeeper is the reason to avoid proprietary (Score:4, Interesting)
Tooling will decide wether BK stands a chance. (Score:2)
Give me a perfect FOSS GUI Tool for Bitkeeper that runs everywhere plus maybe a FOSS web-based BK GUI/Frontend and I'll move from Git to Bitkeeper faster than you can say "kinda-so-so Git tooling". However, if that doesn't happen and handling bitkeeper is just as much a hassle as Git was 7 years ago, I'll pass, thank you.
SourceTree isn't FOSS, although it's free-as-in-beer and GitKraken doesn't really seem to support my workflows, but I'm doing fine and it's still better than SVN, although SVN has near perf
Re: (Score:2)
I usually stay well clear of this type of conversation - though I read them. I am, after all, long since retired/retarded/out of touch.
But, if you're doing non-commercial work - have you looked into SmartGit? It is, I should say, a bit resource hungry but it is otherwise not intolerable.
I can't actually say I've found a GUI client that I like. But SmartGit doesn't make me want to smash things with a rock and murder people. So, there's that.
Of course not (Score:2)
"Does BitKeeper now stand a chance against free software systems like Git and SVN?"
Not a chance. GIT is simply better. A lot better.
It took me a long time to "get" GIT after coming from SVN, it's just *different*. But once I got it, I'd never go back.
Re: (Score:2)
The "McVoy" Effect (Score:2)
This is a very interesting study about what Larry McVoy intended and how the absolutely complete opposite happened.
And this is different from the Streisand effect because really only few acting people were involved(git as the linux kernel scm tool at first), so to categorize it under a new term is appropriate. (McVoy isn't the first but this case is well documented)
The interesting thing is McVoy's actions set the path for the development of git, because git just needed to be created because McVoy could not
Re: (Score:2)
So as non-developer... (Score:2)
Bitkeeper gripes. (Score:2)
Re: (Score:2)
wut.
Git is free. You're mixing up Torvalds (who wrote git and the linux kernel) and Larry McVoy who wrote BitKeeper. And yes, it is too late for BitKeeper.
Re: (Score:3)
Yup. Now I get it. You meant Torvalds had to find out the hard way wasting his time using a closed source solution for the kernel source in the first place.
Re: (Score:2)
Re: (Score:2)
When Torvalds created Git, he shaped it according to his own requirements. Even the best of the alternatives weren't good enough for him as they stood.
So I don't think that the Linux source tree, at a minimum, is likely to move back now. And since git has spawned a fairly extensive ecosystem in its own right, that's another potential market lost.
At this point, it's a might steep hill that BitKeeper would have to climb.
Re: (Score:2)
Git is too entrenched now for anything but something absolutely revolutionary to replace it. Heck, even Microsoft has it baked into VS and recommends people move to that. OS X also has Git support baked in if one decides to load XCode.
Replacing Git would be like trying to replace tar or bash. It -might- be possible, but in reality, it is virtually impossible for it to happen.
If I were the CEO of BitKeeper, I'd be looking at trying to make something to compete against GHE, GitLab, or Bitbucket, with a web
Git documentation? (Score:2)
Re: (Score:2)
Re: (Score:3)
The O'Reilly book, Version Control with Git, for me provided the "ah-ha!" explanation of git's internals that made things made sense.
Re: (Score:2)
Ironically, the author would like you to stop using git. [youtube.com]
O'Reilly book: Version Control with Git (Score:2)
I'm skeptical about O'Reilly books. I've seen some that are poorly edited. But it's worth a look.
Thanks! 574 pages! Mod parent UP! (Score:2)
Re: (Score:2)
It looks as if BitKeeper meets all of these requirements. Fossil meet
Re: (Score:2)
It used to be that everything I'd written on Slashdot in its infancy was still online. If anyone cares enough, you can probably find the links.
Re:Larry McVoy threatened to sue me on /. years ag (Score:5, Interesting)
Since this is Larry McVoy I wouldn't be surprised if it is true. A different story, but related:
http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481 [gmane.org]
I have seen and accepted many non-free licenses over the years and I'm fine with most of of them. But Larry McVoy and BitKeeper stepped over the line. I will never under any circumstance defend him or his work, his actions have been downright harmful to creation of free software at a lever which is simply unacceptable.
Re: (Score:2)
Hitler: "Linus is nastier than the curly headed girl who runs Facebook."
ROFL!