Date: Tue, 28 Feb 2023 18:48:37 -0700 From: Warner Losh <imp@bsdimp.com> To: Brooks Davis <brooks@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, freebsd-git <freebsd-git@freebsd.org> Subject: Re: Report on the pull request experiment so far Message-ID: <CANCZdfo29tq-vgHxVzTyorma-hQT5x45fq_G7yf2vqcUKeZX4Q@mail.gmail.com> In-Reply-To: <Y/6IkCD%2B5YawlCHX@spindle.one-eyed-alien.net> References: <CANCZdfoOm3iWZHvh6oy4Cj6qpcvnHjAWpbvNp7r9msfwO_r5fg@mail.gmail.com> <CAPyFy2D7MBsThAUYkVyh1Tg3UW8mAvBXL5wwmSKjpSsHFm5y1Q@mail.gmail.com> <Y/6IkCD%2B5YawlCHX@spindle.one-eyed-alien.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 28, 2023, 4:04 PM Brooks Davis <<a href="mailto:brooks@freebsd.org">brooks@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Feb 28, 2023 at 05:12:37PM -0500, Ed Maste wrote:<br> > On Sat, 25 Feb 2023 at 18:54, Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank" rel="noreferrer">imp@bsdimp.com</a>> wrote:<br> > ><br> > > 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.<br> > <br> > IMO we should just accept git's notion of separate author and commit<br> > dates, and not worry about author dates being in the past.<br> <br> I remain on the fence, but think we should either accept git's notion or<br> enforce that the date is newer than prior commits and not in the future.<br> IMO we should enforce this on commit dates regardless[0]. There is no<br> conceivable value in allowing people to commit from systems with wildly<br> wrong clocks given they must be on the internet to commit.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I too am on the fence. It isn't a huge deal... </div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto">Warner </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -- Brooks<br> <br> [0] Obviously this only applies to first-parent commits not the commits<br> being merged in a merge commit.<br> </blockquote></div></div></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo29tq-vgHxVzTyorma-hQT5x45fq_G7yf2vqcUKeZX4Q>