Why does 'git commit' not save my changes?

Question

I did a git commit -m "message" like this:

> git commit -m "save arezzo files"
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   arezzo.txt
#       modified:   arezzo.jsp
#
no changes added to commit (use "git add" and/or "git commit -a")

But afterwards, when I do git status it shows the same modified files:

> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   arezzo.txt
#       modified:   arezzo.jsp
#
no changes added to commit (use "git add" and/or "git commit -a")

What am I doing wrong?

Answer 1

As the message says:

no changes added to commit (use "git add" and/or "git commit -a")

Git has a "staging area" where files need to be added before being committed, you can read an explanation of it here.

For your specific example, you can use:

git commit -am "save arezzo files"

(note the extra a in the flags, can also be written as git commit -a -m "message" - both do the same thing)

Alternatively, if you want to be more selective about what you add to the commit, you use the git add command to add the appropriate files to the staging area, and git status to preview what is about to be added (remembering to pay attention to the wording used).

You can also find general documentation and tutorials for how to use git on the git documentation page which will give more detail about the concept of staging/adding files.

One other thing worth knowing about is interactive staging - this allows you to add parts of a file to the staging area, so if you've made three distinct code changes (for related but different functionality), you can use interactive mode to split the changes and add/commit each part in turn. Having smaller specific commits like this can be helpful.

Answer 2

You didn't add the changes. Either specifically add them via

git add filename1 filename2

or add all changes (from root path of the project)

git add .

or use the shorthand -a while commiting:

git commit -a -m "message".

Answer 3

You should do:

git commit . -m "save arezzo files"

Answer 4

I copied a small sub project I had that was under Git source control into another project and forgot to delete the .git folder. When I went to commit I got the same message as above and couldn't clear it until I deleted the .git folder.

It is a bit silly, but it is worth checking you don't have a .git folder under the folder that doesn't commit.

Answer 5

You could have done a:

git add -u -n

To check which files you modified and are going to be added (dry run: -n option), and then

git add -u

To add just modified files

Answer 6

The reason why this is happening is because you have a folder that is already being tracked by Git inside another folder that is also tracked by Git. For example, I had a project and I added a subfolder to it. Both of them were being tracked by Git before I put one inside the other. In order to stop tracking the one inside, find it and remove the Git file with:

rm -rf .git

In my case I had a WordPress application and the folder I added inside was a theme. So I had to go to the theme root, and remove the Git file, so that the whole project would now be tracked by the parent, the WordPress application.

Answer 7

I find this problem appearing when I've done a git add . in a subdirectory below where my .gitignore file lives (the home directory of my repository, so to speak). Try changing directories to your uppermost directory and running git add . followed by git commit -m "my commit message".

Answer 8

Maybe an obvious thing, but...

If you have problem with the index, use git-gui. You get a very good view how the index (staging area) actually works.

Another source of information that helped me understand the index was Scott Chacons "Getting Git" page 259 and forward.

I started off using the command line because most documentation only showed that...

I think git-gui and gitk actually make me work faster, and I got rid of bad habits like "git pull" for example... Now I always fetch first... See what the new changes really are before I merge.

Answer 9

if you have more files in my case i have 7000 image files when i try to add them from project's route folder it hasn't added them but when i go to the image folder everything is ok. Go through the target folder and command like abows

git add .
git commit -am "image uploading"
git push origin master

git push origin master Enumerating objects: 6574, done. Counting objects: 100% (6574/6574), done. Delta compression using up to 4 threads Compressing objects: 100% (6347/6347), done. Writing objects: 28% (1850/6569), 142.17 MiB | 414.00 KiB/s

Answer 10

I had an issue where I was doing commit --amend even after issuing a git add . and it still wasn't working. Turns out I made some .vimrc customizations and my editor wasn't working correctly. Fixing these errors so that vim returns the correct code resolved the issue.

Answer 11

