Hacker News Reader

Comment by ryanpers | Hacker News Reader

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?

View on HN

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

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

Reply on news.ycombinator.com