13

I read this about how to amend commit messages. The accepted answer says:

If you've already pushed your commit up to your remote branch, then you'll need to force push the commit with git push <remote> <branch> --force.

It's my understanding (also from the accepted answer) that git push --force will overwrite all data on the remote branch with the local one.

Why is force-pushing after changing a commit message necessary? What happens if I amend a commit message and try to push without -f or --force?

Improve this question
5
  • 2
    don't push force, unless you know what you do with git.
    – Stargateur
    Commented Dec 6, 2016 at 19:15
  • 2
    @Stargateur Yeah, I haven't tried it yet for that reason.
    – MD XF
    Commented Dec 6, 2016 at 19:16
  • 3
    '--force' should not be used anymore. Prefer '--force-with-lease'. A shame that it's longer to write...
    – Philippe
    Commented Dec 6, 2016 at 19:52
  • @Philippe explain, please?
    – MD XF
    Commented Jan 9, 2017 at 15:21
  • 1
    '--force-with-lease' verify that you fetched all the existing commits before deleting/hiding/loosing them. That way, you could be sure to not 'delete' inadvertently the commits of another dev. It happened to me one time before I new this option. That way you could be sure to not do a mistake!
    – Philippe
    Commented Jan 9, 2017 at 21:08

2 Answers 2

Reset to default
15

By amending commits, you are changing their SHA1, which means the local and remote history are no longer the same.

If you want to replace the remote history by your (amended) local one, you will need to force push.
If you don't, Git will refuse the push, and ask you to pull (which in this case is not helpful, as you would merge with identical content but different commit messages)

Force pushing can be dangerous as it forces other collaborators to reset their own local history to the new (forced pushed) one.

As commented, --force-with-lease is safer (if the remote branch you are changing was itself changed since your last pull, meaning other were actively using it and pushing it back, then the forced push is denied).
Combine that with a sensible pull policy (where you always rebase what you have not yet pushed), and force pushing becomes less needed.

Improve this answer
6
  • 4
    Seems like bad design to me. Modifying commit messages should be something that can be done safely, regardless of one's opinion on the practice.
    – ccarton
    Commented Dec 6, 2016 at 19:23
  • 5
    @ccarton it is at the very core of Git design, which is about data integrity (that I mention here: stackoverflow.com/a/27440678/6309) It achieves that through consistency check: stackoverflow.com/a/28792805/6309. Not a bit can change without the SHA1 of the all repo being changed.
    – VonC
    Commented Dec 6, 2016 at 19:26
  • 2
    Yes, that's my point. The fact that you can't modify a commit message safely without threatening the 'integrity of the data' just seems like short-sighted design to me. I accept that git as it is today probably can't be changed to support this but that's beside the point.
    – ccarton
    Commented Dec 6, 2016 at 19:47
  • 2
    @ccarton it's a good design that bring a lot of advantages even if sometimes there is inconvenients. If you really need, perhaps you should use 'git notes'.
    – Philippe
    Commented Dec 6, 2016 at 19:54
  • 3
    @ccarton Note that you can modify the commits in your local repo until you push them to a remote repo, which should be a decision point itself, not just an automatic action.
    – Gwyn Evans
    Commented Dec 6, 2016 at 23:09
0

It's my understanding (also from the accepted answer) that git push --force will overwrite all data on the remote branch with the local one.

By amending commits, you have already overwritten your git history ( by changing commit's SHA1). Amend is fine as long as you haven't published your changes, but once you do, you really shouldn't be mucking around with the history, because if someone already got your changes, then when they try to pull again, it might fail. Instead of amending a commit, you should just make a new commit with the changes.

What happens if I amend a commit message and try to push without -f or --force?

Git will refuse to update the remote branch with your branch (having amend public commit) because your branch's head commit is not a direct descendent of the current head commit of the branch that you are pushing to.

If this were not the case, then two people pushing to the same repository at about the same time would not know that there was a new commit coming in at the same time and whoever pushed last would lose the work of the previous pusher without either of them realizing this.

Why is force-pushing after changing a commit message necessary?

As i have mentioned above, git will not allow to push to a remote branch. You can read this question. It has many possible workaround to this problem.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.