On Thu, Sep 02 2021, Leo Famulari wrote: > On Thu, Sep 02, 2021 at 12:51:58PM -0400, Leo Famulari wrote: >> On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote: >> > > Commit dates don't have a consistent meaning: are they the time of >> > > first revision of a commit? Final revision of a commit? Time of >> > > signing? Pushing? They are often useful to estimate a timeline, but >> > > it's common for a Git "timeline" to jump back and forth by months or a >> > > year due to long-running development branches being merged in, or due >> > > to a "commit and then polish by rebasing" workflow. >> > >> > I would say the the time of the final commit would be the best option, >> > but I agree that it can be ambiguous. > > Reading your message again, I think you misunderstood what I wrote. > > I wasn't asking what date we should choose to include in our package > versions. I was asking, "What does the Git commit timestamp describe?" > And the answer is that there is not a clear answer, and it depends on > the workflow of the person who made the Git commit. My point being that > a Git repo does not offer us meaningful information about when anything > happened. The date does give an idea of how old the version is, compare that to a random string of 7 characters. If a user wants to know the exact commit, they can always just run ‘guix edit PACKAGE’ and check the ‘commit’ field in the source of the package. From a Guix developer’s perspective, one can get an idea of roughly how old a package is when looking at the package definition. E.g., a few months ago, when Magit hadn’t a release for around 2 years or so, I wanted to see how old our current ‘emacs-magit’ package was. To do that I had to ‘guix edit emacs-magit’, then find the commit-id and copy it, then go to my local checkout of Magit and run ‘git log COMMIT-ID’, just to see how old the version was. If the date of the commit was encoded in the version string, I would immediately see that its 6 months old or something; no need to manually look up the commit-id.