> So I'm writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I'm at most half done, and if I hit a snag maybe that's not true at all. Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they'll be a very specific "log Linus' state" kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.
The whole story of how git was cockled together to ameliorate the awkwardness of dealing with BitKeeper licensing (right?) issues, and marched from there to greatness is a pretty inspiring one, to my mind.
Oh, good catch. It's a very vague allusion to git, though. The one I linked was the first one where I could find the string "git" in it.
> The whole story of how git was cockled together to ameliorate the awkwardness of dealing with BitKeeper licensing (right?) issues, and marched from there to greatness is a pretty inspiring one, to my mind.
Let's not over-romanticise the subject. Github obviously had a lot to do with it, along with luck and admiration for Linus. Also, git is hardly alone: Mercurial was almost the same idea in the beginning. Let us not forget how early git only had branching by cloning, like the Bitkeeper that both git and hg were emulating.
Also, it wasn't just that bitkeeper had an awkward license. It's that Tridgell reverse-engineered the Bitkeeper protocol, and thus Larry McVoy took away Linux's permissions to use Bitkeeper.
I'm not sure about github - I take your point, but you might also argue that if git didn't have the particular design, features, and mindset that went into creating it, github couldn't possibly have become the thing it is today.
Without getting into BK morality tales, though, it is one of those great stories along the lines "well in that case I'll jolly well write it myself" which shows that just sometimes doing that can (in some small way) change everything. Not unlike the linux kernel itself, or GNU/emacs, of course.
BitKeeper originally offered free licences to Linux developers, with one of the conditions being that they don't reverse engineer it.
One of them did, and BitKeeper revoked that licence. That's what prompted Linus to write Git, and also why it is named "Git" (an mild insult aimed at the person who reverse engineered it).
I believe Linus has said that "git" was referring to himself rather than the guy who reverse engineered BitKeeper, but I don't believe him.
Actually, I could much rather believe that 'git' referred to Larry McVoy, Mr. Bitkeeper himself. I've never met the man, but the fact that the license was onerous and he basically took his ball and went home speaks volumes. Also, and again hearsay, but I've heard stories about him.
That being said, I'll take BitKeeper over Perforce any day of the week.
Matt Mackall had been working on hg for a couple of weeks prior to the public announcement This means that both projects started at almost the same time. I believe that Matt actually privately showed Linus hg before he made a public announcement, but maybe I am mistaken about this story.
There are projects like hgit and gitless that put a different UI over a git store, not to mention that just about every GUI tries to hide at least one of the "ugly" parts of the CLI.
Out of curiosity, was anyone else surprised to learn when git first came out? I had been using it for a while, and assumed it had been around for ages, based on how it seemed to be so oriented around a unix file system and using the command line.
The fact you're surprised makes me feel really, really old. I remember watching the initial conflict with popcorn in hand. I was more interested in OpenSolaris in those days, but it was still entertaining to see the pissing matches Linus caused as part of finding the new way.
I'm not what they'd call very young (33), and I'd been programming from an early age; I just hadn't done legit software development with version control until about 2011, and hadn't looked up git's origins until about 2014.
I remember reading about git and thinking "branching and merging in svn really isn't that hard, who needs this distributed versioning stuff?". But then I worked at what appears to have been one of the few companies on the planet that used svn correctly.
Man. I should be getting old. I distinctly remember using Git for the first time. I remember learning that branches are first class entities in Git; learnt other cool stuff from it. For example git grep, it was so cool to see it that fast.
I was- tried it on a private server, as you would, and didn't entirely get its utility at the time. My opinion is that great projects (products?) always have two outstanding versions: the CLI, and the GUI. Problem is that whoever makes the CLI can't make the GUI or they miss the point of what the GUI can offer that the CLI can't, and vice-versa.
> I had been using it for a while, and assumed it had been around for ages, based on how it seemed to be so oriented around a unix file system and using the command line.
Unix culture seems to be alive and well to this day, and still seems to get infused with new blood. So I wouldn't even have been surprised if something like git was made by a college student instead of a 40-something inventor of the most popular Unix-like OS.
I'm looking for a good collection of Linus' own emails discussing some of Git's more advanced topics, as I remember he discussed some subtleties that may be missed by other documentation such as the Pro Git book and the manpages. (maybe said documentation has caught up, but I'd like to check to be sure).
So far, all I've found is a few threads collected at yarchive.net [1], which is promising, but how can I find more? Google fails me :(
I don't think you need to go much further than LKML archives. He wrote git because of the bitkeeper incidence and then handed over the maintainership very shortly after. There was also some mail about ranting when to rebase and when to merge more recently, but it is also in LKML. I don't think he regularly writes to other public lists than kernel anyway :)
In case anybody hasn't tried it yet: It is pretty cool to check out the first copy of git that was committed to git. It is incredibly simple, yet was sufficient to create a commit that is still in the same git repo as modern git.
It is possible for a git commit to have zero parents (initial commit), one parent (the direct ancestor in a linear path), two parents (generally referred to as a merge node) and more than two parents (also referred to as a merge but only possible using the octopus strategy).
Linus Torvalds really has a gift for under-promising:
> I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.
[...]
> It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(.