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>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000cd6b2f05f5cce992 Content-Type: text/plain; charset="UTF-8" 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. > --000000000000cd6b2f05f5cce992 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Tue, Feb 28, 2023, 4:04 PM Brooks Davis <<a href= =3D"mailto:brooks@freebsd.org">brooks@freebsd.org</a>> wrote:<br></div><= blockquote class=3D"gmail_quote" style=3D"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=3D"mailto:imp@bs= dimp.com" target=3D"_blank" rel=3D"noreferrer">imp@bsdimp.com</a>> wrote= :<br> > ><br> > > I also landed one commit that was from 2021. Yikes. The commit da= te is right, but the author date is in the past. I suggest that we add a gi= t commit --amend --date=3D"`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 comm= it<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 o= r<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].=C2=A0 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=3D"auto"><br></div><div dir=3D"auto">I too am on the f= ence. It isn't a huge deal...=C2=A0</div><div dir=3D"auto"><br></div><d= iv dir=3D"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 fetc= h the deltas and rebase... but the latter is more robust...</div><div dir= =3D"auto"><br></div><div dir=3D"auto">A bigger issue in my mind is the proj= ect'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=3D"auto"><br></div><div dir=3D"auto">Warner=C2=A0</div><div = dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"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> --000000000000cd6b2f05f5cce992--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo29tq-vgHxVzTyorma-hQT5x45fq_G7yf2vqcUKeZX4Q>