Files in Git can be in one of these three states: Modified, Staged, Committed
Staged: The current version of the modified file is staged to be included in the next commit.
A bit of a nitpick, but if I change a file, "git add" it, and then change it again, both of these statements are false.
I use git add -p somewhat frequently to do partial staging of a file to split up my changes into multiple commits.
Wow, I have been using git for ages but I did not know about this. I was relying on magit (for Emacs) and git-cola.
You can also discard changes that way, e.g.:
I will have to read about how to use it, because it shows some hunks on a page, and I do not want to stage all of them, for example.
When it shows you a hunk that's bigger than you like, you can use 's' to split it into smaller hunks.
Thank you!
Cherrypick (-p) is wonderful. A command I also like is rebase interactive(-I)
Git rebase -i HEAD~[number of commits]
Yeah, I use `git rebase -i HEAD~n` a lot.
`git add -p` is such a nice utility. Sometimes I do wish that it could also be used for unstages files, so that if I'm introducing a new file, I could still break its contents up into multiple commits.
Of course, the workaround there is that one adds the initial file into the staging area and then `git add -p` the subsequent changes. It could just be a bit more convenient on that front, is all.
Alternately:
It can, you just gotta do a magic incantation first.
The first command signals to git that you intend to add the file. That makes its entire content show up in the patch editor.I think if the word "Files" was replaced with "A change [in a file]", then the statement holds true. Perhaps a better phrasing: