Stefan Sperling on Thu, Aug 01 2024:
> What is the use case enabled by preserving the author timestamp?

It might simply be _interesting_ for any number of reasons when
something was actually written. I wouldn't call that purely cosmetic.

More concretely though, a downside of rebase (as opposed to merge) is
that it loses the information about the exact context in which a change
was made. The author timestamp retains at least a hint.

Consider a larger branch, rebased several times against a changing code
base. Sure, not ideal maybe, but not exactly uncommon either. One of the
rebases introduces a subtle bug that is not discovered for some time and
the cause is not immediately clear. Something in the underlying code
base changed and broke an assumption made by the code on the branch. It
was fine when first written, but no longer fine after one of the
rebases. Author timestamps provide a clue where to look for changes that
could have broken our code.

On a lesser note, I think it's important for rebase not to feel
"costly", i.e. like a trade-off to be weighed against its downsides. To
me, clobbering the timeline seems a bit too harsh.

> The question of when a particular commit entered an important repository
> will come up occasionally, e.g. when the reason for a regression needs to
> be understood.

Perfectly fair, I am not here to argue against the value of committer
timestamps...

> In cases where histedit or cherrypick fold multiple commits into
> a single commit, preserving info about potentially multiple authors
> of the original commits becomes impossible. What should happen then?

That is a good question. However, it applies equally to the author name.
I haven't checked what got or git do in that case.

-p