Hacker News Reader

Comment by eesmith | Hacker News Reader

I don't think this is all that helpful.

> Git gives you a FULLY FEATURED repository on your local computer ... This is different than other version control systems

I use Mercurial and am confused by git. This statement of course doesn't seem right to me, since Mercurial is "FULLY FEATURED" too.

> Commit tree (local repo or HEAD)

Is "HEAD" or "local repo" an alias for either each other or for "commit tree"?

Because I think HEAD is a special location of the commit tree in the local repository - these are three different things, yes?

> Think of files (and changes) as being in 5 different places, or "states"

So, what's a "stash"? Not explained. Why do I need to know about stash?

> git reset and git checkout to pull from upstream

Someone confused because of experience from one of those "other version control systems" which are not so fully featured might not know what "pull" means. Or "upstream".

View on HN

Thanks for the comment; hopefully I can clear a few things up:

- Mercurial is similar to git in that way, but "fully featured" is supposed to contrast to other systems like SVN; the point is that there is a full git repo on every developer's machine - you're not just connected to a single central repo. So when you commit locally, you're actually committing into a repo that has all the power that the remote repo has

- Correct, HEAD is a special place on the tree, but I included it because you'll see and hear all three terms used nearly interchangeably.

- I could have explained stash a little better probably, but the "crash" course was already getting fairly long ;) Stash is a place to put work in progress, and some developers use it more than others. It's a bit of a "special" place (even though it's technically part of the local repo)

- I agree with the last point: mostly, this guide is for devs who already use git and know what 'pull' and 'upstream' mean, but are perhaps confused about the exact mechanics of how to "get files down" other than just cloning repos and checking out branches.

Hoped that helped clear a few things up a bit! Thanks for the feedback

Git confuses me - a lot. Like, what's the point of staging? You write:

> Why have a dedicated staging area?

> So that you can choose and review which files and changes to commit before committing.

Mercurial doesn't have a dedicated staging area, and I don't think I'm missing anything important by not having it, so this explanation doesn't seem to add anything.

But, looking now I see there are a number of resources along the lines of "git for Mercurial users", so perhaps think of me as not your target audience.

Yeah, I'm not familiar enough with Mercurial to really say how they are similar or different, so I'm not much help there. Sorry!

I can still try to answer the staging question though:

So - once you create a commit, it's in the repo forever, so with staging, you can gradually build up a commit without doing it all at once (adding one file at a time, over time for example). You can also stage just part of a file (just a few changes), and create only the commit that you really want to go into the repo.

I suppose it's kind of like a "commit preview" that you build over time.

In practice, a lot of people do just add all their changes and then commit immediately though - so yeah, in that case a staging area doesn't make any difference :)

Reply on news.ycombinator.com