processi

about processes and engines

talked about git and github

last night at the August Ninjava meeting.

The second talk was about Erlang, Joe Norton gave us an overview on this language and tools around it. Extremely interesting. Looking forward to dig more about the finite state machines lib available.

Here are my slides, very shallow. Follow the links after the slides to learn more.

(pdf download)

* http://video.google.com/videosearch?q=linus+git to reach the Tech Talk from Linus Thorvalds about Git
* https://peepcode.com/products/git-internals-pdf Scott Chacon’s “git internals” peepcode, excellent
* http://gitcasts.com/git-talk Scott Chacon’s talks about git, I recommend the ‘voice over‘ he did with his RailsConf 2008 slides
* http://osteele.com/archives/2008/05/my-git-workflow Oliver Steele’s git workflow (very nice graphs) (followup on commit policies)
* http://tomayko.com/writings/the-thing-about-git Ryan Tomayko’s git workflow (maybe it’s better to read it after Oliver’s one)
* http://www.kernel.org/pub/software/scm/git/docs/user-manual.html the user manual
* http://github.com
* http://repo.or.cz
* http://gitorious.org (the source itself)

Written by John Mettraux

August 21, 2008 at 11:41 pm

Posted in git, github, ninjava

5 Responses

Subscribe to comments with RSS.

  1. Thanks for mentioning PeepCode! The link you provided was actually to our screencast. Scott’s PDF is here:

    https://peepcode.com/products/git-internals-pdf

    Geoffrey Grosenbach

    August 22, 2008 at 6:13 pm

  2. Oh, updated the link.

    Thanks a lot. Keep up the great work !

    John Mettraux

    August 23, 2008 at 1:25 am

  3. Interesting. One thing that has always bothered me in the distributed version control is the lack of one true revision number. I guess that can be countered by methodology, but so far I haven’t seen any best practices documents (admittedly I haven’t searched much.)

    If you have time, it would be great if you can write a piece about how did Git changed your work style (i.e. things you couldn’t do before, but can now; things that are now so much faster that you can do them more often; things that you stopped doing; commit granularity, etc.)

    Dimitar Dimitrov

    August 25, 2008 at 6:26 am

  4. Hi Dimitar,

    I recommend the two blog posts :
    http://osteele.com/archives/2008/05/my-git-workflow
    http://tomayko.com/writings/the-thing-about-git

    As for myself, “I don’t branch enough”, Git makes branching easy so I should use it more, but I currently don’t enough.

    For the “one true revision number”, would something like this commit number : http://github.com/jmettraux/rufus-sixjo/commit/7d5a0afd399eeb9dbee0a2ac79b950fcb4567535 tend towards your ‘ideal’ ?

    Granted “http://github.com/jmettraux/rufus-sixjo/commit/7d5a0afd399eeb9dbee0a2ac79b950fcb4567535” is a bit long, but Git is smart enough to let you use just 4 or 5 of the first chars of this md5.

    For the post on the impact on my work style, I need more time.

    Cheers,

    John

    John Mettraux

    August 25, 2008 at 6:51 am

  5. Thanks, both articles were great! If nothing else, one thing I realized is how much I am dependent on my IDE :-)

    Usually I hold a commit until I have a working feature, so sometimes I find myself wanting to go back in time a couple of hours – in this cases I use IDEA’s Local History (sort of persistent undo). Consequentially, I often have Ryan’s problem separating unrelated changesets, in which case I use the IDEA changesets manager and sometimes the “shelve changes” function (if I want to test each commit separately.)

    Git allows to handle these scenarios from the command line without limiting the editor and other tools you use. Another cool feature is the ability to separate changesets after the fact.

    cheers,
    Dimitar

    Dimitar Dimitrov

    August 26, 2008 at 1:14 am


Comments are closed.

%d bloggers like this: