Daniel Stenberg wrote:
> >Or in what sense it is a distributed version control system? A link to a
> >RTFM or specs would be fine.
>
> It is distributed in every sense I'd say. We can have development going on
> independently in as many different repos as we like (and A B and C can
> decide to pull their changes amongst each other without caring about ME),
> but we of course need to have a somewhat controlled way to get changes
> into the 'master' branch which is the one we produce releases from. That's
> why I've suggested we start out mimicing our very simple CVS way of
> working: with N people pushing their changes into the same branch.

It's so distributed, that every developer has their own personal repo
in addition to public repos...

> To get into git, I can recommend the book at http://book.git-scm.com/ and
> the cheat sheet:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
>
> I have to confess it took me a long time to grasp it (and I'm convinced I
> still haven't figured out large portions of git), so I think getting the
> basics first is what matters and then figuring out the fancy details as
> you start to use the tool.

Sympathies! It took me a few months to get Git, having a quick go
every so often. I was always afraid of using the wrong command line
options having some effect I wouldn't know about, and I didn't trust
the many "How to switch from CVS/SVN" tutorials, because they really
aren't the right model. And I didn't find the tutorials all that
helpful either. Most of them presented the concepts in the wrong order.

In the end, these two resources took me to the "a-ha!" state:

    http://www.newartisans.com/2008/04/git-from-the-bottom-up.html
    - "Git from the bottom up" by John Wiegley
    - Explains blobs, trees, commits, and the commit graph.
      Then it all makes sense!

    http://oreilly.com/catalog/9780596520137
    - "Version Control With Git" by Jon Loeliger
    - Practical book. Reading the first few chapters was enough
      to get me started using it.

And then I had a project where I had to edit kernel source in anger,
which was a great way to get the hang of it.

Now I'm using it, it makes a lot of sense. I really don't know why it
seemed so difficult before!

The nicest _practical_ thing I've found about Git:

With CVS/SVN, you can't check in complete rubbish while you try
things, or debugging code, because it'll break it for everyone else,
so you tend to hold off checking things in until you're happy that
it's ok. It's good practice for the repo to contain a useable tree,
but that does prevent using the repo to track unstable work in progress.

With Git it's the other way: you tend to check in a lot because it's
quite helpful to track what you've been doing locally - and you can
easily revert things, reorder changes, try out different combinations,
have a set of changes for local debugging which you keep applying over
changing the publishable code, etc. and it doesn't break anyone else's
tree until you push changes upstream - which you can do selectively,
and after tidying up commit messages and checking the changes are tidy.

-- Jamie
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-03-23