From nobody Fri Jan 5 06:26:17 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T5tlF55Sfz56FVP for ; Fri, 5 Jan 2024 06:26:33 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T5tlF0tchz4mkf; Fri, 5 Jan 2024 06:26:32 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-22-158.area1b.commufa.jp [123.1.22.158]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4056QITV049734; Fri, 5 Jan 2024 15:26:18 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 5 Jan 2024 15:26:17 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Jamie Landeg-Jones , Brooks Davis , Yuri , FreeBSD Current , Bakul Shah Subject: Re: git repo port issues? Message-Id: <20240105152617.688ee28bfd7c1cfc383f74e3@dec.sakura.ne.jp> In-Reply-To: References: <202401031913.403JDZBt028036@donotpassgo.dyslexicfish.net> <46C8698A-A004-4B5F-9107-6D9FD3685074@iitbombay.org> <20240104183539.cef54811b98fe53c5841edca@dec.sakura.ne.jp> <202401041914.404JEJCm083648@donotpassgo.dyslexicfish.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4T5tlF0tchz4mkf X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] 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 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