Hacker News Reader

Comment by cschmidt | Hacker News Reader

I sometimes use git this way on local files:

    git init                       # make a local repo
    git add foo.txt                # add the file
    [edit]
    git add -u                     # add changes to commit
    git commit -m"made a change"   # check in changes
    git log                        # see commits
    git status                     # what has changed

That's really all you need to know.

View on HN

What you need to know is that "git add" has little to do with "foo add" where "foo" is just about any other version control system. Look, you ran "git add" on files that were already added, what?

There is this hidden thing called the index that confuses the heck out of everyone. Oh, but it's not always called the index, either: that would be unnecessarily easy. Sometimes it is called "the cache". How to show the difference between the index and HEAD? Why, of course not "git diff --index" but "git diff --cached".

(In what way the index acts as a cache is beyond me; a cache is a fast place where you look for something that is also available in some slower place, but things in the index are sometimes only in the index and nowhere else!)

Furthermore, things in the index are not "indexed" or "cached". Why, they are "staged". So why don't they call it the stage? (And only that: no synonyms?)

(The index behaves like a cache in the following sense: it has transparent "read through". If you do a "git diff", you see the difference between the index and your working copy for any changed file. But if the index doesn't have that file, then it gets out of the way and you see the diff between HEAD and the working copy. This confuses people because the transparent behavior teaches them, most of the tiem, that "git diff" is like "svn diff" when it isn't.)

The overloaded meanings of "git reset" are astonishing also. Sometimes it means "make the working tree like what is in HEAD". Sometimes it means "no, don't touch the working tree, but change HEAD to a particular revision". Sometimes it means "don't touch HEAD or the working tree: make the index look like a particular revision".

Want interactivity? Sometimes it's --interactive, and sometimes it's --patch. Please, just let me do "git stash --interactive"; don't make me correct that to "--patch".

You do have some very valid points, and git can be confusing. I wonder if those points are more confusing for someone coming to git from some other VCS than someone using git as their first VCS. My 13 year old son got the idea of Git after seeing a diagram like this:

http://git-scm.com/book/en/v2/book/01-introduction/images/ar...

So it is confusing, but I think it can be taught for very basic use.

Notably mercurial sidesteps this mess but not exposing the staging area in its UI.

I just read this comment, and I want to quote you in full in my blog or something. I want the world to see what you wrote here.

> git add -u

This is a wasteful step; you can commit all your changes with "git commit -a" which adds the modified files to the index, and commits, in one step.

The index is a completely pointless idea in git that has no purpose; the next major version of git should factor it out. Git would really improve if it lost the index thing.

You're already using distributed version control where you can have a whole swath of commits which are not published to your upstream. That is all the staging area you need; you don't need a staging area before your staging area. There are just too many levels: working copy to index. Index to commit. Commit to upstream repo.

Git tries to hide the index from users, but that backfires when awareness of its semantics crops up in corner cases. For instance, quite stupidly, if you try to revert a file from a prior commit with "git reset <sha> <file>", it does it in the index rather than where you expect, namely the working copy (that being left untouched). This is a purposeless complication. Now you have a "git diff" which looks like the change is being added rather than subtracted (because that's actually the delta from the index to the unmodified working copy), and a "git diff --cached" which is exactly its opposite (because it's a delta from HEAD to the index).

There has to be a concept of modified state which extends to "this new file is scheduled for addition" or "this file is scheduled for deletion". That's all the "index" you need. Other than that, there should only be the working tree, and whatever is in HEAD.

Git has the tools that let you make multiple commits and squash them together into one, so the index is completely redundant from that point of view. Instead of

  hack file
  git add file
  hack file
  git add file # squash into previous index entry

you can easily do

  hack file
  git commit file  # pretend the index doesn't even exist
  hack file
  git commit file

and then do an interactive rebase where you squash those commits together.

This is actually cleaner because you're not doing "squash as you go" into the staging area, but making actual commits where the changes are tracked and separated. Maybe you will end up not wanting to squash them into a single change!

I.e. since commits can be amended, cherry picked and squashed to your heart's content, there is no need for the software to support workflow involving a staging area where you prepare the perfect commit. It is superfluous.

The index smells like a left over from some early prototyped version of the software, before the full concept was hammered out, which was then difficult to remove (or it never occurred to anyone).

Ugh, this is terrible, the index is git's best feature. I kind of see where you're coming from with the idea of squashing together commits before pushing but it seems like a lot of awkwardness and overhead for the really basic use case of committing a bunch of files without doing it all in one command. Maybe it's just my OCD tendencies but I actually do spend time crafting the perfect commit, picking only the hunks/lines that matter and all that.

I think if people are taught git focusing on the index/staging area, it makes a lot more sense and you have much fewer problems.

You can pick out the hunks and lines that matter using "git commit --patch". This does the "git add --patch" and "git commit" in one step, so you never see any index.

Face it, the git index is an exaust manifold bolted on to a bicycle. This can be proven. Any argument you make for how the git index is useful is easily knocked down with a counterargument which shows how it it is redundant, because existing mechanisms uniformly handle that case.

Moreover, the index can be shown to complicate git. For instance when viewing differences with "git diff" you have: index to working ("git diff"), HEAD to index ("git diff --cached") or HEAD to working ("git diff HEAD"). This cruft all goes away if there is no index: you can just have "git diff" for the usual case of "show me what's different between the branch and working copy", like in virtually every other revision control system on the planet.

> I think if people are taught git focusing on the index/staging area, it makes a lot more sense and you have much fewer problems.

Absolutely no disagreement there. The index is there (complaining won't make it go away), and you have to know about it, otherwise you will not understand what is going on in some situations. People learning git must learn about the index upfront and know things such as "git diff" diffing against the index, or that the successful parts of a merge are in the index whereas the conflicts are unstaged and things of that sort.

You beat me to it. RCS can't scale up like Git, but Git scales down very nicely. Instead of learning two VCSes, you can reuse the same one you probably already use for everything else.

Sure, Git isn't the last word in VCS. There's lots of room for innovation in the space. Still, I don't see anything in the docs (at http://www.catb.org/~esr/src/src.html) that Git can't do just as well. It seems to be a solution in need of a problem.

That's what I do on my "bin" directories (for scripts and such).

On the other hand, maybe being able to grab something analogous to a ",v" file and moving the archive for a single file around by itself has some value. Just not enough value for me to bother installing RCS when git is already present :-)

So what benefit do you get from that? i.e. have you ever gotten yourself in a mess and thought, 'thankfully I used git here, otherwise I'd be fecked.'

Sure, I sometimes try things that don't work, and I can just revert my changes. I'm just used to having everything in source control, so I even like it for one-off stuff that doesn't fit in an existing repo.

Reply on news.ycombinator.com