Re: [PATCH RFC 1/2] builtin/history: abort reword on unchanged message

Pablo Sabater <pabloosabaterr@gmail.com> writes:

And no argument, including that history is new, is a good excuse to make these three things inconsistent, period.

One of the patches in your updated iteration claims

    When using `git history reword <commit>` if the new message is the same
    as the original, it continues and rewrites the history when nothing
    changed.

    `git commit --amend` and `git rebase -i` with reword share this behavior
    and it is wrong as well, but changing them breaks what people are used
    to. Take the opportunity of `git history` being a new command and handle
    it correctly from the start.

and I think this is a totally wrong attitude to go about this.

I may have said that it may have been a better default to try hard to avoid making a change that is a no-op, other than that it changes committer timestamp, while making the current "always create a new commit object" behaviour optionally available, for these three commands, and cited that the behaviour of 'pick' in 'rebase -i' that avoids unnecessary rewrite as an example of a good practice.

But I do not think the existing behaviour to always rewrite is *wrong* at all. It may be wrong not to offer the other choice of pretending no content change means no commit object change, but that is a different story.

I also do not think *aborting* only when the message happens to be the same is a valid mode of operation at all.

The most sensible first step, I think, is to add a new command line option to "git history" (which will gain more history editing subcommands) that tells the command to leave the original history as-is when the only change rewriting commits would make would be to the committer ident or timestamp information. If in a future a new replace-tree subcommand is added, e.g. if

    $ git history replace-tree HEAD~20 HEAD~27^{tree}

were a command to rewrite the history in such a way that 20th direct ancestor of the current HEAD had a tree object HEAD~27^{tree}, by derfault the command _should_ rewrite HEAD~10 and everything that has it as an ancestor. With the "--avoid-unnecsssary-rewrite" optimization feature on, however, it may silently become a no-op when HEAD~27^{tree} happened to be the same tree as HEAD~20^{tree} so the only difference between rewritten and original HEAD~20 would be when that commit object was created and by whom.

And give the same option to "rebase -i" or "commit --amend". We can discuss, educate the users, and flip the default at a major version boundary, if the "avoid unnecessary rewrite" truly turns out to be a better default (right now it is merely our speculation, and we do not even know if the current behaviour is a worse default).