3 ms·

The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as:

The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as: This regression was caused in <hash> on December 19, 2017. The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit. I have scripted this before!

inigyou 3mo ago
Don't change old commits. Change commits you haven't pushed yet.
- kazinator 3mo ago
  That's not for you to dictate to someone about some project you have no idea about. Git is not a religion or cult. Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.
  - inigyou 3mo ago
    If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"
    - kazinator 3mo ago
      "Never rewrite public history", while it is a directive that talks about how to use a product or not used it, is just your personal preference, and nothing correct or incorrect. Just like "never type a profane word into Vim" is ostensibly a statement about how to use Vim, but of no technical value related to Vim use. It is nothing similar to advice such as using a screwdriver to drive screws and a hammer for nails. Some people regard the git repository as the object they are working on and want to create the perfect history in it, yet also to ship regularly. That requires shipped history be revised. It's entirely possible to work productively with an upstream that revises history, producing non-fast-forward changes. There are things you have to do and know that are not required in FF-only workflows, but nothing too terrible.
kazinator 3mo ago
By the way, the proper job of doing this recognizes abbreviated hashes also and fixes them up to equally abbreviated hashes.

inigyou 3mo ago

Don't change old commits. Change commits you haven't pushed yet.

kazinator 3mo ago
That's not for you to dictate to someone about some project you have no idea about. Git is not a religion or cult. Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.
- inigyou 3mo ago
  If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"
  - kazinator 3mo ago
    "Never rewrite public history", while it is a directive that talks about how to use a product or not used it, is just your personal preference, and nothing correct or incorrect. Just like "never type a profane word into Vim" is ostensibly a statement about how to use Vim, but of no technical value related to Vim use. It is nothing similar to advice such as using a screwdriver to drive screws and a hammer for nails. Some people regard the git repository as the object they are working on and want to create the perfect history in it, yet also to ship regularly. That requires shipped history be revised. It's entirely possible to work productively with an upstream that revises history, producing non-fast-forward changes. There are things you have to do and know that are not required in FF-only workflows, but nothing too terrible.

kazinator 3mo ago

By the way, the proper job of doing this recognizes abbreviated hashes also and fixes them up to equally abbreviated hashes.