?

Log in

No account? Create an account
Who, me? [userpic]

Looking for the O'Reilly Git book

March 20th, 2010 (08:25 am)
Tags:

I need to start using Git at work. (I lost a few hours of work, and didn't have a personal branch, because svn branches just aren't easy enough.) I bought the ebook edition of the O'Reilly book Version Control with Git, but the download page is broken, and their customer service isn't available on weekends. Long shot: does anybody have a copy? (No DRM, so it's copyable; and I did pay for it, so it's legal.)

Update: ~2.5 hours later, the site was working again.

Comments

Posted by: metahacker (metahacker)
Posted at: March 20th, 2010 02:11 pm (UTC)
Not an answer per se
keys

How's your experience with Git been? I use it to version/backup my writing archive and my private developer tree, but also have 'professional' interest in it as we're developing extensions around a competing SCM at work. I trip over certain things constantly (I don't think of branching the way git does), but it's fast and easy otherwise.

I found http://gitready.com/ to be helpful, and http://www.kernel.org/pub/software/scm/git/docs/everyday.html was a good starter/refresher.

Just found this, too: http://progit.org/book/ -- looks interesting.

Posted by: Who, me? (metageek)
Posted at: March 20th, 2010 02:49 pm (UTC)
Re: Not an answer per se

I've barely used it at all, actually. I did a little bit with a project a while back, but the project fizzled—and, anyway, I just had clients pushing/pulling to/from Github, using it the same way I use Subversion.

Thanks for the links!

Posted by: Who, me? (metageek)
Posted at: March 20th, 2010 11:58 pm (UTC)
Re: Not an answer per se

Here's an interim conclusion, having read about 1/4 of the way through the book: Git's architecture is absolutely brilliant. Its UI is stupid. Not just "what were you smoking?" stupid, but "why didn't you get the ice pick taken out of your brain first?" stupid. Some examples:

  • The output of "git status" is human-readable, not parseable...but most of its lines are prefixed with "#".
  • Before you commit files, you have to stage them. Staging seems to have no value; it's exposing the bones of the architecture, reflecting the way they decided to make commits atomic. If you add a file, then change it, then commit, the version that you added goes into the repository.
  • The developers apparently realized that staging was ice-pick stupid, so they changed commit to make it easier, automatically staging all files. But they didn't make it the default; you have to write "git commit --all".

Remember that it was developed by Linus, for use in maintaining the kernel. Basically, imagine what would happen if kernel developers tried to define a UI. I'm no UI expert, but I could do a hell of a lot better than this.

(And I'm tempted to: create a wrapper called "fit", which uses the architecture, but presents a UI with the ice pick removed.)



Edited at 2010-03-20 11:59 pm (UTC)

Posted by: metahacker (metahacker)
Posted at: March 21st, 2010 12:14 am (UTC)
Re: Not an answer per se
keys

tig is slightly less bad.

gitx is also slightly less bad, but I am usually running git from console. I do find the syntax highlighting helps a LOT with output formatting...you've got ANSI color enabled, right? turn on color in your .gitconfig:

[color]
  ui = always
  diff = always
  status = always
  branch = always


And you have it exactly--it's what happens when a kernel dev (i.e., Linus) writes a UI that works for him.

Staging--I like staging. Now. Might be some Stockholm syndrome. There is this invisible local backing store that things get added to, and *that's* what gets committed. It does take getting used to, but all the SCMs I use nowadays do some variety of staging. It has some significant benefits in the end; you have a local version of what was truth when you started developing, in case the remote repositories have gone ahead while you were working. Without it, merges would get disastrous.

You do have to stop thinking of git as a front-end to a central repository that holds the definitive version of a file, which takes some brain-changing.

That being said, I have "gap" aliased to "git commit -a; git push" because that's what I almost always want to do at end-of-day.

Posted by: Who, me? (metageek)
Posted at: March 21st, 2010 12:31 am (UTC)
Re: Not an answer per se

turn on color in your .gitconfig:

Thanks, I'll give that a try.

It has some significant benefits in the end; you have a local version of what was truth when you started developing

But, with a DVCS, you have that anyway, don't you? You have your own repository; it's got all the history.

You do have to stop thinking of git as a front-end to a central repository that holds the definitive version of a file, which takes some brain-changing.

Yeah. And I've got it worse: I'm going to be using git-svn. Work is on SVN, and I want git for the ability to commit early and often. So there really will be a central, definitive repository, but git will want me to believe there isn't.

5 Read Comments