El mar, 9 jun 2026 a las 15:21, Junio C Hamano ([off-list ref]) escribió:

Pablo Sabater [off-list ref] writes:

quoted

True, after reading it, history being more costly or the in memory are
not good args.

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).

Hi Junio,

Sorry about how I expressed myself. I didn't mean by wrong to be bad
or anything similar, I just noticed this when testing `git history
reword` and thought that I would like it this other way.

Saying that git history is new or I would like this to be different
are not good arguments to have `git history` inconsistent with other
commands.

My idea was more of a defensive thing, where you would need a
"--force-rewrite" opt to explicitly change timestamps. But I see the
point of having it in an `--avoid-unnecessary-rewrite` so without
options it has the same behavior as other commands.

I'll try to express myself better in the next version and go with the
opt direction.

Sorry again,
Pablo