SteveStreeting.com

65 Responses to “Early-stage Git/Mercurial/Bazaar evaluation thoughts”

1. Matt Williams Says:
   September 28th, 2009 at 11:38 am

   Regarding the commit -a thing, I almost never use it. I tend to just use a gui (like ‘git gui’ or git-cola) to stage all the files I want to commit and then commit them.

   The excuse that is sometimes given for the obscurity of git’s commands is that teams can write their own ‘porcelain’ to fit their workflow. Of course, this is infeasible for most teams but there are people making their own git front-ends such as ‘easy git’ (http://www.gnome.org/~newren/eg/) or vng (http://labs.trolltech.com/blogs/2008/03/30/sourcecode-collaboration/, http://repo.or.cz/w/vng.git).

2. CABAListic Says:
   September 28th, 2009 at 11:56 am

   Seeing as how I end up using the command line most of the time on Linux, I would definitely have to vote against git and for bzr (hg is probably fine too, never used it). The command-line bzr actually beats svn in some regards.
   The question of performance is whether it actually matters – the test case you linked in twitter was, if I understand it correctly, a 500 Mb local commit. If you committed that amount over the wire, would the speed advantage of Git actually matter compared to the transfer time? I have no idea, really.

   Btw, one other item for your checklist, perhaps, would be the handling of line endings. Ogre’s svn repository currently manages the line endings and ensures native line endings for either platform. I don’t know about git or mercurial, but bzr did not have any (inbuilt) support for this in the past, argumenting that this is not part of its job. We would need to either adopt a common line ending mode for Ogre or deal with this some other way.

3. Aras Pranckevicius Says:
   September 28th, 2009 at 11:59 am

   So the question is: what are chances of TortoiseHg improving a lot in a short period of time?

4. Steve Says:
   September 28th, 2009 at 12:11 pm

   @Matt: that’s exactly my point – when you’re using a GUI you don’t think of it because they’ve sensibly realised it’s a good default. But when you move to the command line, it’ll behave differently if you forget the -a. This is a recipe for mistakes.

   @CABAListic: Bazaar does line-ending conversion already, since 1.14: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion. Both Git & Mercurial can be configured to handle line ending conversions too, but don’t by default (both extensions).

   @Aras: I’d say the lack of good Mac GUIs for hg is more critical. I can use TortoiseHg right now with only slight occasional irritation, but I simply don’t have a GUI I’m happy with on the Mac yet.

5. Ciaran Says:
   September 28th, 2009 at 12:12 pm

   I do understand the sentiment behind your “If understanding how it’s built is a prerequisite to using it, then I’m sorry, it fails miserably at being user friendly.”

   However, the VCS is (in my opinion, needless to say) *the* most important part of a software developer’s toolkit. It’s worth the effort to understand how it works, and it’s hardly rocket science anyway.

   User friendly is good for users, who don’t have the need/time/ability to know what’s going on behind the scenes. Developers ought to see the benefit of things not being abstracted away too much.

   Also, commit -a is a good thing!

6. Steve Says:
   September 28th, 2009 at 12:17 pm

   @Ciaran: Can’t disagree more. If I had to understand how every one of my tools worked, I wouldn’t have time to do anything else. I write OO code because I like to abstract, because I don’t want to have to understand even my own code from 2 years ago if it already works. Encapsulation and black-boxes are a good thing, they allow you to focus on stuff that matters, not things that are irrelevant to your current task. Developers are users too, it’s all about context. I don’t care how Git works under the hood, honestly. It’s irrelevant to what I want to do. If they can’t abstract that to ‘userland’, they’re not trying hard enough.

   And please explain to me why it’s a good thing that commit without the -a (ie the default behaviour) takes an older version of the file than the one you’re building with. Every developer I know ‘adds’ files when they create them so they don’t forget to do it. It is a good thing to be able to differentiate between the working dir contents and a staged area, but why is the default so at odds with what most people find intuitive?

7. Andrew Fenn Says:
   September 28th, 2009 at 1:12 pm

   I think you already know which side of the fence I’m on but I feel your disadvantages of bzr are pretty weak. Not popular and launchpad being new that is.

   Popularity isn’t important ease of use is. Also launchpad might be new but I have had a better and faster response with launchpad via irc then I have ever had with sourceforge and that includes when I was subscribing.

   I can’t help but notice that even though you list git with the most problems you are giving in to the marketing hype.

8. Steve Says:
   September 28th, 2009 at 1:23 pm

   @Andrew: Actually popularity is very important when you want to get developers involved. If it were for a private project, I’d probably use Bazaar and self-host based on my experience with it so far. But for a public project, what percentage of the community will already be familiar with using the VCS tool is *very* relevant.

   The main reason I’m even considering Git again is because, as I stated, the GUIs are surprisingly nice. The command line still has major usability issues, as I said. That’s not giving in to marketing, that’s weighing my real practical experience so far. I recognise that most of my issues with Git are avoidable via the GUI, and that people already use it a lot – I don’t like that as an outcome, but them’s the facts. You obviously have a bias towards Bazaar, but I’m trying to look at it objectively and resist letting my personal hate of the git command line design override all other concerns; I have to look at the bigger picture.

   But, no decisions have been made yet. If Mercurial goes out because of the lack of Mac GUI tools, and Bazaar works well on Mac and converts well from svn, then I’ll need to canvas the community to see what the feeling is there.

9. Andrew Fenn Says:
   September 28th, 2009 at 1:40 pm

   Hi Steve. Think I double posted. Sorry about that. I’m actually on my phone right now so it’s difficult to post.

   I don’t really have a bias towards bzr in more the fact I think the disadvantages for bzr are unfair. I think that they all have similar levels of popularity in the open source arena.

   Although I use bzr for my own project I haven’t had much problems with git either. However I haven’t used it as much as bzr.

10. blankthemuffin Says:
    September 28th, 2009 at 1:52 pm

    I’d probably find bigger things to complain about with git than the -a, it’s the result of ( in my opinion, although it would seem this is a love/hate thing ) a pretty darn useful feature, the staging area. It allows you to selectively ( per file, or even per chunk in a diff ) commit changes to your local repository. So while I may make several different changes in one sitting, neglecting my good version controlling habits, I can commit them separately as they should be. -a is just a shortcut to throwing all your changes into the staging area and committing that.

    So while it’s a difference, I think it’s one of the more worthwhile differences. One of the things which I found more annoying was calling the staging area the “index” which throughly confused me, luckily this seems to have been rectified.

    Just noticed this too:
    “And please explain to me why it’s a good thing that commit without the -a (ie the default behaviour) takes an older version of the file than the one you’re building with.”

    Commit without the -a will commit whatever is in your staging area, when you stage a change, you stage a snapshot. If you modify the file again, it is a separate change to the staged one.

11. Steve Says:
    September 28th, 2009 at 2:03 pm

    @Andrew: I think claiming bzr has similar levels of popularity to git is being a little optimistic. Rightly or wrongly, (and no doubt helped by Linus’s & Linux’s profile), git definitely pops up *way* more often than Bazaar in discussions I have with developers. Mercurial is in between. But, we’ll see what our community says later.

    @blankthemuffin: “Commit without the -a will commit whatever is in your staging area, when you stage a change, you stage a snapshot. If you modify the file again, it is a separate change to the staged one.”

    You’ve succeeded in describing *what* it does, but not why that’s a good default. Yes, it’s useful to stage things, I’m not disputing that. But when almost all developers come from a background where the default is to commit your working folder, not some separately staged set of changes (which do not represent the build you have just tested in your working copy, and the golden rule is to only commit what you’ve tested), taking only the previously explicitly staged changes by default is not expected behaviour. And as I say, most developers I know ‘add’ files when they create them so they don’t forget, at which time their contents are either empty or not finished yet, therefore the ‘change’ that represents in this stage area is useless.

    The fact that the likes of TortoiseGit change this default behaviour is a definite indication that the command-line does not exhibit intuitive default behaviour.

    FWIW, Mercurial’s queue commits are a far better way of managing staged changes IMO. In git the staging area is a bit of a mess of temporary stuff, stuff that’s been added, stuff that’s been explicitly staged etc. I like that in Mercurial you can package a commit up as a qcommit, which behaves just like a commit but it stashes it in a staging area, rather than a real branch. I think this is a far more intuitive way of handling groups of changes you don’t want to formally commit yet.

12. Dirkjan Ochtman Says:
    September 28th, 2009 at 2:42 pm

    Sounds like a reasonable analysis. I’ll ask the TortoiseHG team to have a look, to see if they can fix/improve upon the issues you’re describing. If you have any questions about hg usage or integration, feel free to contact me on twitter or come to #mercurial on freenode!

13. SharedProphet Says:
    September 28th, 2009 at 3:07 pm

    Is there a reason you’re not looking into just doing Subversion hosting somewhere besides SourceForge. Assembla, for instance?

14. SharedProphet Says:
    September 28th, 2009 at 3:08 pm

    Er, that first sentence was meant to be a question. : )

