CODEWITHSUNDEEP
gitgithub
E.Cross
E.Cross

Reputation: 2137

Git Push returns "Everything up-to-date"

I am attempting to push my updated files to a remote repository on github, operating OSX Snow Leopard using git version 1.8.4.2.

I have successfully done git init followed by git add . and git remote add origin https://github.com/me/repo.git. I then did a git commit -m "first commit" followed by git push origin master

All of this worked great

The problem is that I have a message returned to me when I try to commit and push again. I updated some files for example, did a commit with a message, and then ran git push remote origin.

The command works except it says "Everything up-to-date". I scanned a half dozen or so stack overflow questions with similar errors and a lot of them relating to not being on the correct branch or being in detached head mode. I believe my case is neither.

Here is the result of git log --graph --all --decorate --pretty=oneline:

* 6926001f0eed54c05f807eb04ed05fd0584cd2e6 (HEAD, origin/master, master) first commit

and here is git remote show origin

* remote origin
  Fetch URL: https://github.com/me/repo.git
  Push  URL: https://github.com/me/repo.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

and here is git branch -v

* master 6926001 first commit

I am not sure what other information I can provide, but please do let me know and I will update the question. I am fairly new to git, thanks for reading!

Edit:

I ran the second commit again and got this message:

# 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:   file1
#   modified:   file2
#   modified:   file3
#
no changes added to commit (use "git add" and/or "git commit -a")

Upvotes: 3

Views: 4714

Answers (1)

torek
torek

Reputation: 489838

You need to add files to the "staging area" before git commit will actually make a new commit.1

The "staging area" lets you arrange everything the way you want it, which is sometimes not the same setup you need in the work directory (e.g., you might need to tweak a config file to test part 1 of a new feature, but not want to commit that particular config-file change yet).

It's generally wise to run git status before git commit to see what's ready to commit and what's not yet staged. Also, git diff --cached shows what will be committed (compares the HEAD commit to the staging area), while git diff without --cached shows what won't be committed, i.e., what is not yet staged.

As a short-cut, you can use git commit -a, which automatically adds files that show up as modified or deleted in git status output. (But this does not add "untracked" files. Again, see the output of git status.)

For completeness, I'll add that git diff HEAD shows what you would commit if you ran git commit -a. (These three git diff variants are listed in the git diff documentation, under the EXAMPLES section.)

Here are a few web references about the staging area:

http://gitready.com/beginner/2009/01/18/the-staging-area.html

http://git-scm.com/book/en/Getting-Started-Git-Basics (this is the Pro Git book, which is very good but can be quite confusing too, mostly because git itself can be pretty confusing).

https://softwareengineering.stackexchange.com/questions/69178/what-is-the-benefit-of-gits-two-stage-commit-process-staging

1Technically not quite true: more precisely, just before committing, git commit does a quick comparison of what it is to commit, vs the current HEAD commit. If there is no difference, it stops unless you've specified --allow-empty. With -a, "what it is to commit" includes modified and deleted files; only if there are none will you still need --allow-empty to make a new commit.

Upvotes: 5

Related Questions