I had a very similar issue with the same error message. "Changes not staged for commit", yet when I do a diff it shows differences. I finally figured out that a while back I had changed a directories case. ex. "PostgeSQL" to "postgresql". As I remember now sometimes git will leave a file or two behind in the old case directory. Then you will commit a new version to the new case.

Thus git doesn't know which one to rely on. So to resolve it, I had to go onto the github's website. Then you're able to view both cases. And you must delete all the files in the incorrect cased directory. Be sure that you have the correct version saved off or in the correct cased directory.

Once you have deleted all the files in the old case directory, that whole directory will disappear. Then do a commit.

At this point you should be able to do a Pull on your local computer and not see the conflicts any more. Thus being able to commit again. :)

Answer 12

if you have a subfolder, which was cloned from other git-Repository, first you have to remove the $.git$ file from the child-Repository: rm -rf .git after that you can change to parent folder and use git add -A.

Answer 13

delete each .git file in all projects

you can use this command

rm -rf .git

Answer 14

Warning, If you are Using Git 2.40 or 2.41 (Q1/Q2 2023), even a git commit -am can still generate:

no changes added to commit (use "git add" and/or "git commit -a")

This is reported in git-for-windows/git issue 4462

The crucial part to make it fail was to ensure that no tracked file is left after staging the deletions

mkdir test_repo
cd test_repo
git init
echo test > file1.txt
echo test > file2.txt
git add --all
git commit -m "first commit"
del file1.txt
del file2.txt
git commit -m "remove files" -a

This is fixed with Git 2.42 (Q3 2023).

A few places failed to differentiate the case where the index is truly empty (nothing added) and we haven't yet read from the on-disk index file, which have been corrected with Git 2.42 (Q3 2023).

See commit 2ee045e, commit 7667f4f, commit 866b43e (29 Jun 2023) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 7f5ad0c, 08 Jul 2023)}

commit -a -m: allow the top-level tree to become empty again

^{Signed-off-by: Johannes Schindelin}

In 03267e8 ("commit: discard partial cache before (re-)reading it", 2022-11-08, Git v2.40.0-rc0 -- merge listed in batch #1), a memory leak was plugged by discarding any partial index before re-reading it.

The problem with this memory leak fix is that it was based on an incomplete understanding of the logic introduced in 7168624 ("Do not generate full commit log message if it is not going to be used", 2007-11-28, Git v1.5.4-rc0 -- merge).

That logic was introduced to add a shortcut when committing without editing the commit message interactively.
A part of that logic was to ensure that the index was read into memory:

if (!active_nr && read_cache() < 0)
  die(...)

Translation to English: If the index has not yet been read, read it, and if that fails, error out.

That logic was incorrect, though: It used !active_nr as an indicator that the index was not yet read.
Usually this is not a problem because in the vast majority of instances, the index contains at least one entry.

And it was natural to do it this way because at the time that condition was introduced, the index_state structure had no explicit flag to indicate that it was initialized: This flag was only introduced in 913e0e9 (unpack_trees(): protect the handcrafted in-core index from read_cache(), 2008-08-23, Git v1.6.1-rc1 -- merge) (unpack_trees(): protect the handcrafted in-core index from read_cache(), 2008-08-23), but that commit did not adjust the code path where no index file was found and a new, pristine index was initialized.

Now, when the index does not contain any entry (which is quite common in Git's test suite because it starts quite a many repositories from scratch), subsequent calls to do_read_index() will mistake the index not to be initialized, and read it again unnecessarily.

This is a problem because after initializing the empty index e.g. the cache_tree in that index could have been initialized before a subsequent call to do_read_index() wants to ensure an initialized index.
And if that subsequent call mistakes the index not to have been initialized, it would lead to leaked memory.

The correct fix for that memory leak is to adjust the condition so that it does not mistake active_nr == 0 to mean that the index has not yet been read.

Using the initialized flag instead, we avoid that mistake, and as a bonus we can fix a bug at the same time that was introduced by the memory leak fix: When deleting all tracked files and then asking git commit -a -m ...^(man) to commit the result, Git would internally update the index, then discard and re-read the index undoing the update, and fail to commit anything.