15. Steve Says:
    September 28th, 2009 at 3:11 pm

    @Dirkjan: Thanks, for the benefit of TortoiseHg I should probably be more specific about what I mean by ‘clunkier’. Here’s a few things off the top of my head:

    1. No explicit recursive Add.. or Revert.. context menus. You have to use the generalised View File Status and manually filter it by status if the list is too big, which is clumsy.
    2. Even when there is an explicit ‘Revert’ option on single files, it just opens the same generalised dialog where Revert is one of many toolbar options. Confusing since I already selected that as my action, but I now have to select it again. The same goes for Remove.
    3. The ‘Add’ action on has no confirmation dialog when applied to a selection of files, which is inconsistent with other Tortoises.
    4. The default font used for the list views is nasty and takes too much space because it’s monospaced.
    5. The diff view in ‘View File Status’ is very basic, but when you fire up the ‘difference’ view it opens an intermediate window. Even if you select ‘Always launch single files’, when closing the external diff this intermediate window is left behind, and it serves no purpose.
    6. Why don’t you use TortoiseMerge as the visual diff by default like the other Tortoise variants?
    7. On multiple occasions the icons of parent folders did not update to reflect changes within them, even after explicitly telling them to refresh.
    8. On a more general note, the navigation style is unnecessarily different from all other Tortoise tools. TortoiseSVN, TortoiseCVS and TortoiseGit all look roughly the same in terms of their dialogs, while TortoiseHg takes a completely different approach (a generalised dialog to handle all actions which does not specialise based on what you selected in the context menu), which I don’t really understand considering how popular the others are. I find TortoiseGit much more familiar and comfortable as a long-time user of the others, despite preferring the underlying principles of hg.

    I’m using TortoiseHg 0.8.1.

    @SharedProphet: I’ve been considering moving to a DVCS for a while anyway, so rather than start paying for a SVN server (right now, I don’t trust the performance I’ll get out of free options) I might as well start paying for a ‘final’ destination.

16. Jelmer Vernooij Says:
    September 28th, 2009 at 5:30 pm

    @CABAListic FWIW Bazaar supports line-ending conversions these days through a plugin (bzr-eol).

