"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: [patch] preserve and show author dates
To:
"Sven M. Hallberg" <pesco@khjk.org>
Cc:
gameoftrees@openbsd.org
Date:
Thu, 1 Aug 2024 21:30:26 +0200

Download raw body.

Thread
On Thu, Aug 01, 2024 at 07:17:19PM +0200, Sven M. Hallberg wrote:
> Hi there,
> 
> I've noticed that got rebase, and histedit by extension, overwrite the
> author timestamp with the current (committer) time.
> 
> Since this was itching me, I scratched it. The patch below is my initial
> work to gauge if I'm on the right track here. It avoids clobbering the
> author timestamp in lib/worktree.c:commit_worktree() by threading it
> through as a separate argument.
> 
> In addition, it adds support for showing a (differing) author timestamp
> to got log and tog.
> 
> You can also see this split into some individual commits at:
> 
>  https://gotweb.khjk.org/?action=summary&headref=authortime&path=got.git
> 
> A word on my commit_worktree() changes: I opted to keep the creation of
> the committer timestamp where it was, right before the call to
> got_object_commit_create(). Then I detect whether a different author
> timestamp should be applied by the presence of the optional _committer_
> argument. This works fine, but seems unintuitive. The direct alternative
> would have been to change the interface of the function to make author
> the optional argument.

What is the use case enabled by preserving the author timestamp?

For example:
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. Committer timestamps can provide a good approximation of
an answer (and gotd doesn't yet sanity-check timestamps against the server's
system clock, but could conceivably do so and clamp such timestamps into
a reasonable range).
Author timestamps showing when someone first typed 'got commit' before
rebasing their branch several times don't seem interesting for this
particular problem, and are at best redundant information.

So is the preservation of author timestamps a purely cosmetic tweak?
Or is there some workflow step that does not work without this feature?

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?

I'm not trying to argue for or against this particular change yet,
just trying to understand why it is needed. I know that Git has this
behaviour, too. I never understood why.