Warner Losh wrote:
> See sys/conf/newvers.sh for the 'n' value we use in uname strings. It's a
> linear count of commits on the first-parent branch back to the start of the
> repo.
>
> Also, the dates usualy are first order correct and i use them for the stats
> i run. Though I've also just drop
On Thu, 4 Jan 2024 12:49:03 -0700
Warner Losh wrote:
> On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote:
>
> > Tomoaki AOKI wrote:
> >
> > >
> > > Or create database (key-value store would be sufficient) storing commit
> > > order (like r* of svn) and commit hash.
> > > I'm still not cer
On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote:
> Tomoaki AOKI wrote:
>
> >
> > Or create database (key-value store would be sufficient) storing commit
> > order (like r* of svn) and commit hash.
> > I'm still not certain whether commit order or commit hash should be the
> > "key". Possi
Tomoaki AOKI wrote:
>
> Or create database (key-value store would be sufficient) storing commit
> order (like r* of svn) and commit hash.
> I'm still not certain whether commit order or commit hash should be the
> "key". Possibly store hash as the key fisrt and store assigned MONOTONIC
> order as
commit based like
>
> git log ..HEAD
>
> -- Brooks
>
> From freebsd-current+bounces-5248-freebsd-lists=dyslexicfish@freebsd.org
> Wed Jan 3 23:26:23 2024
> Date: Wed, 3 Jan 2024 23:26:01 +
> From: Brooks Davis
> To: Jamie Landeg-Jones
> Cc: bro...@fr
On Wed, 3 Jan 2024 23:32:27 +
Brooks Davis wrote:
> On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote:
> > On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote:
> > >
> > > Nothing about dates is centralized in git, but some server side checks
> > > could be implemented on CommitDate.
On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote:
> On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote:
> >
> > Nothing about dates is centralized in git, but some server side checks
> > could be implemented on CommitDate. IMO we should require that
> > CommitDate be >= the previous one
Bakul Shah wrote in
<46c8698a-a004-4b5f-9107-6d9fd3685...@iitbombay.org>:
|On Jan 3, 2024, at 11:22 AM, Brooks Davis wrote:
|>
|> Nothing about dates is centralized in git, but some server side checks
|> could be implemented on CommitDate. IMO we should require that
|> CommitDate be >= the
On Wed, Jan 03, 2024 at 10:52:04PM +, Jamie Landeg-Jones wrote:
> Brooks Davis wrote:
>
> > Nothing about dates is centralized in git, but some server side checks
> > could be implemented on CommitDate. IMO we should require that
> > CommitDate be >= the previous one and less than "now".
>
On Jan 3, 2024, at 11:22 AM, Brooks Davis wrote:
>
> Nothing about dates is centralized in git, but some server side checks
> could be implemented on CommitDate. IMO we should require that
> CommitDate be >= the previous one and less than "now".
Given that git commit objects form a DAG, I don't
Brooks Davis wrote:
> Nothing about dates is centralized in git, but some server side checks
> could be implemented on CommitDate. IMO we should require that
> CommitDate be >= the previous one and less than "now".
Ah, I realised Linux doesn't like centralised dates, because of the
decentralisa
On Wed, Jan 03, 2024 at 07:13:35PM +, Jamie Landeg-Jones wrote:
> https://cgit.freebsd.org/ports/
>
> The latest update to "main" is :
>
> authorYuri Victorovich 2023-01-03 14:49:38 +
> committer Yuri Victorovich 2023-01-03 14:49:38 +
>
> I.e. A year old. Reading the commit m
https://cgit.freebsd.org/ports/
The latest update to "main" is :
authorYuri Victorovich 2023-01-03 14:49:38 +
committer Yuri Victorovich 2023-01-03 14:49:38 +
I.e. A year old. Reading the commit message, it does appear to be a wrong
clock, rather than an old message, but whilst t
13 matches
Mail list logo