3 ms·
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
by Tobu 10y ago
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.
- aninhumer 10y agoNo, 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.
- deleted 10y ago[deleted]
- nickez 10y agoNo, 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);
- aninhumer 10y agoOh 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.
- glandium 10y ago> 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).