Date: Mon, 24 Feb 2020 05:00:51 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Jan Beich <jbeich@FreeBSD.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Mathieu Arnold <mat@FreeBSD.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, Cy Schubert <cy@FreeBSD.org> Subject: Re: svn commit: r526863 - head/shells/ksh93-devel Message-ID: <202002241300.01OD0ppq011000@slippy.cwsent.com> In-Reply-To: <8sks-cgu4-wny@FreeBSD.org> References: <202002222317.01MNHbLo027195@repo.freebsd.org> <20200223083358.kl6wgdcj2pekzess@atuin.in.mat.cc> <202002231502.01NF2lj5007283@slippy.cwsent.com> <20200223154559.v4hlnjn24f7fxr2g@atuin.in.mat.cc> <202002231702.01NH2YOD008243@slippy.cwsent.com> <20200223180058.73ml7qthhj5phvn6@atuin.in.mat.cc> <202002231830.01NIUL3q003289@slippy.cwsent.com> <8sks-cgu4-wny@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <8sks-cgu4-wny@FreeBSD.org>, Jan Beich writes: > Cy Schubert <Cy.Schubert@cschubert.com> writes: > > > In message <20200223180058.73ml7qthhj5phvn6@atuin.in.mat.cc>, Mathieu > > Arnold wr > > ites: > > > >> On Sun, Feb 23, 2020 at 09:02:34AM -0800, Cy Schubert wrote: > >> > In message <20200223154559.v4hlnjn24f7fxr2g@atuin.in.mat.cc>, Mathieu=20 > >> > Arnold wr > >> > ites: > >> > > > > > >> > > > > How can the commit date change and the hash remain the same? This > = > >> is a > >> > > > > very very unlikely collision. > >> > > >=3D20 > >> > > > That was purely my fault. I had built and tested the port and commit > t= > >> ed i=3D > >> > > t=3D20 > >> > > > to a branch of my git tree. Prior to merging it to master I changed > t= > >> he=3D > >> > > =3D20 > >> > > > commit date a more recent date to reflect the git svn dcommit I was= > >> =3D20 > >> > > > planning that day. Then did git rebase to redo the commit, git merge > = > >> to=3D > >> > > =3D20 > >> > > > merge back to master, and finally git svn dcommit. I missed a step i > n= > >> my=3D > >> > > =3D20 > >> > > > workfolow. > >> > > > >> > > I still do not understand, how does that influence the date the commit > >> > > referenced by the hash, 0be82553 here, was made? > >> >=20 > >> > OK, here's the timeline. > >> >=20 > >> > Feb 8: > >> >=20 > >> > 1. I branch master to ksh93 in my github repo. > >> > 2. The port is updated. COMMIT_DATE=3D2020-02-08 > >> > 3. make makesum > >> > 4. Port is built, builds correctly. > >> > 5. Port is committed to my ksh93 branch. (The other ksh93 is also=20 > >> > committed.) > >> >=20 > >> > Feb 22: > >> >=20 > >> > 6. git merge from ksh93 to master > >> > 7. I realize the COMMIT_DATE of 2020-02-08 is now incorrect. > >> > 8. I change the commit date to the current date and use git rebase to=20 > >> > re-commit the commit. > >> > 9. (I forgot to make maksum when I changed the commit date. My bad.) > >> > 10. git svn dcommit to push my commits to svn. > >> >=20 > >> > That's how it happened. Do you understand now? > >> > >> Mmmm, ok, but, the version of the port is supposed to be about upstream, > >> not some made up date you create. In this case, the version is supposed > >> to be the date of the *upstream* commit, not the date where you do > >> stuff. > > > > That makes sense. I started doing this when I realized github didn't report > > > commits accurately so I opted to use the date I did the work. > > GitHub does report CommitDate in addition to AuthorDate e.g., > > https://github.com/krb5/krb5/commits/master > > where "Commits on Feb 17, 2020" refers to CommitDate but if you open > the specific commit its AuthorDate is from "Nov 26, 2019". It reports the commit date but it's incorrect. Go to the page of the changed file and many times it will show a different date and time. I can be off by days sometimes. They may have improved the precision of their site though. My comparison of git pull/git log with the latest commit reported on the site indicates their reported commit dates are off by a few hours now, which is a huge improvement from before. <rant> The other problem with their site, github hashes that don't always work, still exists though. The hash reported by git pull, when it is longer, always works. The first seven bytes of the hash isn't always enough. The seven byte hashes reported on the site don't always work. But that's a minor issue. </rant> -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202002241300.01OD0ppq011000>