17. Steve Borho Says:
    September 28th, 2009 at 8:30 pm

    Thanks for taking the time to enumerate your TortoiseHg griefs, I’ll try to respond to each:

    1. Doing an add from the shell context menu on a folder should do a recursive add to that folder. If not, it’s a bug.
    2. Yeah, this used to be even clunkier, but still needs improvement.
    3. This was actually a feature request. A lot of users wanted adds to be as efficient as possible, so we skip intermediate windows. If we had a solution to #2, we could do this better.
    4. The font is configurable (gtools.fontlist), but not in a friendly way.
    5. The intermediate window works around flaws in many visual diff tools. It can be skipped entirely if your diff tool does not need the ‘training wheels’. User config->tortoisehg tab->Skip Diff Window
    6. The Mercurial community seems to prefer kdiff3 over TortoiseMerge. That said, THG will use TortoiseMerge if it is installed and selected: User Config->tortoiseHg->three way merge tool.
    7. There’s a couple of open bugs for similar problems.
    8. THG is written in PyGTK, while the other tools are primarily C++. THG shares no code with the other implementations, beyond the overlays provided by the TSVN project. On the plus side, this means THG can run on Linux and Mac. On the downside, we’re starting from scratch. The specialization issues (#1, #2, etc) are mainly caused by lack of resource. We’ve been focusing on architecture issues for the most part. UI warts are just now being tackled en masse.

    Release 0.9 is due to come out on Nov 1. The changelog and commit tools have been greatly improved and everything else has been polished. If opened a feature request for #1 through #4, there’s a good chance they can be fixed as well.

    Cheers

18. Arseny Kapoulkine Says:
    September 28th, 2009 at 9:08 pm

    I second the tgit/thg controversy. In fact, the horrible TortoiseHg gui (who the hell decided to make something THAT different from tsvn?..) is the only thing that’s keeping me from switching to hg for my projects. All other GUIs for Hg I’ve seen are also horrible, I don’t know the reasons. It’s as if the developers don’t use their own GUI, preferring command line operation.

19. blankthemuffin Says:
    September 29th, 2009 at 12:11 am

    I saw right after I posted that that may have seemed rather condescending, that one has to misunderstand a feature in order for them to disagree with it.

    Having a bit of a think about it, there really would be no loss to having ‘git commit’ committing all changes, and ‘git commit –staged’ committing what is in the stage currently. As well as the migration issues you mentioned, considering more often than not I commit the entire change-set, it would seem intelligent to have it that way. I think the trick with these things is making the power readily available, while still highlighting the simple, most likely actions.

20. jntesteves Says:
    September 29th, 2009 at 6:01 am

    Launchpad is, if I remember well, already in the way of supporting private projects. Since it’s a commercial service from a company that intent to profit from it.

    Bzr looks really nice. I like the way it tries to be so simple that even people who have never ever used another VCS will not have a hard time using it.

    Most people never used it just because there isn’t a lot of open-source projects using it right now. But that doesn’t mean the Ogre community can’t be one of the first. (And it is actually hosting Ubuntu, so it sure can do the job here)

    If you liked it and are seriously thinking about adopting it, I think you should just go to the forum, tell everybody about your decision and ask if anyone have any complaint.

    I don’t see any reason for anyone not willing to learn it, since it seems so damn easy.

21. Steve Says:
    September 29th, 2009 at 9:32 am

    Yes, I intend to approach the community once I feel I have a solid grasp of the alternatives myself. Fact is I’m still testing myself for now.

    Even though I find Bazaar intuitive initially, I’m not sure I like its approach to branches; that is that one folder only ever contains one branch and is in many ways a separable repository of its own. It means that you can actually merge changes between branches with a Pull/Push if you want to, which feels very weird and seems like it might confuse things. However, if you do use the Merge option, it works easily and the history is properly preserved. The other effect of isolating branches within folders is that you can only Pull/Push one branch at a time, so if I had changes in more than one branch I’d have to do it from 2 different folders. Of course the argument could be that it’s messier to switch branches in-situ and commit changes to both in the same folder, and simpler to keep them in their own folders. But, it’s nice to have the option.

    Also while Bazaar Explorer is very, very nice, TortoiseBzr has a few rough edges still. But I felt quite comfortable in Bazaar Explorer because of the way it was context-sensitive, suggesting next actions like committing pending merges.

    Finally, because Bazaar can operate in different ways, centralised, decentralised and hybrids, I found it difficult to know what ‘Update’ did in the explorer. Also I couldn’t figure out how to switch branches within a working copy in the GUI, which is something I do a lot. So, definitely more time needed.

22. Steve Says:
    September 29th, 2009 at 9:42 am

    @Steve Borho:

    Thanks for the responses. Hopefully the points didn’t come across as too ungrateful, I realise you’re doing this work voluntarily; but I do think addressing them will help THg appeal to more people. I’ll just cover the points that need extra clarification:

    1. Actually my problem is that there is no “Add…” context menu item, when you select a folder that’s already in the repo (like the root folder). In all the other Tortoises you can do this to get a list of all the files not in the repo from this level downwards so you can pick them for adding. In THg I have to use Commit.. or View File Status dialogs and filter it manually.
    3. Ha, ok. I don’t agree with it personally; it’s very easy to accidentally pick the wrong context menu option and not having a confirm dialog is again at odds with the other Tortoises.

    I’ll raise feature requests as you suggested. Thanks for taking the time to answer.

23. jacmoe Says:
    September 29th, 2009 at 10:44 am

    Steve – you’re a tough costumer.
    You just can’t be pleased.
    But one thing I really like about TortoiseHg is that most of the stuff happens in the Commit dialogue.
    I never add files directly, only through the commit interface. That’s where I ignore, remove, etc. as well.
    And it does ask me if you want to add/remove files when I push the commit button.
    For all my daily work, I’ve promoted View Changelog and Synchronize to the main menu, and I almost never go into the submenus.
    Well, each to his own.
    I work a lot faster with TortoiseHg than with the three other Tortoises I’ve used.

24. Steve Says:
    September 29th, 2009 at 1:34 pm

    @jacmoe: Seems you like the very bits I don’t like. I’m extremely happy with the interface approach of the other Tortoises, which is why I find THg so odd. I think if it intends to be different it shouldn’t be called TortoiseHg, that might head off some expectations – the Tortoise prefix suggests similarity with TortoiseCVS and TortoiseSVN, which I’ve used for years – TortoiseGit and TortoiseBzr certainly follow that general approach too. THg is the only one of the 5 that differs so much, so maybe it should be renamed. It’s fine to be different if that’s a deliberate choice, but maybe the THg name should be left for someone else making one that works more like the others?

25. Steve Borho Says:
    September 29th, 2009 at 2:41 pm

    The main reason TortoiseHg begins with ‘Tortoise’ is because it offers a shell extension. I actually argued against the name in the beginning, but it is what it is.

    As I mentioned, we share zero code with the other implementations, outside of the overlay registrations, which is the source of much of the discrepancies (combined with the fact that I’ve not used any of the other clients for more than a few minutes.)

    We’re a fairly small team of developers, compared to the other clients, but the rate of improvement has been substantial. There’s been 1200 commits since the last stable release in July.

    Thanks for the feature requests, I think we can fit those into the upcoming release.

    @jacmoe: sync functionality has been pulled into the changelog tool on the default (0.9) branch. You can preview incoming and outgoing changesets in the history browser. So you can probably demote Synchronize from the top menu after you upgrade.

    Cheers.

26. Steve Says:
    September 29th, 2009 at 2:51 pm

    Thanks for being receptive to my petty complaints

27. Jabberwocky Says:
    September 30th, 2009 at 6:06 am

    What is it about DVCS that you like enough to prompt this change, rather than simply migrating to a more reliable SVN host?

28. Steve Says:
    September 30th, 2009 at 10:07 am

    It’s mostly about community participation. Right now, unless you are an authorised committer the only way to exchange contributions is to use patches. They’re fine and all, but they have several problems when they’re non-trivial:

    • If a contributor has made many changes for different reasons, it’s awkward to generate separate patches for each of those things so they can be reviewed separately. It’s a real pain in fact. Since a DVCS allows local commits, each change can be identified & sseparated more easily, by both the originator and the recipient
    • If a contributor wants to work in collaboration with another community member, still outside the central repository, it’s awkward to have patches flying backwards and forwards. A DVCS organises this much better, allowing non-authorative hubs of development out in the community for temporary or experimental work. It also makes it easier for others to test community WIP changes. And, if multiple contributors work together, all the history is tracked so you can see who contributed what rather than just one big patch.
    • All these things together make conflict resolution considerably easier for non-trivial patches and community collaborations

    For small private projects I don’t think DVCS makes a great deal of sense, but for open source and other large projects I can see definite benefits. We have cases where people go off and try things out outside the core team, or who build up large patches including a few different things they found & changed, and that is awkward to manage sometimes – a DVCS will make that considerably easier, and promote even more community experimental & collaborative development I think. The best stuff can then make it back into the core more easily at the end of that too. So we still get the robust checking & evaluation for the core, which operates mostly the same as with SVN, but community contributors are able to work more efficiently, both alone and together.

29. ASpanishGuy Says:
    September 30th, 2009 at 5:57 pm

    I’m crazy or i prefer git over mercurial because it’s more easy to me…(perhaps my mind is like torvalds’ mind).
    I’ve downloaded lastest unstable tortoiseHg gui and oh, man, is overcomplicated. Perhaps is a problem of mercurial but i can’t be productive with it.
    First, how in the earth i can create a local branch (that i can only see and edit aka bookmark extension branch). How can i chery pick a commit? Why when i use bigger fonts and install tortoiseGit and tortoiseHg, shell menu icons are in weird positions (it’s a tortoisehg problem that forces them to displace). And why is so difficult to delete branches…

    I agree that git command line is weird, but power users use command line and if that sucks, they build tools to get around (like egit wrapper). In the gui area, Gitx on MacOSX rocks and tortoiseGit is better, and i found them (and git) more easy to use than mercurial (in fact, in mercurial there’re so many extensions and ways to do things like several kinds of branches, that noobies will be asking in your forums what’re the difference between an option and another).

    I agree that implementation sucks, i hate cygwin programs and msysones. I want native ones, that are designed to work in every computer(like Mercurial did). I hope that someday a git lib is developer, tortoiseGit is linked with it and everybody will be happy.

    My take. Wait another year before u take a decission Steve, continue to use SVN, and use git-svn module to work. It’s a bit buggy but it works. That’s how i started to use git and after trying several DVCS, i found that git with all his problems has a better workflow to me. Perhaps someday i change to another DVCS, who knows. but today i think that they all sucks and are not so polised as SVN and tortoiseSVN are/were.

30. Ciaran Says:
    September 30th, 2009 at 9:24 pm

    Steve – surprised at the strong disagreement about black boxes and ‘knowing how it works’. I’m pretty sure you know how your compiler and runtime libraries work behind the black boxes. You might not need that knowledge all the time, but when it comes to getting decent performance out of something, you’d be lost without it. Likewise, when using a garbage collected language, you can use it up to a point without understanding how the garbage collector works, but sooner or later you’ll come unstuck.

    To pick an example closer to home, I guess I could pick up OGRE and use it as a black box. However, if I’m making serious use of it, doing complex stuff, needing good performance, etc, I know I need to understand how it works inside.

    Relating that back to the VCS, if you’re a casual developer working on small projects with small teams, it probably doesn’t matter a) which one you choose, or b) if you know how it works. On the other hand, a large project with history going back (and that will go forward) many years, with many contributors – I would say it matters very much.

    As for the idea that commit -a should be the default – the staging area is not some occasional nice to use feature that git happens to have. It’s a fundamental part of what is, in my opinion, a much better workflow. (Maybe not typical, but FWIW I have NEVER used -a). Perhaps the reason it seems non-intuitive to you is that you are used to the SVN workflow. In that case, I think either it’s worth further investigation of the git way of doing things, or perhaps you just want SVN+some DVCS features, in which case you probably don’t want git at all.

    I like ASpanishGuy’s take on things actually – don’t rush the decision.

