Re: [PATCH 0/2] commit: preserve commit hash on a no-op amend

[Junio C Hamano <gitster@pobox.com>]

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> git commit --amend --no-edit rewrote the commit and moved the branch tip
> even when nothing changed, because the committer date was reset to "now".
> Reuse the existing committer date so a no-op amend keeps the commit hash and
> leaves the branch untouched.
>
> A real change (tree, message, author, committer, or signing) still rewrites
> as before.

I think this change brings nothing but regression.

Isn't it obvious that "commit --amend --no-edit" without updating
any tree contents would record exactly the same contents as before,
without a "real change" (as you said above), to any and all users,
expert and casual alike?

The end-user who runs such a command must have a reason to do so.
The *ONLY* valid reason anybody might want to such an amend is to
make sure the result is a new object, even if it records otherwise
the same content.

Why would they want to do so?  Perhaps it is so that future merges
of the topic branch that contains the commit will work more smoothly
into an integration branch that had earlier merged the topic branch,
and then that earlier merge was reverted.  This change will rob an
effective way to ensure a successful final merge in a workflow to
(1) merge a topic, (2) revert the topic, (3) update near the tip of
the topic while keeping earlier topic intact, and then (4) merge the
result again.

So, no.  I do not think this is a good change.

Let's digress and imagine an alternate universe where rebase/commit
--amend/history were "smart" from day one.  These command in such a
hypothetical world may not be capable of refreshing an existing
commit without making any "real change".

Making a change to these commands to _optionally_ allow them to
recreate an otherwise unchanged commit, so that it will get a new
object name, would be a welcome change that would allow users who
would use "commit --amend --no-edit" with today's system for such a
use case.  

And that would have been a logical evolution of the system in such a
hypothetical world.

But the thing is, we do not live in such a world.

If we still think that alternate hypothetical world is a better
place, we'd need to actively move things around, carefully designing
the transition to avoid harming existing users along the way, to get
there.  Changing the behaviour all of a sudden and breaking existing
workflows is not something we do around here.

One way to get to such a world might be:

 * Introduce an "committer timestamp is a trashable information"
   option, and teach commands like "commit --amend", "rebase", and
   "history" to cheat and yield the existing commit without
   refreshing when they are asked to recreate an existing commit
   while the option is in effect.  Give people the opposite
   "committer timestamp is not trashable information" option, so an
   earlier "is trashable" option on the command line can be
   countermanded by giving it later on the command line.

 * Have users discuss if "is trashable" is a better default, and
   gain consensus to make it the default in a future version of Git.
   Advertise the fact that we achieved consensus LOUDLY, while
   telling dissidents that "is not trashable" option will forever be
   available for them.

 * At a big version boundary, switch the default.

And I do not think I in principle would object to the first step of
such a three step process.

Thanks.