Hacker News Reader

git is not just some other utility. The comparison to screen savers is not adequate. git is an advanced system tool meant for software engineers. That's why I compare it to a programming language or an operating system.

Also, the return on investment is huge.

I think that time spent learning git is time well spent.

I would argue that you aren't learning a computer utility, but rather learning how distributed version control works. I honestly can't find anything in the author's post that doesn't make sense for DVCS.

Oh come on.

Your language, your editor, and your source control. Three things worth knowing backwards and forwards if you're going to call yourself a developer. Three things easily worth spending a week grokking, if necessary.

And then there's the thousands of libraries, debuggers, versions, deployment choices, design strategies, etc etc. Development is an endless path of learning, and git is barely learnable.

And editors don't take a week to learn because you don't have to learn everything to use them. Even vi works quite well with just a few commands, and you will never NEED anything other than those, only optimize your usage.

"git is barely learnable" - hardly!

The fact that even experts admit they don't understand the array of options and implications for commands like reset and rebase would tend to support me here.

And there is always dispute about the best way to do something as simple as back out a commit or clean large old files from a repository (very difficult with a large team). The series of incantations to do such things is always ridiculously obtuse, with non-intuitive flags and symbols.

Sure the basics are learnable, and google can often reveal solutions (though rarely definitively), but I know no one with a comprehensive understanding of the majority of git fundamentals.

I wouldn't be calling someone an expert if they don't understand what a rebase is.

"git reset is probably the most confusing command written by humans. I've been using Git for years, even wrote a book on it and I still get confused by what it is going to do at times." -- http://gitref.org/basic/#reset

source code management is way beyond 'a computer utility', but since you brought it up, here are some other computer utilities:

- dd - bash - find

Most of those require quite a bit of time to master.

Now, moving past that, git isn't merely a computer utility, its a foundational element in programming. It's actually more primitive than a programming language itself! The thing that separates the high school students from the "professional" programmers is SCM, and mastery of it. Having seen hardcore dev done on 10m loc code bases in perforce, you need some perspective on how hard git is and isnt.

One of the biggest problems I find is that people attempt to understand git via the lens of SVN. Once you free yourself from the past and understand the basic fundamentals of git, and cast aside your svn-isms you will be zen.

I for one wouldn't hire a developer who isnt intimately familiar with at least one SCM system. Zip files named v1, v2, v3 anyone?

But you aren't going to sit down and spend a week learning all the ins and outs of dd, bash, find, or, say, grep. You are going to skim the docs, learn the minimum to do the task at hand, wash, rinse, and repeat.

My path at learning SVN was that way too. Heck I didn't even learn the merge command for a couple years until I really needed to, and then I realized how much I had been missing.

I think the big issue that some of us have with git is it can't do all the same things that svn can do. Of course a big problem with svn is it can't do all the things git can do. I wouldn't set nails with a ball peen hammer either.

If you want to use git, here's a 10 minute primer:

1. Create the git repository:

  git init

2. To commit any changes, you type in:

  git commit -a -m "thing that I changed"

3. To branch, you type in:

  git checkout -b newbranch

4. To switch back to a branch, you just type in:

  git commit -a -m "changes made on branch"
  git checkout <branch>

5. To merge in a branch to the current branch, you type in:

  git merge <branch>

6. To push to a remote repository, you first add a remote repository by typing in the following:

  git remote add origin git@example.com:my_project.git

(origin can be anything, but a good convention to use for the main repo that you are pushing to).

Now to push your changes, you just use:

  git push origin <branch>

Most often you will use:

  git push origin master

Except, that isn't enough.

What do I do if a merge fails? How do I abandon the merge (git certainly doesn't help you, it just keep complaning that there is an unresolved merge).

Why do I get 'git push' telling me there is nothing to push, but 'git pull' telling me I have branches with resolved merges (because git push pushes only one branch, and git pull pull everything).

Those are just two things I've seen beginners hit recently.

Following the rest of the discussion, at those points you do what you do with any other tool you use: pop into the manpages for two minutes and figure it out.

What do I do if a merge fails?

From the man page of git-merge:

  Before applying outside changes, you should get your own work in good shape and committed 
  locally, so it will not be clobbered if there are conflicts. See also git-stash(1). 
  git pull and git merge will stop without doing anything when local uncommitted changes overlap 
  with files that git pull/git merge may need to update.

How do I abandon the merge?

From the man page of git-merge:

  --abort

  Abort the current conflict resolution process, and try to reconstruct the pre-merge state.

  If there were uncommitted worktree changes present when the merge started, git merge --abort 
  will in some cases be unable to reconstruct these changes. It is therefore recommended 
  to always commit or stash your changes before running git merge.

  git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

As a mercurial user I look and that and go... gee that's complicated. All the 'origins' and named 'master' and email addresses and extra stuff.

for ref the equivs are:

1. hg init

2. hg commit -m "message"

3. hg branch newbranch

4. hg update branchname

5. hg merge branchname

6. hg push

How does hg know where to push to? (honest question)

You edit .hg/hgrc. You also must run:

  hg outgoing

What I'm interested in is how to switch to a different branch.

To switch to a branch you go

hg update branchname

If you have uncommited changes it will refuse. You can 'shelve' the changes or force the update to the branch (with a flag on the command line).

Interesting... must have a look at hg!

But I'm not really sure that pushing is that much of a difficult concept, because you just have to add a remote and then use this to do your push. Not really that much of a difference...

Edit: I've just realized... I probably need to clarify the command:

  git remote add origin git@example.com:my_project.git

The only git keywords here are "remote add". Origin could be named anything you want (call it "external"), and the git@example.com:my_project.git is actually what points to the git remote repository. You can also use the same style URI if you want to use SSH, or even HTTP(S).

It has a default setting. You can set the default in your .hg file. When you pull your repo from somewhere that becomes the default. You can also specify where you want to push to.

eg.

hg push ssh://hg@bitbucket.org/myusermame/project

or

hg push https://username:password@code.google.com/p/project/

I understand, your argument is why I used Dropbox's primitive version control over SVN. I never had to think about it.

But now I use git, and I don't even consider myself an engineer. I do front-end. Structurally speaking, git makes 10x more sense to me than SVN ever did.

> Taking a week to learn a computer utility seems insane to me

I teach git at work. It takes me a grand total of 10 minutes to explain git's core concept to any dev. It takes me the better part of one hour to teach them how to use git. It takes them the rest of a work day for them to train basically without any intervention on my part, only man pages and a bunch of questions. After that they're basically without training wheels and hardly reach to me, except for the trickiest cases. That's assuming no one is stepping on the brakes, then one who does not want to learn, won't learn.