Hacker News Reader

Comment by Tobu | Hacker News Reader

The blog author doesn't understand Git that well:

    git add foo.rb
    // continue working in foo.rb
    git commit foo.rb

will commit the latest version of foo.rb.

That's because git commit handles its arguments by add-ing them to the index (staging area) before doing the actual committing.

I'm not so sure about the conceptual graph from the paper, either. The stash is a commit, it doesn't have anything to do with file states.

View on HN

No, the author is correct. The add command adds that version of the file to staging, so subsequent changes will need to be added as well if you want them in the commit.

No, you can read the following in the man page of git commit:

3. by listing files as arguments to the commit command, in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git);

Oh indeed, you're right. This didn't occur to me because I've never had a reason to use `git commit [path]`.

And I don't know if I'd call this error evidence of the author not understanding git, as much as I'd call it further evidence of the inconsistency they're highlighting.

> That's because git commit handles its arguments by add-ing them to the index (staging area) before doing the actual committing.

That's not what it actually does. It commits all the changes from the file (staged or otherwise), and nothing else. It leaves the index/staging area in the same state, except for the committed file.

That is:

  git add foo bar baz
  git commit foo

will commit any change to foo, and leave bar and baz alone (staged and non staged parts).

Reply on news.ycombinator.com