On Fri, Aug 02, 2024 at 01:25:49AM +0200, Sven M. Hallberg wrote:
> 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...

Fair enough. I see that the author timestamp is simply not supposed
to change in Git when individual commits are merged somewhere else.

And Got only calls got_object_commit_get_author_time() when creating commits,
so preserving this timestamp would serve to keep collaborators happy who
are using Git. Got users shouldn't see anything changing.

No objections to your patch from me (not committing it myself; due to a
wrist injury I have a bit of energy to handle email, but not much else).

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

It seems Git users resort to adding information about multiple authors
to commit messages. Seems this problem was overlooked during Git's design
phase.

I wish there was a better way, but for compatiblity reasons I want to
refrain from adding custom extensions to the format to fix such issues.