4 ms·
Thanks for the background. There are indeed awful things about git's design, but I think it would have been very hard to out-market git. Git is both free AND
by chubot 10y ago
Thanks for the background. There are indeed awful things about git's design, but I think it would have been very hard to out-market git.
Git is both free AND viral. It's viral because if you want to use someone else's code, you have to use their source control system. Linux using git is a big deal in that respect (and yes I realize the kernel used BitKeeper :) ).
Also, Github as company and git the open source project are pretty complementary. It's hard to house both entities under the same roof, and you need that for ecosystem to succeed. Github is basically a UI/app company, and git is systems plumbing.
It's analogous to some PaaS companies wanting to make their own web framework. No actually that's a huge amount of work and you underestimated it. For all its faults, rewriting Rails is not something anyone can do. Heroku ended up being one of the early success stories because they just took your rails app and ran it.
Likewise everyone thinks they can rewrite Github, but that's pretty hard. It's at least 10x more work than you think, and you can get it wrong. If a tool isn't open source, there's much less incentive for a company like Github to come around and "popularize" it.
It seems like it's very hard to make money in developer tools in general, because so much is open source. And honestly they should be -- I would be a hypocrite if I said I didn't choose tools because they are open source. I guess Github and Atlassian are the outliers.
Anyway, my overall point is that I wouldn't necessarily chalk it up to marketing :) I do think open source got much bigger in the last decade, and it's hard for me to imagine that it wouldn't be built around an open source VCS.
- EpicEng 10y ago>Git is both free AND viral. It's viral because if you want to use someone else's code, you have to use their source control system. Linux using git is a big deal in that respect (and yes I realize the kernel used BitKeeper :) ). And BK is (was, until last year [too late]) closed software that requires a paid commercial license to use. Pretty much a show stopper for open source contributors donating their free time.
- luckydude 10y agoYeah, too late. Shoulda, coulda, woulda. There's some nice code in there though, I wish people would steal our libc stuff. Some really nice ideas in there. And a pleasant license so you can use it where ever you want.
- Artlav 10y agoIt would make it much easier to steal if you mention (that is, market) which ideas in there are worth stealing ;)
- luckydude 10y agoI've long thought I should do a blog on it and submit it here, just haven't gotten around to it. Until then... The "lines" data structure. This is a list library that scales down to a very small thing and up to pretty decent sized things. Think perl arrays and the ops on them. lines.h snippet below. /* * liblines - interfaces for autoexpanding data structures * * s= allocLines(n) * pre allocate space for slightly less than N entries. * s = addLine(s, line) * add line to s, allocating as needed. * line must be a pointer to preallocated space. * freeLines(s, freep) * free the lines array; if freep is set, call that on each entry. * if freep is 0, do not free each entry. * buf = popLine(s) * return the most recently added line (not an alloced copy of it) * reverseLines(s) * reverse the order of the lines in the array * sortLines(space, compar) * sort the lines using the compar function if set, else string_sort() * removeLine(s, which, freep) * look for all lines which match "which" and remove them from the array * returns number of matches found * removeLineN(s, i, freep) * remove the 'i'th line. * lines = splitLine(buf, delim, lines) * split buf on any/all chars in delim and put the tokens in lines. * buf = joinLines(":", s) * return one string which is all the strings glued together with ":" * does not free s, caller must free s. * buf = findLine(lines, needle); * Return the index the line in lines that matches needle */ The stdio stuff. We have a way that you can "push" code on top of a FILE. Some layers we implemented were compression and CRC and XOR. The compression is lz4 (we may still have gzip); the CRC stuff splits the file up into "blocks" (size is uniform in a file but it varies by overall file size), crcs each one. The XOR stuff adds an XOR block at the end. The result to a user is if they fpush(&f, fopen_crc(...)); then the file will be crc "behind the scenes". That fpush is the only new line of code to get the crc stuff. Ditto for compression. It gives you compression and hardened files under the stdio API and it's super fast. Like GB/sec fast. There's other stuff as well, like the spawn() code (I haven't called fork() in a decade or more) that brings a form of Windows spawn to Unix (since you can't make fork() work well on Windows). All of the code is Windows/Unix portable.