3

I wrote an incorrect commit message, and I've pushed it to the remote. There are no small number of questions that already deal with this:

are just a couple. But they all seem to terminate with git push --force, and the additional warning about why this is a bad idea - it edits the history, which means that everyone else who uses the repository suffers when they try to pull. They don't seem to say what the "right" thing to do is.

So what's the recommended or "correct" way to deal with this situation? I thought I could add an extra message with git commit --allow-empty, but supposedly there is "rarely a good reason to do this". Is --allow-empty indeed the right way to fix things? If not, what is the right way?

Note: Doing things the "right way" can involve "admitting I screwed up". As an example of what I'm looking for, the git tag man page has a discussion on retagging pushed tags. It clearly discusses methods to re-tag incorrectly tagged commits, giving both a recommended course of action and a --force-ish way of doing things.

Community
  • 1
  • 1
Praveen
  • 6,872
  • 3
  • 43
  • 62
  • 1
    This will depend on your project contribution guidelines, which may be implicit. Sometimes it's acceptable to force push a new commit, other times it won't be. – ChrisGPT was on strike Jun 20 '15 at 19:04
  • @Chris This isn't an official project - it's a personal project hosted on github, but one that I know many of my friends also pull from. So there are no guidelines other than the ones I set myself. Regardless, I feel there ought to be a recommended course of action seeing as this is probably a mistake that's made pretty often (going by the number of votes on those other answers). – Praveen Jun 20 '15 at 20:20
  • Git is pretty consistent in *not imposing a workflow* on you. You're free to work without any remotes, or with 100. You're free to sign tags and commits, or not. You're free to rebase shared commits, or forbid it. It's up to project maintainers to choose how they wish to use the tool. Similarly, it's up to you, as the project maintainer, to choose whether you want to force push simply to fix a commit message. Personally I'd avoid this, but only you can decide if it's the right move for you in this situation. – ChrisGPT was on strike Jun 20 '15 at 21:51
  • @Chris So if I understand you correctly, you're saying that if it were up to you, you'd rather just leave the incorrect commit message as is, without modification and without a note of any kind - since, I guess, at the end of the day, it's just another tiny commit that will be lost in a deluge of others. I think that's a fair argument. But please correct me if I misinterpreted. – Praveen Jun 20 '15 at 23:07
  • You got it. For me, it largely boils down to impact. Will the commit message do more harm than a forced push? Is it really misleading? Then maybe fix it. Is it just a typo? Then leave it there. I suspect that it falls somewhere in between, and you're in a much better position to judge it than I am. – ChrisGPT was on strike Jun 20 '15 at 23:47

1 Answers1

6

One thing you can do is to add a note to the commit, e.g. git notes add -m "Here is my note" head~1. This will then show up in the git log without actually changing the commit. Another alternative is to add an annotated tagto the commit, e.g. git tag -a tag-summary -m "Here are the tag details" head~1. I prefer the tag approach, as tags show up in the log view of most tools, whereas notes do not (though they do show up in git log).

David Deutsch
  • 17,443
  • 4
  • 47
  • 54
  • 1
    I like the idea of adding a note. But if what you say is true, in that many tools won't show the note, I'm not convinced it's the best way. I'll accept it if I don't get any better answers. I'm not so fond of the idea of adding a tag, because I think tags serve a fundamentally different purpose, i.e., versioning. Writing a correction for a commit message on a tag fixes the problem, but I find it pretty unappealing. – Praveen Jun 20 '15 at 20:39
  • It looks like notes _is_ actually the way to go. From the [git-scm blog](https://git-scm.com/blog/2010/08/25/notes.html) on this, it would seem that notes are meant to hold additional commit info, without changing the commit SHA. You're right that not all tools show notes yet - for instance, github doesn't. `gitk` does, however, and since `gitk` is what I use to graphically view my history, I'm pretty satisfied with this solution. Hopefully more tools will support notes in future, and the git interface for pushing and pulling notes will improve. Thank you very much! – Praveen Jun 22 '15 at 06:13