Page MenuHomeFreeBSD

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

Authored by markj on Jul 31 2025, 4:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Oct 7, 11:56 PM
Unknown Object (File)
Sat, Sep 27, 5:29 AM
Unknown Object (File)
Sat, Sep 20, 4:17 AM
Unknown Object (File)
Sep 16 2025, 4:37 AM
Unknown Object (File)
Sep 7 2025, 4:39 AM
Unknown Object (File)
Sep 4 2025, 6:42 PM
Unknown Object (File)
Aug 28 2025, 5:11 PM
Unknown Object (File)
Aug 26 2025, 5:21 PM

Details

Reviewers
des
Group Reviewers
srcmgr
Summary

Requested by: des

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 65865
Build 62748: arc lint + arc unit

Event Timeline

markj requested review of this revision.Jul 31 2025, 4:52 PM

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

This revision is now accepted and ready to land.Jul 31 2025, 4:53 PM

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

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

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?

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.

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.

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.

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

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