CODEWITHSUNDEEP
gitversion-control
devoured elysium
devoured elysium

Reputation: 105097

What is the rationale behind git's decision of not commiting a new added file current contents but instead the contents of when it was added?

So, from what I've read in Pro Git,

It turns out that Git stages a file exactly as it is when you run the add command. If you commit now, the version of someFile as it was when you last ran the add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run commit. If you modify a file after you run add, you have to run add again to stage the latest version of the file

it seems that when you add a file to your git repository, either you commit right away, or your if you make any modifications to that same file before the commit, those modifications won't be saved in that commit.

What is the rationale behind that?

Upvotes: 3

Views: 162

Answers (3)

Tyler
Tyler

Reputation: 22116

It's actually very consistent with the way git add works for non-new files.

$ git checkout master # assume there is some file called code.c
# hack hack hack
$ git add code.c
# hack hack hack
$ git commit

This adds the file as it looked at the time you did the git add. In, say, svn, you wouldn't even do the add because svn add is only for new files. So it's one extra step (unless you use git commit -a as someone else said) but it gives you a lot more flexibility, to commit only some changes and leave others uncommitted, within the same file. Once you get comfortable with git, you may fall in love with the git add -p command for exactly this reason. :)

Upvotes: 0

Karl Bielefeldt
Karl Bielefeldt

Reputation: 49078

Almost always, it makes sense to commit immediately after an add, which is why commit has an -a option, and why practically every other VCS doesn't let you split the add and commit, even though they are separate stages internally.

There are some circumstances where it is very handy to do separately. Some people use the staging area as a sort of temporary commit if they're not sure they want to keep the changes or not, and are still experimenting. I prefer all my commits to be compilable, so I will sometimes do an add when I am ready to commit but have a bunch of compile errors. That lets me do a diff on what I have changed while fixing compile errors in case I mess anything up. It's also very handy if you want to split your changes into multiple commits for whatever reason.

Upvotes: 2

Kromey
Kromey

Reputation: 1212

git doesn't track files, it tracks changes. So when you "add a file", you're not adding the file, you're adding the changes to that file, which in the case of a new file is all its content at the point that you added it. So, if you make changes after "adding the file" but before you commit, you have to add those new changes as well or they won't get committed.

Upvotes: 4

Related Questions