31. Owen S Says:
    October 1st, 2009 at 8:11 pm

    Steve, I have one word to yell:

    Gitorious! Gitorious! Gitorious!

    Forget GitHub. Gitorious is FAR better. As far as I’m concerned, it’s the gold standard for VCS hosting. It makes many things brilliantly easy – for example, you can do patch submission with git push, it has a change reviewal system, and so on.

    In other words, it’s awesome.

32. nikki Says:
    October 2nd, 2009 at 1:15 am

    Well actually, I’d say, why not use Subversion, but somewhere else?

    The thing with git not being similar to SVN and CVS etc. is that it works in a totally different manner. If you see the ‘DAG’ thing in it, it’s pretty cool (how it’s snapshots of trees, and commits pointing to trees etc.). But if you, the team, and most of the community are used to ‘centralised’ already, then I’d suggest sticking with a centralised approach VCS.

    The reason you’re having a problem with the git interface is, you already have a pre-defined notion of what ‘commit’ (for example) is. And, the notion of commit that svn gives, really doesn’t exist in git, so they couldn’t ‘name it the normal way’. The git idea of stuff is very different from SVN. If you do want to switch to a DVCS (or at least, git), then you’ll have to change a few ideas, it can’t really be helped, because that’s the way it works.

    Although yeah, the git documentation does need a lot of improvement. It’s more about the commands themselves than the concept.

    If you’re looking for git, but then, like SVN, so then what’s the point of switching? You got nothing different… If you’re looking to use git just like svn, there’s no point, because you’re not getting the advantages it provides.

    Best of luck, hope you think about it and make a good decision.

    Personally, I’d love to see Ogre on git because I’m a git guy myself.

33. nikki Says:
    October 2nd, 2009 at 1:21 am

    Oh and I forgot this. Do check out these pages first, don’t read th e git documentation, it’s more of a reference than a ‘conceptual introduction’.

    This is the popular ‘Git internals’ book from Peepcode. It’s a quick read (I went through it in 30 to 45 minutes). It’s well worth the 9$:-
    http://peepcode.com/products/git-internals-pdf

    Another nice ‘conceptual read’:-
    http://www.eecs.harvard.edu/~cduan/technical/git/

    If you’re thinking git, forget ’svn-ish commits’. Think branching, merging, rebasing.

    Kinda like, don’t write C in C++, don’t use git just like SVN.

