2

I made a commit some times ago and I see some spelling error in the text for commit. As Far as I know this test is for users to understand what commit is about and has no effect on source files so if I change it, it should not make any problem with other developers.

Am I right that changing the text has no effect on other developers?

How can I change the text?

I am using git and for UI I am using Sourcetree.

love
  • 1,000
  • 2
  • 16
  • 35
mans
  • 17,104
  • 45
  • 172
  • 321
  • Changing anything in any changeset would change its ID which will lead to changed DAG. So the answer to the "changing the text has no effect on other developers?" --- it does have a huge impact on anyone who has already pulled and started using your commits. – zerkms Sep 10 '14 at 10:02
  • There's no convenient way to do it in git. If it's very important to you to be able to conveniently rewrite history and share that with others, check out Mercurial's Changeset Evolution feature. – Yawar Sep 10 '14 at 12:29
  • Possible duplicate of [Edit an incorrect commit message in Git](http://stackoverflow.com/questions/179123/edit-an-incorrect-commit-message-in-git) – jub0bs Jan 28 '16 at 17:08

3 Answers3

2

While you can use an interactive rebase for changing a commit in the past, such an act will always change the history of the repository.

So when working with a team you should ensure that you only change commits which weren't already pushed in the remote; for commits which were already pushed you should avoid operations that rewrite the commit history, since it can seriously mess up the repositories of your coworkers.

The command in question is git rebase --interactive, and if you want to learn more about it and how to use it effectively, you can take a look at the Rewriting History chapter of the gitpro book, which should answer your question.

Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
2

[...] so if I change it, it should not make any problem with other developers. Am I right that changing the text has no effect on other developers?

It all depends whether you've shared the problematic commit or not with your collaborators.

If you have, changing the commit message (even for correcting a tiny typo) will (to a very, very high probability) change the commit ID (SHA1) of that commit, and in turn, the commit IDs of its descendants (if any). That's a form of history rewriting.

Rewriting history that is (or has been, at some stage) public is problematic, because your collaborators' work is likely to rely on your old history (i.e. the history of your repo before the typo fix).

If you've made the commit in question public (for instance, by pushing some local branch that contains it to a remote repo also used by your collaborators) and you decide to rewrite history anyway, you're likely to piss people off. Your collaborators may retaliate by doing any or all of the following:

  • stare you down in corridors,
  • make you trip and fall down the stairs,
  • spit in your favorite coffee mug.

The list is not exhaustive, but you get the idea. So, if the problematic commit is already public, think twice before correcting that typo in its message.

How can I change the text?

If you're set on changing the message of the problematic commit, what you should do depends on whether the problematic commit is a parent of other commits in your history:

  • if it is, as advised by Zeeker in his answer, you have to resort to

    git rebase -i
    
  • if the commit in question is not a parent of any commit, you can simply use

    git commit --amend
    
jub0bs
  • 60,866
  • 25
  • 183
  • 186
0

If you want to edit the text of a past commit without affecting the workflow for others, I suggest you create a replacement commit:

git replace --edit ‹commit›

This will open an editor where you can edit the commit message as well as details about the author, comitter or timestamps. The resulting commit will be used as a replacement for the original commit in most operations, without modifying the history at a fundamental level.

According to How to push 'refs/replace' without pushing any other refs in git?, getting these replacements to other developers may require an explicit

git push origin 'refs/replace/*'

on your side, and a matching

git fetch origin 'refs/replace/*:refs/replace/*'

for all collaborating developers. Those who don't do the latter will still see the old wording.

Community
  • 1
  • 1
MvG
  • 57,380
  • 22
  • 148
  • 276