0

The section of the book:

http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Staging-Modified-Files

says that if I change file A, run 'git add A' and then change file A again, run 'git commit' on this file, only previously staged changes will be committed. To commit unstaged changes - add file again and then commit.

After some testing, however it turns out that git commits all changes of the file A, even those that were made after the file had been staged initially.

Can anyone shed some light on this matter? Thanks.

EDIT: I am not using -a option It looks like if I specify the file explicitly for "git commit A" (I am not using -a option), it commits unstaged changes as well. Committing without file "git commit" asks to enter a commit message and then behaves as described in the book.

alexy2k
  • 560
  • 1
  • 6
  • 10

2 Answers2

1

You're probably adding the -a option when you commit, which does another add on everything before the commit. It works as described when you omit the -a.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
1

How are you determining that it "commits all changes of the file A"? I can't reproduce this on my version of git. To reiterate what I think you're saying, if you follow this process:

$ git add A                 #initial commit of A
$ git commit -m first
$ <modify A>
$ git add A                 #stage first set of changes
$ <modify A again>
$ git commit -m second      #without staging second modifications

What you should see at this point is that the first set of changes, but not the second, was committed. git show HEAD:A should display the file as it was before you made the second modifications. However, the second modifications will still be in your working copy of the file (cat A), and git status should report that there are unstaged changes in A. That's exactly what I got when I tried to replicate this, and is what should be expected.

If that's not what you're seeing, then either you did something different than what was listed above, or somehow the version of git you're running is broken.

twalberg
  • 59,951
  • 11
  • 89
  • 84
  • That's correct. I see unstaged changes. However, if I edit A, stage it, edit again, then run 'git commit A -m <..>' it adds unstaged changes aswell. To sum it up, specifying file explicitly during commit submits all changes - both staged and not. Does this make sense? Thanks for helping. – alexy2k Aug 31 '12 at 19:56
  • The man page for `git commit` says this: "The content to be added can be specified in several ways: .... 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". So, yes, when you explicitly name files to commit, what you are seeing makes sense. – twalberg Aug 31 '12 at 20:08
  • Lesson learned again - read the docs first :) Thanks for pointing that out. Accepting your answer. – alexy2k Aug 31 '12 at 20:13