1

I did a push of my latest changes

git push origin master

then I amended the commit message with an interactive rebase, i.e.

git rebase -i HEAD~5

and changed the message in the last commit.

This saved successfully, but when I did a git push origin master it just says Everything up-to-date.

Now the git history doesn't show the wording change as actually have been made?

However when I do a git commit --amend -m"msg" and then try and push the change is 'seen'.

Michael Durrant
  • 93,410
  • 97
  • 333
  • 497

3 Answers3

2

During the interactive rebase I had changed the commit message... but I hadn't changed the first column ('action') from pick to reword (or just r for short).

Doing this made the change get applied correctly.

Michael Durrant
  • 93,410
  • 97
  • 333
  • 497
  • As the description in the interactive-rebase to-do list (the file that is opened in your editor when you start the rebase) says, the messages in that file are only for illustrative/navigation purposes. All actual changes happen after you have saved the file. – Nevik Rehnel Mar 01 '14 at 16:17
0

then show Everything up-to-date when I do a push?

A possible explanation, illustrated with Git 2.18 (Q2 2018): during a "rebase -i" session, the code could give older timestamp to commits created by later "pick" than an earlier "reword", which has been corrected.

See commit 12f7bab (18 Apr 2018) by Johannes Sixt (j6t).
(Merged by Junio C Hamano -- gitster -- in commit 0657e0f, 08 May 2018)

sequencer: reset the committer date before commits

Now that the sequencer commits without forking when the commit message isn't edited all the commits that are picked have the same committer date.
If a commit is reworded, it's committer date will be a later time as it is created by running an separate instance of 'git commit'.

If the reworded commit is follow by further picks, those later commits will have an earlier committer date than the reworded one. This is caused by git caching the default date used when GIT_COMMITTER_DATE is not set.
Reset the cached date before a commit is generated in-process.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
-1

Because commit hash of the last commit doesn't change. You have to change commit hash of the last commit, so the server will know you have made changes.

You can use reword or edit command when doing interactive rebase. Or just use commit --amend.

Illegal Walker
  • 23
  • 6
  • The reasoning is logical here, but there's something missing. Running `git commit --amend` does indeed change the hash of the most recent commit, but `git push` still shows `Everything up-to-date`. – conorsch Sep 20 '15 at 17:38