The thing about Github

Posted by: Penny Leach 3 years ago

(6 comments)

After talking with Lukas on Thursday night, I realised that I've got a bit of a reputation as a Github hater. (As an aside, I seem to be often writing blog posts dispelling myths that people believe about me - why is this, I usually say what I think but maybe it's just that I don't express myself properly). So to be clear - I don't hate Github at all. I don't really use it, other than a few exceptions that were policy based rather than choice based. I am inherently deeply suspicious of what I think of as the mac-owning github-using whiskey-drinking ruby-on-rails hipster rockstar-geek crowd (I wrote about this before, in 2008), and despite my best efforts, seem to be surrounded by them, which in and of itself is rather alienating. But let's just say that I left my feelings about Github to mild interest, a good dose of wariness, disappointment that the FOSS equivalent, Gitorious, isn't really as good, and mild annoyance that when I was forced to use it for a work a few times it was down.

However, I recently started doing a lot more running (surely coinciding with my foray into unemployment) and having exhausted the Radio New Zealand play I was listening to and giggling at the familiarity of the accents which I miss living on the other side of the stupid world from home, I turned to Podcasts for the first time in my life (really sometimes I do think that I'm deliberately keeping myself in the dark ages). Anyway today I listened to this interview with Scott Chacon from Github and was quite struck by it. I think the two most interesting points he made where I found myself thinking, "yes! exactly!" were about the vastly improved development workflow that git encourages if you are open to it - I think he used the words, "crafting commits" - which would hugely benefit the development community and help us to produce higher quality code, and the second was about actually learning a bit about what git could do and how to really use it (compare to how well you know your editor) rather than just memorise the few commands that you need to just keep going because it's a necessary annoyance that you need to live with. 

I am continually frustrated by the fact that people don't think exactly like me about this - "what, I need to read the diff before committing it?" makes my hair catch fire with rage, seriously. So if Github is making git more accessible to people and this is improving the development practices of the community, then I say, Go,Github Go!

As an aside, another tool mentioned in this episode was Showoff, which looks really interesting - a text based presentation format that you can keep the source code to in Git. I have been using Latex Beamer for my slides for years for this reason, which is kind of a bit like trying to nail jelly to the ceiling and getting so frustrated in the process that you gouge out your eyes with blunt spoons. So I'll be definitely taking a look at that.

Comments

  • Richard Clark 3 years ago

    I use github extensively. I think they've done an excellent job of building a good tool for storing code and a smattering of simple, elegant tools around that for projects that aren't too complex.

    It really is a pleasure to use, and that makes me happy all by itself.

    Link / Reply
  • david 3 years ago

    i started to use github, and have seen that the simple fork / pull request concept is really amazingly simple, cool, transparent and makes people work differently.

    however, you are very locked into the system. (i mean, you can use other git repos of course, but the easy-to-use features are only there if everybody is on github).

    and its only free as in free beer. never bothered to read their contact stuff in detail, but i guess they could start to make stuff paying. or just go bankrupt and leave projects without their meta data. as with sourceforge or all the freemailers and so on...
    at least with git somebody will have the most recent version of the repository locally, which is a vast improvement over svn...

    Link / Reply
  • gordy 3 years ago

    How can you even write a decent check in message if you don't review the diffs and write the message from the logical changes made not their implementation. There is nothing more useless than "renamed variable x to variable z" because it fails to answer the question "why was this change made"; I can work out the "how" from a simple diff.

    Yes, all too often I work with developers who view source code control as some kind of machine backup and they check in every day even if it breaks the build. Where does that learning experience come from?

    Link / Reply
  • Penny 3 years ago

    @Richard yeah fair enough. A lot of people find it really easy and elegant to use. I personally find it weird to use - a commenter on the facebook import of this entry (grr) wrote that the early gitsters are used to gitweb and the 2nd wave gitsters grew up with github and I wonder if that's part of the difference.

    @David yeah after talking a bit yesterday with Michael Schwern, I realised that part of my problem stems from essentially what the value add of Github is, which is the workflow (and paper trail) around Pull Requests just centralises the workflow that I've been using for years already, which is publishing and viewing alternate public repositories and sending "pull requests" on mailing lists, bug trackers, and irc. Github centralises that, which is arguably a good thing, but in a way that makes me nervous about control and .. well you know I'm a control freak.

    @gordy yeah that's exactly my frustration. I really hope that github is going to force these people to pick up their game by teaching them good workflows, but if they just memorise the 6 commands that are the equivalents of the ones they used in svn, it'll never work, which I think is part of the point the podcast was making.

    Link / Reply
  • simon 2 years, 2 months ago

    spoons are blunt anyways

    Link / Reply
  • Samuel Bronson 1 year, 4 months ago

    Actually, one of the nice things about distributed VCSes is that you still have time to check the diffs even *after* you've committed, since committing is decoupled from publishing.

    (Though, now that I think about it, I've probably got some darcs repositories symlinked straight into a web tree, so if I do "darcs record" there that really does publish the changes right away...)

    Link / Reply

New Comment

required
required (not published)
optional

Recent Tweets

Recent Posts

Archive

2013
2012
2011
2010
2009
2008
2007
2006
2005

Tags

Authors

Feeds

RSS / Atom