On Thu, 4 Jan 2024 12:49:03 -0700 Warner Losh <i...@bsdimp.com> wrote:
> On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones <ja...@catflap.org> wrote: > > > Tomoaki AOKI <junch...@dec.sakura.ne.jp> 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 value, then, add the just-stored order as key and hash as > > > value in another database would be neeed. If the database can contain 2 > > > value for 1 key, it would be suitable for you to store the assigned > > > time in UTC as "when it is committed to FreeBSD master repo". > > > > I do miss the incrementing "r" value - it's a nice immediate way to > > tell which update is more recent. Actually, to me, that is more important > > than the date - I've attempted to base my changes on the date due to the > > absense of such a useful field. > > > > 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 dropped tags on the first commit of each year > too... > > Also be advised that the pre FreeBSD 8 or so tree still has some surprising > artifacts in it. > > Warner What I suspect/fear is that current n* numbers are assured to same value for the same officially existing branch or not. What I want is such an assured number (order). What happenes if something lile below happened? *Accidentally commit something into local repo racking, for example, stable/14 instead of local (personal) developement branch. *Noticed before next `git pull` and revert it and commit it to correct local branch. *Pull upstream (official) updates. This case, checked-out tree would be match upstream (if no other changes are not yet done). If n* number is kept the same as upstream with situations like above, it could be VERY helpful if n* is exposed in mails automatically sent to dev-commits-* ML and somehow in cgit repo (like r* numbers for old, svn era commits). If not, what I've described in my previous post would be helpful if used for auto-post to ML and (hopefully) cgit, IMHO. Regards. > > Actually, I think I may implement such a thing on my local cgit repo. > > > > https://cgit.dyslexicfish.net/ports/latest/tree/ > > https://cgit.dyslexicfish.net/src/current/tree/ > > > > Cheers, Jamie -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
