git-arc: Make "git arc stage" preserve the author date

[markj]

Summary

Requested by: des

[markj]

We could make this behaviour configurable, but I don't really see a need for that...

[glebius]

I actually liked that git arc stage resets the date. Now I would need to do git rebase --ignore-date before staging & pushing.

[imp]

I thought this was intentional and liked it. Otherwise a lot of my commits show up as many years old, whicj os a lie

[markj]

In D51655#1180023, @imp wrote:

I thought this was intentional and liked it. Otherwise a lot of my commits show up as many years old, whicj os a lie

It wasn't really intentional, I just don't pay much attention to author dates. Commit dates are more useful but even they can be misleading. git cherry-pick preserves the author date, so it makes sense to me for git arc stage to behave the same, just as it preserves the commit author.

Even without this change, the timestamps are misleading. I might stage some commits and let time pass (e.g., to run regression tests) before pushing. So, I'm not sure what we're losing.

Maybe @des can elaborate on why it's useful to preserve the author date?

[imp]

Especially since we've talked about having a tight limit on both author date and commit date so checkout by date is more useful and git log shows linear time.

[jhb]

Yes, I considered this a feature, not a bug. GDB for example requires (though doesn't enforce) that people do git rebase --ignore-date to reset dates before pushing to their master so that the dates in git log are commit dates. One can debate a bit the UI of git log, but it is what it is. On stable branches I think it's probably a feature that the author date on stable/X is the original commit to main. But for main I'm more of a fan of the author date being roughly == commit date.

[des]

I don't see any reason to police the author date, and I see value in documenting how long ago the work was done (or at least started) before it was committed. We definitely should police the commit date, though.

[imp]

I agree with jhb.

Let's turn the question around: what value is there knowing when I started on a change when that data is inconsistently preserved. If I split a huge commit, I get today's date on all but one of them...

[emaste]

The main flaw is probably just that Git by default wants to use the author date as the primary timestamp in git log etc. It intentionally captures the author and commit dates as separate things, so why throw one away and force them to be the same thing? I agree with @des - there is value in being able to see the age of a commit's creation relative to its commit date.

My recollection about hooks to enforce dates involve only commit dates, essentially:

1. commit dates must be monotonically increasing
2. commit dates must be before the current time on the repo server