Re: Report on the pull request experiment so far

On Tue, Feb 28, 2023, 4:04 PM Brooks Davis <brooks@freebsd.org> wrote:

> On Tue, Feb 28, 2023 at 05:12:37PM -0500, Ed Maste wrote:
> > On Sat, 25 Feb 2023 at 18:54, Warner Losh <imp@bsdimp.com> wrote:
> > >
> > > I also landed one commit that was from 2021. Yikes. The commit date is
> right, but the author date is in the past. I suggest that we add a git
> commit --amend --date="`date`" to the process. This likely is a good thing.
> There's no simple --reset-date, alas: only a reset that also resets the
> author.
> >
> > IMO we should just accept git's notion of separate author and commit
> > dates, and not worry about author dates being in the past.
>
> I remain on the fence, but think we should either accept git's notion or
> enforce that the date is newer than prior commits and not in the future.
> IMO we should enforce this on commit dates regardless[0].  There is no
> conceivable value in allowing people to commit from systems with wildly
> wrong clocks given they must be on the internet to commit.
>

I too am on the fence. It isn't a huge deal...

I've also found git am --ignore-date copes well. It's a lot faster to fetch
the .patch file and feed it to git am than to fetch the deltas and
rebase... but the latter is more robust...

A bigger issue in my mind is the project's use of trailer metadata that
doesn't match what git expects. The whole spaces vs - thing is making
tooling harder than it needs to be...

Warner

-- Brooks
>
> [0] Obviously this only applies to first-parent commits not the commits
> being merged in a merge commit.
>