34. nikki Says:
    October 2nd, 2009 at 1:29 am

    I’m just afraid that, if you switch to git and keep doing SVN, you really don’t get the DVCS benifits. You’ll have wasted a lot of time adjusting to a new environment. I mean, you haven’t even mentioned branching/merging etc. in your comparisions.

    Sorry about the multiple posts…

    And a wonderful git man page everyone should read:
    http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

35. nikki Says:
    October 2nd, 2009 at 1:47 am

    Ok, last, “the golden rule is to only commit what you’ve tested”, don’t worry about it. Commits are local. And about ‘git revert’ being a new commit that reverses old ones, maybe that’s what you want. So that, when someone pulls your branch (after having pulled the previous commit), he gets a revert. If you reset hard, then it’s a local ‘go back’. Git revert is for /after/ people pull your changes.

    Also, git reset is again not a ‘working copy changes revert’. It’s for redoing commits, but of course, you shouldn’t have pushed.

36. nikki Says:
    October 2nd, 2009 at 1:59 am

    Oh great, I just discovered this: http://www.stevestreeting.com/2009/08/06/getting-more-structured-with-my-dvcs-tests/

    

37. Steve Says:
    October 2nd, 2009 at 8:46 am

    I understand what git revert does. My point is that it’s no different to reverse-merging changes and then committing a new revision. That’s how you reverse changes consistently in other VCSs, I don’t see why it needs its own dedicated command. And zero marks on picking terminology that had already been used elsewhere to mean something completely different.

    I still think you should only commit code that builds & runs, even locally, because otherwise if you push that to others you don’t want there to be revs where the code won’t build or run properly. Of course with Git you can use the rebase command to erase the intermediate broken revs, but I think it’s better to be more disciplined and not rely on patching over crappy revisions, because you might forget to do it. Articles I’ve read about Git written by professional developers rather than random hackers who revel in the complexity they can create still have the kind of good practice guidelines most VCS users will find familiar. Even Linus admits that most Git users don’t understand when they should be using rebase or not, despite the advice he’s tried to spread. Just because Git *can* do it, doesn’t mean you should use it unless it’s appropriate – a fact that lots of Git users seem to miss and use that as an excuse not to follow any guidelines, because they can always fudge it back into shape again afterwards. It’s a bad attitude to take in a professional team.

    And honestly, don’t give me the line that Git is ‘totally different’ from other systems. Sorry, but it’s marketing nonsense. Its precisely the same ideas but extended considerably into the parallel development space, sprinkled with mutable history (which is the crutch that people rely on to compensate for the errors). Fundamentally most of the principles are the same (if not the centralised workflow), the tools are just more powerful in that context. At the end of the day the principles for keeping the authorative repo ‘clean’ are the same as those for SVN – you just have more tools to patch it up when people have screwed around. Yes, you can use whole new workflows that you can’t with SVN, that’s the whole reason I’m looking at them at all instead of just re-hosting SVN. But it doesn’t mean you should throw caution to the wind and hack away with no notion of good practice. Sure, someone can merge & rebase it into submission upstream to make it consistent, but not all projects are large enough to have people dedicated to just doing that, and that alone like in the Linux kernel. Other projects benefit from some sensible procedures which are not that unlike what you’ll find in SVN, just with far greater distributed power.

38. nikki Says:
    October 2nd, 2009 at 1:28 pm

    Actually, I think you’re right about the similarities. I was talking about differences in the ‘behind-the-scenes’ implementation parts. I personally don’t have much experience with SVN (just used it for one project, and then mostly an end-user), I can’t say, you’ll have a better idea about it.

    Have you checked out the git notions of ‘commit’, ‘tree’, ‘blob’, ‘tag’ etc.? I’d say undersanding the ‘DAG’ thing helps a lot when you work with git, it eases the workflow.

39. Steve Says:
    October 2nd, 2009 at 1:43 pm

    Yes, I’ve read up on these. Honestly, I’d say the need to explain them to all users is more of an indulgence on the part of the authors / enthusiasts than a necessity, they can be explained in much more real-world terms if you try a little. It’s like explaining how to use a web browser by starting with a von Neuman diagram. Linux suffered from this syndrome for years too, until the fact that you didn’t need to know how to rebuild your kernel to be a Linux user finally became mainstream. The fact is, geeks love to show you how clever they and their work is – it’s a failing in all of us. Anyone who just wants to use the software, however, invariably doesn’t care

    The DAG is fine but overemphasized. You can infer a DAG out of any VCS if you chose to (it’s a natural result of any revision process – you can make one out of Word documents if you want!), whether it’s the implementation data structure or just a logical principle is largely irrelevant when it comes to usage.

40. Steve Says:
    October 2nd, 2009 at 1:53 pm

    @Ciaran: “Steve – surprised at the strong disagreement about black boxes and ‘knowing how it works’. I’m pretty sure you know how your compiler and runtime libraries work behind the black boxes. You might not need that knowledge all the time, but when it comes to getting decent performance out of something, you’d be lost without it.”

    Sure, but the big difference there is that my own creations are directly dependent on those tools; my application quality is influenced fundamentally by knowing my compiler and libraries well. My VCS, in contrast, is merely an organisational tool – it doesn’t affect how fast my application will run, how much memory it will use, how the API will be exposed etc – any more than what text editor I use does. I don’t feel the need to understand how the syntax highlighting works in Visual Studio, because it makes no difference to the end result. It might be fun to find out, sure – but that’s a luxury, not a necessity. The same goes for my VCS – I just need to know how to *use* it effectively, I really don’t give a rats arse precisely how it works under the hood, so long as it works and the logical principles are clear.

    At the end of the day, while I might love to dig into the detail of everything I use, in practice I have work to do. There are a finite number of things that I have time to care about, a firm priority list. The internal workings of my VCS is quite a way down that list. My problem with the Git attitude is that it doesn’t seem to appreciate that – the documentation thinks that I should care deeply about how it works, rather than just how to use it, when in fact I have far more important and relevant things to be spending my time & energy on. Suggestions that you can’t understand how to use a tool unless you understand the implementation are outdated, a throwback to the Linux old-skool.

    So while I don’t have any particular difficulty reading up on the Git technical details, every time I read something exitedly telling me how you have to know all that to *really* know how to use Git, I just can’t help thinking “these guys don’t have a clue what the real world is like”, which undermines my opinion of it.

