From: Pablo Sabater Date: Tue, 09 Jun 2026 15:51:51 GMT Subject: Re: [PATCH RFC 1/2] builtin/history: abort reword on unchanged message Message-ID: In-Reply-To: El mar, 9 jun 2026 a las 15:21, Junio C Hamano () escribió: > > Pablo Sabater writes: > > > 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 ` 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