41. ASpanishGuy Says:
    October 2nd, 2009 at 2:30 pm

    >So while I don’t have any particular difficulty reading >up on the Git technical details, every time I read >something exitedly telling me how you have to know all >that to *really* know how to use Git, I just can’t help >thinking “these guys don’t have a clue what the real >world is like”, which undermines my opinion of it.

    So easy solution to take. Use TortoiseGit because it’s more easy to use than TortoiseHg. But don’t get my wrong, i’m not a defender of Git(i have the same problems/ideas as you), but i don’t understand some funcionality of Mercurial and TortoiseHG is horrible on some aspects compared to TortoiseGit.

    If i had no tortoiseGit i would continue to use svn because although was fun learning how crazy was git, i would never use a tool that doesn’t have good gui*.

    So you have ways: wait another year or ask your comunity which VCS to use.

    *) If someone makes a tortoiseHg like tortoiseSvn and tortoiseGit, with all their features integrated in windows, and fix the problems that i stated in my previous post(like local branches). I’ll not have problems to change to Mercurial.

42. Steve Says:
    October 2nd, 2009 at 2:43 pm

    I definitely agree TortoiseGit is easier than TortoiseHg. I’ve also discovered Easy Git (http://www.gnome.org/~newren/eg/) which seems to fill the gap for command-line users. But, as I’ve said, it feels a little wrong to rely on wrappers to make a tool’s interface palatable.

    I need more time to evaluate them properly with my list of use cases, but I just have too much “real work” right now to do it. There are some features of Git I like over Hg, such as the discardable local branching, but I need to see how everything pans out in practice. Realistically it’ll be a while (weeks or months, not days).

43. Josh Jensen Says:
    October 3rd, 2009 at 1:21 am

    I believe it is very important to submit one change per changelist. Too often, though, I find myself working on one feature, and in the course of that work, I find a bug and fix it in the same file as the feature I’m working on. Now I have two changes in that changelist, a bug fix intermixed with a real feature. Ack! To make matters worse, I fixed some whitespace along the way, too.

    In Perforce/Subversion/svk/Mercurial/Bazaar, I commit the file with following description:

    * Added new feature.
    * Fixed bad bug.
    * Cleaned up some formatting.

    Now, to the next Joe who comes along, he has to muddle through my whitespace changes and try to determine what is the feature and what is the bug fix.

    I’ve dreamed about a feature like Git’s staging area for years. Using the very handy ‘git gui’, I stage the whitespace lines/hunks. I commit the whitespace as a single changelist, and by description, it is very obvious what it does and why any user can immediately ignore it. I then stage the appropriate bad bug hunks and commit the “Fixed bad bug”. For another developer, there is no doubt that it supposedly fixes the bad bug, and all the code that does it is right there. Finally, I commit the new feature.

    Mind you, I didn’t hit the command line for any of this, as all of this functionality is easily accessible within ‘git gui’.

    The one time I need to touch the command line is when I might have wanted to ensure that fixing the bad bug compiles without issue. Generally, I don’t care, as I push all changes at once from my local branch, but assuming I need that assurance, I run:

    git stash –keep-index

    This saves my working copy in the stash and leaves behind my staged bad bug code. I then test, commit, and restore the stash.

    Unfortunately, git gui doesn’t have stash support, and none of the GUIs have –keep-index support except for Git Cola (that I am aware of).

44. Josh Jensen Says:
    October 3rd, 2009 at 1:41 am

    I spend 90% of my time within the built-in ‘git gui’. At first, I was appalled at the ugliness of the tool. Then I found it was functional in ways I never suspected. I immediately became more productive as I didn’t have dig through dialog boxes to get the information I needed.

    Within the git gui screen, I can see all files that have been modified, need to be added, or are missing from my hard drive. Clicking on a modified file shows me just the diffs from the file where I can select lines or hunks to stage for the commit. I’m not a fan of looking at diffs, but in this case, seeing all modified portions of the file at a glance is useful.

    Another list shows me all the files that have been staged. As with the first list described above, I can click on a staged file and see the diff. With that view, I can unstage lines and hunks from the commit.

    There is an editor to update the description used to commit the files. I can edit the description while viewing the diffs. That is fantastic, as most GUIs make me diff in another window, and I have to task switch back and forth.

    That’s not all. From this same screen, I can stage any changed file, push to the remote repository, and amend my last commit. From the menus, I can view history (very convenient with at a glance diffs available for all files within the changelist), create/checkout/rename/delete branches, revert files, perform merges, and push and pull changes to/from remote repositories.

    TortoiseGit may look and act like TortoiseSVN, Git Extensions may have Visual Studio and Explorer integration, Git Cola has lots of neato things, and so on for the others, but none have as functional of commit dialog (where I spend most of my time within a VCS) as Git Gui.

    Finally, Git tutorials/books always focus on the command line. For the majority of the work I do, git gui does everything I need. GUIs should be more of a focus within these articles/tutorials/books.

45. Steve Says:
    October 3rd, 2009 at 10:29 am

    Yes, I completely agree that it’s a good idea to separate out the subject matter of your commits. This is especially the case when submitting changes upstream, where some may be accepted and some may be rejected.

    I don’t think the staging area is a great solution for this on its own though, because the state you staged is not necessarily the complete state you built & tested with in your working copy. In your example you resolved this using the stash option, which is actually directly anagolous to how I do this kind of thing in SVN right now. The difference is that if I want to pull out a single change from a mixed working directory and commit it, I generate a patch for those changes and move it across to a clean copy, and build / test / commit it from there to make sure it’s consistent. Your stashing approach is very similar, except that you’re doing it within one working folder.

    My problem with the stage is that it encourages committing manually tweaked, potentially untested changes. If you follow good practice then it’s not a problem (like your stashing approach to allow you to test the staged changes separately), but I see so many people who don’t consider this necessary. They think it’s fine to pick changes manually and stage them as a change without ever testing them on their own, and I think that’s wrong. I’d say you should only ever push a changeset that you’ve tested in that state, so it would be better to have support for staging and grouped, queued changes, but only to commit from a working copy version. Provided you still have the ability to stage / stash this should be no problem and no loss of flexibility, it’s just that you’re being encouraged to commit what you’ve actually built, not some separately picked set of changes. This is what Mercurial qcommit does, and that’s why I prefer it to the Git staging area.

    I would like to take qcommit and the general command-line from Mercurial and put in Git, or take Git’s local branching, TortoiseGit and its speed and put it in Mercurial. Sigh.

46. Josh Jensen Says:
    October 3rd, 2009 at 6:09 pm

    There are plenty of times when I can look at a change and decide there is no problem submitting it without all the other changes. I change whitespace, for example, and I can commit it with little worry. I make two independent changes in different files, and I know it is safe to commit the change from one. If I make two independent changes within the same file, I can make a determination that neither will conflict with one another and commit.

    In fact, TortoiseSVN allows me to selectively commit certain files. Whether I choose to use that feature or not is up to me. Technically, I should commit everything, because that is what I tested against. Nonetheless, the developers provided me the power to make my own decisions.

    Git takes it a step further and gives me the power to selectively commit portions of a given file. I don’t have to use it, nor do they specifically encourage me to use it. The important part is I have been given the power to make very granular commits according to my own needs and desires. It is just another tool to ease the development process.

    In any case, I’ve made it clear that I have little issue (most of the time) submitting portions of a file, and you require all changed files to be submitted at once. Git nicely supports both workflows.

47. Josh Jensen Says:
    October 3rd, 2009 at 6:14 pm

    With regard to Mercurial’s qcommit and patch queues, how does it compare to StGit. From what I’ve read, they seem very similar.

    I spent some time with StGit. It has a neat workflow, but it doesn’t preserve my history, if I understand it right. That is, I make a Change A to the patch, and then I modify Change A and add it as Change B. Change A is no longer preserved within the history. If I need to roll back to it, it is gone.

    If I had developed my feature within a branch, I could have retrieved Change A from the history.

    Does a Mercurial patch queue do it differently?

48. jacmoe Says:
    October 4th, 2009 at 1:16 pm

    I’ve found the Mercurial transplant extension to be a real lifesaver: it allows you to transplant a changeset to another branch. As long as your commits are atomic, it works splendidly. Really close to cherry pick for Git, except that most things (if not all) happens on the changeset level in Mercurial (AFAIK).
    On weirdness of TortoiseHg is that most of the action happens in the View Changelog dialogue.
    Use the right-click menu on a node and you’ll see..

49. Steve Says:
    October 4th, 2009 at 8:06 pm

    @Josh: My problem with this is that I’ve seen coders make mistakes countless times with a partial commit because they thought they knew the extent of the changes, but missed something. Hell, I’ve done it myself many times. Whitespace & comments are all very well, but I think generally condoning manually selected commit subsets is bad practice. Anyone who has deployed a product release into a live, mission-critical environment will tell you that it’s not good enough to have tested something unless you’ve tested that specific combination – it’s not enough to interpolate / extrapolate from ’similar’ tests, just because you think you know the system. Personally I take the same approach to my code, and I’ve always encouraged my staff to do the same. Developers screw up and make bad judgements about the safety of changes all the time – I know that because I am one

    I’ve never tried StGit, I’ll have to compare.

50. Ian Clatworthy Says:
    October 6th, 2009 at 2:27 pm

    Hi Steve,

    Bazaar 2.0.0 was officially announced today and our new website was rolled out yesterday. If we’ve done our job right with this release, Bazaar adoption will pick up a lot in coming months.

    Thanks for the nice words about Bazaar Explorer – I’m the primary author. If members of your community are worried about learning Bazaar, maybe the new “Visual Tours” we’ve put together will put their mind at ease. See http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html for example. Explorer is now bundled with the Windows installer and installed by default. It’s a breeze installing it on Ubuntu too. We’re currently working on an all-in-one Mac installer – it’s currently a bit messy getting it installed there but I hope that changes in the next week or two.

    If you’d like improvements made to Bazaar Explorer, be sure to let us know. We’re trying really hard to make it a tool that power users (like me) can live in continuously while still being simple enough for casual contributors to be highly confident in using. (In our experience, encouraging casual contributors is a key part of growing community around your project.) We still have plenty of improvements to make but I’m confident we’re on the right path.

51. Steve Says:
    October 6th, 2009 at 2:37 pm

    Yeah, congrats on Bazaar Explorer, I really liked it.

    The thing that bothers me a bit about Bazaar now is the way branches are handled; that is that a repository path *is* the branch. This is quite like SVN on the server-side, but propagated everywhere, and I found when using it in a working copy that it felt a bit weird not being able to switch branches in-situ, and that merges could be done either via a push between branches or a ‘real’ merge, since branches are repos too. I’m not sure I could get used to that

52. Ian Clatworthy Says:
    October 6th, 2009 at 8:47 pm

    If you want a switchable working tree, just create a Checkout. To switch to another branch, use Work > Switch checkout.

    The Checkout can be under the repository (and Start > Init > Shared tree sets things up that way) though many users like to put their repositories/branches in one place and their checkouts elsewhere. It’s completely up to you and each user can choose whichever way of working they want.

53. Ian Clatworthy Says:
    October 6th, 2009 at 9:10 pm

    In Bazaar, branches aren’t repositories, though a repository will be created implicitly for a branch if one doesn’t exist yet. Working in a shared repository is highly recommended. Explorer 0.8.2 checks if the branch destination is outside a shared repository and offers to create one if it’s not.

    I’m not sure what you mean by using push to merge? To merge, use merge. If you’re keeping a mirror branch up to date, use pull. Here’s the normal process:

    1. Grab a branch from a hosting site. Explorer will suggest making a shared repository. Agree to that and Explorer will suggest a name of ‘trunk’ within the repository for your mirror.

    2. Create a feature branch called ‘fix-123′ or ‘feature-abc’ by selecting ‘trunk’ in the repository view and selecting the Branch button.

    3. Work in your feature branch.

    4. When it’s ready to land, open trunk and pull to refresh it. Then merge your feature branch into it and commit.

    You can get fancy by doing stuff like working in a checkout or by making trunk a bound branch. To begin with though, the process above is what I’d recommend.

    The one place where push comes into it is where casual contributors don’t have write access to the trunk on Launchpad say. Then they push to a branch of theirs and create a merge proposal for the core development team to review.

54. Steve Says:
    October 7th, 2009 at 9:35 am

    Thanks for the info. However “Switch Checkout” is always disabled for me and doesn’t exist on Tortoise Bazaar, which is probably why I never saw it.

    Also creating a branch doesn’t seem that obvious from within your own checkout. To create a branch, you have to select a source again.

    What I meant by pushing a merge is that because, when I created branches, they appeared to be just like any other repository and so I could push a change from one branch to another if I chose to, which just felt confusing. I would normally use merge too, but it was just an example of how the self-contained nature of the branches seems weird to me.

    I guess I’m not comfortable with the way branches exist in a pseudo-standalone way (as I perceive it), rather than simply being contained as a logical construct in the main repository. I’m sure it’s more flexible that way, but somehow I prefer branches to be bound in a containing repo rather than detachable as their own repo.

    I’m no expert in Bazaar, this is just my initial impression on playing with a few branches on my local machine.

55. Josh Jensen Says:
    October 22nd, 2009 at 5:44 am

    FWIW, StGit does preserve all patch manipulation history in a branch called branchname.stgit. It would be possible to retrieve an older version of the patch from that history, but it is somewhat ugly.

    What I would like to see is a view of the patch’s history itself, as if it were a branch. All the information is stored in branchname.stgit; I can see my prior commit. It just doesn’t show in a nice form within gitk (or if it does, I can’t figure out how).

    Ignoring that, StGit seems every bit as powerful as mq.

56. Steve Says:
    October 22nd, 2009 at 9:37 am

    In practice, I’ve actually found that Git’s cheap, private local branches are fine for handling these cases. I create a local branch or three (which are not linked to any origin branch) and build up unfinished patches there, and then merge them across to my main branch which I push upstream from when they’re ready. Works fine, and the level of control is actually very good. I find this infinitely more useful than the staging area because it’s multidimensional.

57. jacmoe Says:
    October 23rd, 2009 at 4:45 pm

    I tried to answer you on Twitter, but here goes:
    Rebase is included with Mercurial, and you don’t have to enable it.
    When pulling, you have four options: nothing, update, fetch and rebase. It’s in the Synchronise dialogue.
    One extension you’d want to enable is hgext.win32text which fixes eol issues.

58. Steve Says:
    October 23rd, 2009 at 4:53 pm

    I definitely did have to enable the extension before I could use ‘hg pull –rebase’ or ‘hg rebase’ on the command line. Standard Mercurial 1.3.1 just says it doesn’t understand the rebase command / option until you do that.

    I spotted that THg has the Rebase option in the ‘Pull’ dialog after I posted, but guess what – if you forget to select it during the Pull, you’re stuck. There is no separate Rebase option that I can find in THg, and you can’t repeat the Pull to do it because it does nothing when you’re up to date. The only way to resolve it at that point is to use “hg rebase” on the command-line, which like I say does not work unless you enable the extension.

    [edit]I think that the upcoming THg 0.9 supports a separate Rebase and Transplant, which will be welcome since TGit makes these operations much easier.

59. jacmoe Says:
    October 23rd, 2009 at 5:21 pm

    Ah – I think I got it because I’ve enabled the mq extension.
    Yep, that’s it.
    You can select the default pull action somewhere in the highly intuitive (not) configuration dialogue.

60. jacmoe Says:
    October 23rd, 2009 at 5:24 pm

    In your Mercurial.ini (In Windows, that is – .hgrc on *nix)
    put this:
    [tortoisehg]
    postpull = rebase

    This is my list of extensions:
    [extensions]
    hgext.win32text=
    hgext.mq =
    transplant=
    color =
    hgext.bookmarks =

    Transplant is great.

61. Steve Says:
    October 23rd, 2009 at 5:38 pm

    Thanks, that’s useful. However I do kind of like to do *just* Pull and then check what changes are before I decide what to do, rather than always rebasing. Especially if I have multiple branches active.

62. jacmoe Says:
    October 23rd, 2009 at 9:03 pm

    Hint: Use ‘Incoming’ first. It’s like a sneak peak.

63. Rob Says:
    November 11th, 2009 at 1:51 pm

    The -a thing makes a lot of sense to me. It has to do with working in terms of patches. We’ve switched to git at $work and a lot of times, I have a gazillion debugging statements in various files. I want to commit a fix for one of the three variants of the bug I’m working on, but I don’t want to have to back out all the warning statements I’ve added for tracing because I have two more variants to hunt down.

    Yes, it takes a little getting used to sometimes. But, that’s not a bad thing.

64. Tero Says:
    November 14th, 2009 at 12:09 pm

    I made same kind of evaluation for some time ago and my choice was Mercurial: http://alen.mobi/blog/2009/07/30/i-prefer-mercurial/

    I have been using Git and I didn’t really like it’s cli interface. After Git I tried Mercurial and it was really pleasant to use because I come from Subversion. I haven’t used any GUI tools for version control, so I can’t say anything about them, but from command line Mercurial rocks

65. jacmoe Says:
    November 14th, 2009 at 7:38 pm

    Steve’s leaning towards Mercurial now – read this:
    http://www.stevestreeting.com/2009/11/06/dvcs-score-card/

    And the topic @ the Ogre forum:
    http://www.ogre3d.org/forums/viewtopic.php?f=4&t=53129

Leave a Reply

Search

Follow Me on Twitter

• Managed to crank out *some* code today, but working through a fog of decongestants and menthol inhalers is terribly sub-optimal. *poweroff*
• Hats off to them, Epic Citadel really is impressive to see running on an iPad.
• Open source PSGroove now allows you to run full homebrew code on a PS3 http://github.com/psgroove/psgroove . Nice!
• Having a major head cold, and the rational thought required to code, are not happy bedfellows.
• @SnappyTouch my experiences are what led me to decide to write a new git & hg UI for Mac (beta soon :))

Recent Comments

• Steve on hgsubversion – dropping old history during conversion (mod)
• codekoala on hgsubversion – dropping old history during conversion (mod)
• Steve on Complete guide to using a Roland TD9 in Rock Band
• Erik on Complete guide to using a Roland TD9 in Rock Band
• reptor on Why I won’t be updating Facebook anymore

Professional

• My LinkedIn Profile
• Torus Knot Software

Projects

• OGRE

Categories

• Books
• Business
• C++
• Cocoa
• Comedy
• Development
• DRM
• Films
• Food
• Games
• Google
• hardware
• Health
• History
• Internet
• legal
• Linux
• Local
• Music
• Objective C
• OGRE
• Open Source
• OS X
• Personal
• Political
• Random
• Sci-Fi
• Tech
• Travel
• tv
• Uncategorized
• Web
• Windows

Tags