From owner-freebsd-git@freebsd.org Mon Feb 1 22:11:14 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 040474E903D for ; Mon, 1 Feb 2021 22:11:14 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV2G96kDkz3KBN; Mon, 1 Feb 2021 22:11:13 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from weatherwax.trouble.is (weatherwax.trouble.is [IPv6:2a00:1098:82:3a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weatherwax.trouble.is", Issuer "R3" (verified OK)) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C31652261F; Mon, 1 Feb 2021 22:11:13 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.trouble.is (rincewind.trouble.is [IPv6:2a01:4f9:2a:1715::1:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "rincewind.trouble.is", Issuer "R3" (verified OK)) by weatherwax.trouble.is (Postfix) with ESMTPS id 4DV2G90mvSz24B5; Mon, 1 Feb 2021 22:11:13 +0000 (UTC) Received: by rincewind.trouble.is (Postfix, authenticated sender philip) id 4DV2G71KGSz6KjD; Mon, 1 Feb 2021 22:11:10 +0000 (UTC) From: "Philip Paeps" To: "Alan Somers" Cc: freebsd-git , "Gordon Tetlow" , "Colin Percival" Subject: Re: git transition plan for base/user/cperciva/freebsd-update-build Date: Tue, 02 Feb 2021 06:11:07 +0800 X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.14r5757) Message-ID: <6E20F78F-6BA8-451A-A828-ACA80B6B2E6C@freebsd.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 22:11:14 -0000 On 2021-01-30 04:12:04 (+0800), Alan Somers wrote: > What is the plan to transition the > https://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/ > code? > It's not really a branch of src; it's more like an independent > project. > Will it be getting its own repository? This came up in a security team call a while back. I believe our thinking was that it should be a separate repository. I don't believe any work has been done so far to make that happen though. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From owner-freebsd-git@freebsd.org Wed Feb 3 12:55:07 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9AFA536644 for ; Wed, 3 Feb 2021 12:55:07 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DW1qb4SFjz4Ydq for ; Wed, 3 Feb 2021 12:55:07 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 98E7A536643; Wed, 3 Feb 2021 12:55:07 +0000 (UTC) Delivered-To: git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 98AF7536642 for ; Wed, 3 Feb 2021 12:55:07 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DW1qb1Lbqz4YDx for ; Wed, 3 Feb 2021 12:55:06 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 113CsusE073078 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 3 Feb 2021 13:54:57 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Wed, 3 Feb 2021 13:54:56 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: git@freebsd.org Subject: HEADS UP: hashes changing for the freebsd-ports repo on Sunday Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/2.0.3 (2020-12-04) X-Rspamd-Queue-Id: 4DW1qb1Lbqz4YDx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:39540, ipnet:2a05:fc87::/32, country:CH] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 12:55:07 -0000 Hi folks, It's another one of those instances where the hashes will change (starting with all commits from Jan 5th 2021 forward). Our latest ports committers were not added to the authormap file in time _and_ this stopped being a fatal issue in the converter a while ago :/ Please bear with us a while longer. Thanks Uli PS: This also affects the src and doc repos, but they will obviuously not be changed again, see the errata notes at https://github.com/freebsd/git_conv/tree/next From owner-freebsd-git@freebsd.org Wed Feb 3 19:45:51 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9E48E5298B0 for ; Wed, 3 Feb 2021 19:45:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DWBxV6yPkz3PNL; Wed, 3 Feb 2021 19:45:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f50.google.com with SMTP id q3so172546oog.4; Wed, 03 Feb 2021 11:45:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gnm46wb2a+ffxPhOuLJhOk7cGy+cOVucwUF+IOdeFX8=; b=PoIjbNy13yTw3+Ifdq5lfAUAYYZYaO/dClS/7sKoYUwb0kcvo+I4nBqsGsxo8aBRQK CagS7nkV7maCJm7caY78KfI52FY3p3+xvvFJQwZ1cvN7xxm7Hm4XOD7+EB4vEGxA0P75 Z72xmGWPTueojkYaungubQnVAAbQnw2VPAwLYG7hWmrSrnhpWf/vJ+XejJ4Fo24YdCz8 WI+gcJqUZXhzVu0vFWOx7bKN/cUc6gpByzCFEnjEl/k3ycyFr0hNtJtW6JyN+nYyPJd7 XL4qUw8n0ypHyMLo74tkQDPG+cabPu/b/S8Ve4D3tSVjCJsyoqul5VlVMEWB57ql9y64 srrQ== X-Gm-Message-State: AOAM531DPEBusuNb5yNpD2zNOEpPF/UcgXWZSUyBm/8cvMbm0yoIFz/U ALZ/eWR3aVNIfkullqQfuI544O33s3ck7acOuWgMixN97lA= X-Google-Smtp-Source: ABdhPJwl8ft+InjpMluhYQsJs/0VZ9q6FvikPvSypi9UcPKJUOnt2rvxD921RseH6xX/efHA88S9TzBUqZ11WRIUcAE= X-Received: by 2002:a4a:ce90:: with SMTP id f16mr3166451oos.61.1612381549576; Wed, 03 Feb 2021 11:45:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Wed, 3 Feb 2021 12:45:38 -0700 Message-ID: Subject: Re: Git status update To: Ryan Libby , freebsd-git X-Rspamd-Queue-Id: 4DWBxV6yPkz3PNL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.161.50 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.161.50:from]; SPAMHAUS_ZRD(0.00)[209.85.161.50:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.161.50:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.161.50:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-git]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 19:45:51 -0000 On Wed, Jan 20, 2021 at 2:56 PM Ryan Libby wrote: > On Wed, Jan 13, 2021 at 9:14 PM Alan Somers wrote: > > > > On Wed, Jan 13, 2021 at 9:32 PM Li-Wen Hsu wrote: > > > > > On Thu, Jan 14, 2021 at 12:07 PM Alan Somers > wrote: > > > > Is anybody working on https://ci.freebsd.org/ ? Its stable > builders are > > > > working, but the head builders are still stuck on subversion. > > > > > > I'm working on it, and thanks for the help from bdragon@, it has made > > > some good progress but I still need to integrate them to the > > > production server. > > > > > > Best, > > > Li-Wen > > > > > > > Good news. I look forward to seeing it. > > -Alan > > _______________________________________________ > > freebsd-git@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-git > > To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org" > > Is there anything the rest of us can do to help? We're at one month > now without CI. > > Ryan > Ping. We're getting close to 13.0-RELEASE, and it's a real handicap to have no working CI. What can we do to fix it? -Alan From owner-freebsd-git@freebsd.org Wed Feb 3 21:31:50 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9333852CDD5 for ; Wed, 3 Feb 2021 21:31:50 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DWFHp300Xz3rFm; Wed, 3 Feb 2021 21:31:50 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bdragon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 58C5E932; Wed, 3 Feb 2021 21:31:50 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 13A9D27C0064; Wed, 3 Feb 2021 16:31:50 -0500 (EST) Received: from imap38 ([10.202.2.88]) by compute3.internal (MEProxy); Wed, 03 Feb 2021 16:31:50 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgedvgddugeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdluddtmdenucfjughrpefofgggkfgjfhffhffvufgtsehttdertder redtnecuhfhrohhmpedfuehrrghnughonhcuuegvrhhgrhgvnhdfuceosggurhgrghhonh eshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnhepteetleffuddvtddtuedv hfefheejvddvgfdvkedvfeethfegkedvkeelveeuvddunecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsggurhgrghhonhdomhgvshhmthhprghu thhhphgvrhhsohhnrghlihhthidquddtgedvfeehkeeigedqudekuddtkeehuddqsggurh grghhonheppefhrhgvvgeuufffrdhorhhgsehimhgrphdrtggt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E48DCA005D; Wed, 3 Feb 2021 16:31:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 03 Feb 2021 15:31:28 -0600 From: "Brandon Bergren" To: "Alan Somers" , "Ryan Libby" , "John Mehr via freebsd-git" Subject: Re: Git status update Content-Type: text/plain X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 21:31:50 -0000 On Wed, Feb 3, 2021, at 1:45 PM, Alan Somers wrote: > > Ping. We're getting close to 13.0-RELEASE, and it's a real handicap to > have no working CI. What can we do to fix it? > -Alan Last I heard about it, lwhsu@ was going to get a dev copy of jenkins up to allow testing the massive jjb changes that the git transition entails. I have a local cluster that I've been testing the jobs with on and off for a while. -- Brandon Bergren bdragon@FreeBSD.org From owner-freebsd-git@freebsd.org Wed Feb 3 21:34:29 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A3ED652D026 for ; Wed, 3 Feb 2021 21:34:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DWFLs4DCcz3rn7; Wed, 3 Feb 2021 21:34:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7F524A90; Wed, 3 Feb 2021 21:34:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id z32so868987qtd.8; Wed, 03 Feb 2021 13:34:29 -0800 (PST) X-Gm-Message-State: AOAM533jmVRUgM5Vpi6ibw4353TajgZQTKqX8O+sITdpC/Vv6Mu8NYZF Cm8Zc6WI+Mi1oaBoT/njAt/t+bnvMoqCT9XseKU= X-Google-Smtp-Source: ABdhPJwEpoDAo22lkdgymfQbSJzNL0pfcJTbbpBzbNvBpQ43F5AoxbCGNPXqtUuzc+L+O4TLANHq+R+0S61dRvbRLuQ= X-Received: by 2002:ac8:59c1:: with SMTP id f1mr4390769qtf.310.1612388068905; Wed, 03 Feb 2021 13:34:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Wed, 3 Feb 2021 15:34:14 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Git status update To: Brandon Bergren Cc: Alan Somers , Ryan Libby , John Mehr via freebsd-git Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 21:34:29 -0000 On Wed, Feb 3, 2021 at 3:31 PM Brandon Bergren wrote: > > On Wed, Feb 3, 2021, at 1:45 PM, Alan Somers wrote: > > > > Ping. We're getting close to 13.0-RELEASE, and it's a real handicap to > > have no working CI. What can we do to fix it? > > -Alan > > Last I heard about it, lwhsu@ was going to get a dev copy of jenkins up to allow testing the massive jjb changes that the git transition entails. > At this point, testing in production seems like a better position to be in than the current situation. :-) Thanks, Kyle Evans From owner-freebsd-git@freebsd.org Fri Feb 5 00:47:47 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BB510536829 for ; Fri, 5 Feb 2021 00:47:47 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (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 4DWxbQ680Kz3kRl for ; Fri, 5 Feb 2021 00:47:46 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id D07F611470 for ; Fri, 5 Feb 2021 09:47:36 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1612486056; bh=hFALd1JJUsagXcMPswjN2KPBTz5iTAE8cEpVbMeOO4k=; h=Date:To:Subject:From; b=tQQUl2O96Bvpw7yNJlP4ZWH+y3o5yc/6P93ECx+mfTmSOtXy1Db7hxG58huGnfgbl cigOdyPcaXuc1uPiLtvJNXNLyFx1qe37xcfcEDrmRoVQpSVL2qrjubsBSajRwyOwYY UYuSTohy+EfZP7+nziNDiFt4zg/PfYNC3bDFwoB203HvEJUJkTFuj5DWIEr8Fjo54v zaB0NXPGfzWEh1kcSi8QjqfaHerEhwvhSVlgV98mYirjnAzEOY2FpT7xuoe/Ns4w+S dsnRJMg9LrUdjEPAb9icy1y8gVAk0xO9/Q2Gc62RCk9RcwWYkDw3zWKIwd0/rqeS7U HDB6cMtz/7HQQ== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id F02341CB5F; Fri, 5 Feb 2021 09:47:35 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Fri, 05 Feb 2021 09:46:44 +0900 (JST) Message-Id: <20210205.094644.1159184285479762732.yasu@utahime.org> To: freebsd-git@freebsd.org Subject: Referencing git commit in the comment of Bugzilla From: Yasuhiro Kimura X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DWxbQ680Kz3kRl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=tQQUl2O9; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[utahime.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-git] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 00:47:47 -0000 Hell All, Doc and src have already migrated to git and ports will follow soon. In this situation it's quite possbile that bug reporter wants to reference git commit in the comment of bug report submitted to Bugzilla. Then is there standard(?) way to do it? As for subversion syntax such as "base r123456" or "ports r778899" is provided. And I expect similar one is provided for git. Best Regards. --- Yasuhiro Kimura From owner-freebsd-git@freebsd.org Fri Feb 5 00:51:43 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC12B5368ED for ; Fri, 5 Feb 2021 00:51:43 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (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 4DWxgz0h7rz3kc0 for ; Fri, 5 Feb 2021 00:51:42 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id E3930110F7 for ; Fri, 5 Feb 2021 09:51:40 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1612486300; bh=qBmHsCYAuE3/m/hvlOZBA4IAlhs1Y+7duelz1LU0qvk=; h=Date:To:Subject:From:In-Reply-To:References; b=FGwT7UPUlz9CnU7tvD+n9UyUX1yze8dAzCr67+3EkoiCJFDOrDdM7YEPXRrlDS60d KWWg7jvILkVtkcKOS0AQ6dIxwrMAVmqL2QNEl4LKiJWNTmWGQTd18SWYFOh6YYa321 3tnHBZLlJJI7wcd5G4QLyiTPLS16u5Dhp27nN05X+dV5ERtHALRQmFEewNHm7P1ntw isOHycH1ugJS8l7I3LL+ESnrwh8fZ34pHaUepicODoo3CReWcN8cqECc8jMZD1jsqn IxyMYWwLGxuV9GjwTEbs2JmIJQt9hl8pqcPZLZpV06qUpWC2NAJzo9ZjQeQoOumi8c fvM+ZC9H0xasg== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id EE7C61CBC7; Fri, 5 Feb 2021 09:51:39 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Fri, 05 Feb 2021 09:51:23 +0900 (JST) Message-Id: <20210205.095123.454565370342772860.yasu@utahime.org> To: freebsd-git@freebsd.org Subject: Re: Referencing git commit in the comment of Bugzilla From: Yasuhiro Kimura In-Reply-To: <20210205.094644.1159184285479762732.yasu@utahime.org> References: <20210205.094644.1159184285479762732.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DWxgz0h7rz3kc0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=FGwT7UPU; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org:c]; MV_CASE(0.50)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[utahime.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-git] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 00:51:44 -0000 From: Yasuhiro Kimura Subject: Referencing git commit in the comment of Bugzilla Date: Fri, 05 Feb 2021 09:46:44 +0900 (JST) > Hell All, Gaaaahhhh, not "Hell" but "Hello'. Why I overlooked such evil typo.... Sorry everyone... --- Yasuhiro Kimura From owner-freebsd-git@freebsd.org Fri Feb 5 11:04:43 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2FB825448DB for ; Fri, 5 Feb 2021 11:04:43 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.xs4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXCHG5Znmz4rll for ; Fri, 5 Feb 2021 11:04:42 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from cust-d4a83f22 ([IPv6:fc0c:c11d:cecc:f58a:eaa1:c0:9d8f:c143]) by smtp-cloud8.xs4all.net with ESMTPA id 7yullOiOwW4yN7yumleq5p; Fri, 05 Feb 2021 12:04:40 +0100 From: Adriaan de Groot To: freebsd-git@freebsd.org Subject: Re: Referencing git commit in the comment of Bugzilla Date: Fri, 05 Feb 2021 12:04:33 +0100 Message-ID: <2268670.THHZn3L5Ee@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: <20210205.094644.1159184285479762732.yasu@utahime.org> References: <20210205.094644.1159184285479762732.yasu@utahime.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3763654.kAAoriTUSa"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4xfPOyqdDZL4iJQQruO+fp0KXKW8UhpunxAIeNskxq6J9TSFbzQZ+A500rHYPrTc/EDHThPAdoCq0WvSsXKeAmPzcjKuoIroBQJfEIK31YAVc+9DPbaVTe FB82e8nYKkBGZCnmlBfmJrsEM9XIYLuJsjnRKJxDVVsXChRcDHqTwtM6VNls9ISqFnkZEzO9fO3S0ptNOfbGtMvZIsKOSCO6B/YP14WhmD1rqO/fxznUE7wJ IpQBPgTJAgaXR68gdEaycT6lnHa+0ELVBN6sn8CCApTjlCFSzNTCpsIY8AkTFaAl X-Rspamd-Queue-Id: 4DXCHG5Znmz4rll X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 11:04:43 -0000 --nextPart3763654.kAAoriTUSa Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Adriaan de Groot To: freebsd-git@freebsd.org Cc: Yasuhiro Kimura Subject: Re: Referencing git commit in the comment of Bugzilla Date: Fri, 05 Feb 2021 12:04:33 +0100 Message-ID: <2268670.THHZn3L5Ee@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: <20210205.094644.1159184285479762732.yasu@utahime.org> References: <20210205.094644.1159184285479762732.yasu@utahime.org> On Friday, 5 February 2021 01:46:44 CET Yasuhiro Kimura wrote: > Doc and src have already migrated to git and ports will follow soon. > In this situation it's quite possbile that bug reporter wants to > reference git commit in the comment of bug report submitted to > Bugzilla. Then is there standard(?) way to do it? As for subversion > syntax such as "base r123456" or "ports r778899" is provided. And I > expect similar one is provided for git. Since a "git commit" has a hash, there is no nice number-that-always-goes-up to specify a commit; there **is** the hash, though, which might be b8a9c4c3b78aa58e289dd9212f399e3f6af690b0 That is a long and annoying string, and since *usually* there are no collisions, git provides "short hash" notation: a unique prefix of the commit hash is enough. In the specific repository I'm working in, b8a9c4c3b is enough: 9 characters instead of 40. In a different repo (FreeBSD ports, as it happens), asking for a short hash (of a different commit) gives me be24aaa957c8 so 12 characters. The commit before that one was ef537e763f17 which shows there is no nice number-that-always-goes-up property. To get the hash, use (for instance) `git log -1`; to get the shorter one, use `git log -1 --abbrev-commit`. You could add an alias ("slog", for short-log) adding `--abbrev-commit` if you always want to see the short hash; do note that the short hash can become *longer* later in history if a prefix collision does happen. [ade] --nextPart3763654.kAAoriTUSa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEhrjttu2OP5apuuy1z93JbxKxkVwFAmAdJkEACgkQz93JbxKx kVyAlwwArG0BhNzmB8dXEgirR/ydWDypKNzrwSwsvcJGqRJqHbx/k1vjU8aF+Ebh zh2YRRJXRuXmf3ptj/sjcBdnV43Dl/bLrivZVZeeafq7Yv0ReMsf0orTAolC+sw+ I1vyxPjpTNellu4bVgn9MsN1OBMVmcXj/7w+2glJexiJqn3DaFrp9EQkmFDJ3pUy DeOvKAX4tovLfZpuCUaaCdJZVAwEPC0y1aAemGF/BFfGlAGD0n3rRmgZ/KDEh1x2 iZkod3V+9t/k7tPnOvkMKtZaitBce8NbgFsjlFy+4CSdjY89rhvnkG0cO8hSacSu 0uMTAHn6tHVHoairy+H/puu+4xSTFdrSRe8fU2DDPfHBG2L/BrwfNycCjv/VTTFo WsRnh81VD/7pNe6NofZyZBBVl0rLcokUAh9TzKBNlIZ6CZTGXFcVBzXQtazmXW+c EKx+PW5MAt5wUrsHm7ZTfi7qJ/zvoCG5yb/HESoFj/J7Way4bsE7zgKo5wyBndTD N10a2pS/ =RUZh -----END PGP SIGNATURE----- --nextPart3763654.kAAoriTUSa-- From owner-freebsd-git@freebsd.org Fri Feb 5 11:24:20 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9AEAE54588F for ; Fri, 5 Feb 2021 11:24:20 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.xs4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXCjw2WvCz4tCF for ; Fri, 5 Feb 2021 11:24:20 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from cust-d4a83f22 ([IPv6:fc0c:c11d:cecc:f58a:eaa1:c0:9d8f:c143]) by smtp-cloud8.xs4all.net with ESMTPA id 7zDllOpx4W4yN7zDmletuS; Fri, 05 Feb 2021 12:24:19 +0100 From: Adriaan de Groot To: freebsd-git@freebsd.org Subject: Re: Referencing git commit in the comment of Bugzilla Date: Fri, 05 Feb 2021 12:24:17 +0100 Message-ID: <2170105.sMrx5ctUpN@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: <20210205.094644.1159184285479762732.yasu@utahime.org> References: <20210205.094644.1159184285479762732.yasu@utahime.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3020904.ZmR5Pbtf01"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4xfFXNeG3HFwMTnmCCaD2P4IEqcOIz6LbBVNM6sg0+mxCOAwi+PcuA05g72+tngcEF5Nf5/h4BNc2Co+5bSYkZEqW+mUmB8inJqmSRFDCJbQtq7Rg32OIb u3BoJqfIRm3W2HdhSHP3u5CvIJO01OC/gE94tn+mioH4mmdCdWyBgiBz7imgY17xcRzcdjeCoALCl8X4/d0SdQwMn1oeOyoyDRaLd2hkFL+iLrkqsB5RU0z8 bm/hwQ29XrMQfBqYbE7YSpYN91MjSGxcca/6a7u6iOEQUvbincYVztDP+UoOxTvX X-Rspamd-Queue-Id: 4DXCjw2WvCz4tCF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 11:24:20 -0000 --nextPart3020904.ZmR5Pbtf01 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Adriaan de Groot To: freebsd-git@freebsd.org Cc: Yasuhiro Kimura Subject: Re: Referencing git commit in the comment of Bugzilla Date: Fri, 05 Feb 2021 12:24:17 +0100 Message-ID: <2170105.sMrx5ctUpN@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: <20210205.094644.1159184285479762732.yasu@utahime.org> References: <20210205.094644.1159184285479762732.yasu@utahime.org> On Friday, 5 February 2021 01:46:44 CET Yasuhiro Kimura wrote: > Doc and src have already migrated to git and ports will follow soon. > In this situation it's quite possbile that bug reporter wants to > reference git commit in the comment of bug report submitted to > Bugzilla. Then is there standard(?) way to do it? As for subversion > syntax such as "base r123456" or "ports r778899" is provided. And I > expect similar one is provided for git. Carrying on with two points: - If you always want to see short hashes in `git log` and similar commands, you can configure it. Set `log.abbrevCommit` to true, for instance git config --global log.abbrevCommit true You can leave out `--global` if you only want to apply it to the "current" git repository, which is wherever your current working directory is. - To address the nice-number-that-goes-up issue -- and remember, git is all branchy -- you can ask the question "can I follow commit history from hash A to hash B?". I'm not sure git can answer this question directly, but a question you **can** ask is "what is the shared ancestor commit of hash A and hash B?". If the answer is "A" then B is reachable from A, and A comes before B. If the answer is "B" then it's the other way around. And if there is some **other** answer, then the two hashes are not ordered -- for instance, when they are in different branches. Git provides the `merge-base` command to find that common ancestor, with a flag `--is-ancestor` to .. huh, to answer the original question and return a truthiness exit value, for instance: git merge-base --is-ancestor c5cc7822b0494e5474c2f305dda95aabeb64aa6f b8a9c4c3b78aa58e289dd9212f399e3f6af690b0 && echo yes [ade] --nextPart3020904.ZmR5Pbtf01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEhrjttu2OP5apuuy1z93JbxKxkVwFAmAdKuEACgkQz93JbxKx kVxAvQv/RZfOihXlwCOZ7eHREQ7mQRQLXr5kL3uUb57d0JUdqTTjiFGibfZ8Wp5H xzj+osHyQ+hcVznKIKxx2NJDkjbZ0P1gq+EcFhLcod4ThU1360sJ6L1MVAPPJNfN r/4Q5vDc1ZC/yIE+5O6/PvrOkIVH/Haw7tHGMDLFbvA7oy9DjUG9B8udtUkOo2rM bNrQVVMXQhsIrMQSp/s6bU3QHMdDX0+voBKRePS9ypaXOte00v9HKvoSITZNk/H3 9xBNyIaK1ycrsEuB2OgM5dKoR/vRUZ+wk08AechJebGDJk8YBbaMK70kLXu1Mccd WFbFQMkt96LbE7J874SriH8lyikzStkkTsx5IH6Bb1VG+w90pVC8/3aTaWWAb0Cz mEMT8QuU+JvHPHNP7rtQqQTtn3cF6ul9p2RXVMu5eleUt08oAPX8J+TJOFa6ZJu1 2zmAGTD4wmN1IyH9k5c3yWoUvQXWGhUJPus49jMT/ro4d8SAz3QAnBoZD3+frr4i YVIpdUvZ =+UpU -----END PGP SIGNATURE----- --nextPart3020904.ZmR5Pbtf01-- From owner-freebsd-git@freebsd.org Fri Feb 5 18:03:06 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5B6B854DF45 for ; Fri, 5 Feb 2021 18:03:06 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXNZ226y2z3rCy; Fri, 5 Feb 2021 18:03:06 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 3B98C25B06; Fri, 5 Feb 2021 18:03:06 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f171.google.com with SMTP id n15so7760025qkh.8; Fri, 05 Feb 2021 10:03:06 -0800 (PST) X-Gm-Message-State: AOAM530cVz98NS8gHJzcJM9Oo2gaKE0PAv+m4lhoTck56+478D2Xnkri l45IqwB8fC48Vvg3wELY0jMwKM9pVcuXEnw6MQU= X-Google-Smtp-Source: ABdhPJycsAJ06NiRYU4lf03GNS7u64nP4FE+d4GeYLW7Mjbp+Jwa1Zwjtu034JIyVIUxVcRVZezr1t2801Kkkq3Yygs= X-Received: by 2002:a37:745:: with SMTP id 66mr5995477qkh.120.1612548185585; Fri, 05 Feb 2021 10:03:05 -0800 (PST) MIME-Version: 1.0 From: Kyle Evans Date: Fri, 5 Feb 2021 12:02:52 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Branch point/branch point tags To: freebsd-git Cc: FreeBSD Release Engineering Team , John Baldwin Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 18:03:06 -0000 Hello! For some context: I received an e-mail from the commit about releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch releng/13.0"), but it's unfortunately impossible to tell based on e-mail context which commit it branched off on. Notably, commit races happen and re@ isn't obligated to pick 'the latest at that exact time' as far as I'm aware -- presumably they have carte blanche to pick whichever commit they feel is a good choice. We didn't really have this issue with svn because there was a single commit that announced both implicitly in the addition summary as well as explicitly which commit was chosen as the branch point (referencing "svn commit: r339434 - stable/12"). We can of course discover what we care about in the git world by clicking on the link to go to cgit and exploring the parent, but this is decidedly not always convenient. I had thought of one solution, but it's not great; adding the parent commit hash to the mail when a new ref is pushed. That imposes some weird limitations that remove some of the benefit of git, e.g., re@ would have to push the branch in the first commit then push any follow-up unless we can slap it on 'the first commit in a push that created a new ref'. This is kind of silly when they can just prepare everything that needs to be done and push it with confidence in a single step. jhb@ pointed out on IRC another possible solution, and I'm wondering what the git wg and re@ think... apparently, in the dark ages that far predate me (CVS), we had something like a BP ("Branch Point") tag that served the same purpose. - Is this desirable information for anyone else to have? - Would it screw up anything we actively try to do? I imagine, for example, that re would just create an annotated RELENG_13_0_BP tag and push that, which would serve as the announcement that this is the commit for reference and perhaps also be good bisect targets. While `git merge-base` works well for simply matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP it's definitely quicker to conjure up the well-defined tag name than `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base releng/13.0 stable/13)` Thoughts? Thanks, Kyle Evans From owner-freebsd-git@freebsd.org Fri Feb 5 18:16:13 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 01F4054EC06 for ; Fri, 5 Feb 2021 18:16:13 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXNs85Qr5z3sXM; Fri, 5 Feb 2021 18:16:12 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1612548972; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yBjZZxz7o9ZfgKdZ9eSIp0wDez+4V0SUAYzCKtdGgCQ=; b=vuQXbpGvoixQzvkxcG4eBS25nYdvzWCc86WOTZ5UM2nH1E1jjOdLGweCC8/tvi3Mq85OMi vKNeRFggR+1bvnt8sML6FiIh4Xam0sMiSzTMnmdYoylTpYRdJVAH3c6uJjKkDOlYs3LC4Q GNATrU/FzxCrIM4H4YJpM3sG93MBPcecVom2B32BXL0vxs0tZiJvV6vCtt9rpMuucp4uYD IYDAl/PXipw8HsPW5JYlcnLRjO/ziKfqFzuXGIXgKrjlCjNCr42vMOhPirRdo1B0IkIkLL vLOJcLnL2v43MZIgxo9Sm4Cs3+2Bqex8HRn7MU7q54Pl5gDJ6j4rrvM6Sidp/Q== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 572A21FC08; Fri, 5 Feb 2021 18:16:12 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 5 Feb 2021 18:16:09 +0000 From: Glen Barber To: Kyle Evans Cc: freebsd-git , FreeBSD Release Engineering Team , John Baldwin Subject: Re: Branch point/branch point tags Message-ID: <20210205181609.GS77557@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ByPQBpNkGlvUu0tn" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1612548972; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yBjZZxz7o9ZfgKdZ9eSIp0wDez+4V0SUAYzCKtdGgCQ=; b=s3ZA+Wa9IwUnMAmgZ30IENgka3a5lMNhzr5ruxfhJ6pJasvnwK17k0OGlOxbbJZ5v7xvUK jxom5t00Q7CvBztv4dCUOVBGjyb5tFUDDLTuW/5v2GHteYjd319GL+LSIPdNt9bmDc3xEI cY7d+JuC2NOeoJmHQdalIsBWU4IcQS/ljhw5g4gPZkW/dDikOLBG8GRSuWv0ADI2NCQFGn Fl4+mt83DMaSH8QhwBNGFElaGkkDMg7Bi1hcCfE4YZA46FY8OmX9fx1Qn3KCXwhBmqZCPT hNnlKhHDk6gqFqAnSV7SPc8M0tKMfsc2cmROVAD/VaflTBN/ZI//Dxy+tH6WBw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1612548972; a=rsa-sha256; cv=none; b=sDcHDb7Fg1BZ0lMr1H6S6PamKFjyeoSuZiREgAy6n/F+MNTeUR/DdBGgezbHyl+SpCkNnO E8Q7f8FRWLmkPwCTuYXUb2GmlqcCsMFVtdXC5dQcZpJ6ocLU3V6UnHR4tw4r+NTfVD7mc7 V4Bj5/V930SZbz48yRbUz2HVlt//GoLaJlovNuJZG6YSBhrqtdU/xxfdh+dmF/XUVF2pH5 Z7z0ZB9lUvZeGwvgQ2KV4UfgX6O/W2k4Ke0V4FvM1vkJbQ1AAXDDs+Nqf4PNM6w13SKtqs n0UEGu4CN5iHeC1NENb0N+pq+uK55BoGYHdM299XbNrNpwHbqlHr+5NO3FVC9g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 18:16:13 -0000 --ByPQBpNkGlvUu0tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 05, 2021 at 12:02:52PM -0600, Kyle Evans wrote: > Hello! >=20 > For some context: I received an e-mail from the commit about > releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch > releng/13.0"), but it's unfortunately impossible to tell based on > e-mail context which commit it branched off on. Notably, commit races > happen and re@ isn't obligated to pick 'the latest at that exact time' > as far as I'm aware -- presumably they have carte blanche to pick > whichever commit they feel is a good choice. >=20 > We didn't really have this issue with svn because there was a single > commit that announced both implicitly in the addition summary as well > as explicitly which commit was chosen as the branch point (referencing > "svn commit: r339434 - stable/12"). >=20 > We can of course discover what we care about in the git world by > clicking on the link to go to cgit and exploring the parent, but this > is decidedly not always convenient. >=20 > I had thought of one solution, but it's not great; adding the parent > commit hash to the mail when a new ref is pushed. That imposes some > weird limitations that remove some of the benefit of git, e.g., re@ > would have to push the branch in the first commit then push any > follow-up unless we can slap it on 'the first commit in a push that > created a new ref'. This is kind of silly when they can just prepare > everything that needs to be done and push it with confidence in a > single step. >=20 > jhb@ pointed out on IRC another possible solution, and I'm wondering > what the git wg and re@ think... apparently, in the dark ages that far > predate me (CVS), we had something like a BP ("Branch Point") tag that > served the same purpose. >=20 > - Is this desirable information for anyone else to have? > - Would it screw up anything we actively try to do? >=20 > I imagine, for example, that re would just create an annotated > RELENG_13_0_BP tag and push that, which would serve as the > announcement that this is the commit for reference and perhaps also be > good bisect targets. While `git merge-base` works well for simply > matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP > it's definitely quicker to conjure up the well-defined tag name than > `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base > releng/13.0 stable/13)` >=20 I do not have any comments on the solutions here, but I will make sure it is brought up during the next working group call. Admittedly, I probably should have explicitly stated releng/13.0 was branched from stable/13, but I suppose part of me just figured it would be obvious =66rom a workflow perspective. But given I am personally so familiar with the workflow in this case, it was a bad assumption on my part, either intentional or otherwise. That said, I will be more thoughtful of this in the future, regardless of what solution(s) (if any) are implemented. Thank you for pointing this out. Glen --ByPQBpNkGlvUu0tn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmAdi2kACgkQAxRYpUeP 4pM7Ag/+MTapjRmtewVM/1fwJemEetr8kKvceVBq4HXiOFUVuJHg3mxkLJGA8zHV 9ki3xeM/DTSDEeMrnbm9OnvN91h+3w92CTvv8jJ0aeWt+QbgUIqQAb/stOCqIoTb 56C3DMqhi0w6r+RXYyIEYAQDHuFnFrL73BGq+YlvDgCnEe4yrqBH42LiWcK5sfov X+N/4BxVg6aRSUSO4miYwacyX6jOG7yUXuPn5HuckspgnUiniOb7stJW9Uz8nHCN 7qCyjcZRKbPMAREO7gOSzbREWK2wFb5/7xnmaB9lwRkSi9jjPch2bagI1XeatSTF rwFkp/r/HF5iNldVzjng3pHgWy5aexQ34ZTyzjw6/SCbSGiHYCOKwPWu3l8m+Qk/ DrTOXBvgtIdQMwHiAXF1q4mW7TcJSDroDg0xrLQF2eryNEARWqYdrO98SgAAKh3/ Nu20Qm5rOPh0FXvQZJW2WlhHa03eO1HPIwqN1+r5Ed8Y6YvJ+4E+MPYJPfE0Tqux DtGCGqmOEGNXFYV5W9RvK5BU6NpgMMvpVhbK4WD9xJLyw7W5/Deq608GG74J+5aq 1WgRte1tMcB9L2ZC3YOKUbtqLZ5biEKzHAX4rFI0TbAqn/K/wqsqClKRCMAD2q95 IOEOrNeRJI45Po49+887AD2bfm7SCoCI+i+rsFIGYb8o+EuMZkw= =A6Lr -----END PGP SIGNATURE----- --ByPQBpNkGlvUu0tn-- From owner-freebsd-git@freebsd.org Fri Feb 5 18:50:16 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CB72054F5B7 for ; Fri, 5 Feb 2021 18:50:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXPcS5S3Wz3v11; Fri, 5 Feb 2021 18:50:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:cd23:6cb6:5cbf:14e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 3D98526105; Fri, 5 Feb 2021 18:50:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Glen Barber , Kyle Evans Cc: freebsd-git , FreeBSD Release Engineering Team References: <20210205181609.GS77557@FreeBSD.org> From: John Baldwin Subject: Re: Branch point/branch point tags Message-ID: Date: Fri, 5 Feb 2021 10:50:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210205181609.GS77557@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 18:50:16 -0000 On 2/5/21 10:16 AM, Glen Barber wrote: > On Fri, Feb 05, 2021 at 12:02:52PM -0600, Kyle Evans wrote: >> Hello! >> >> For some context: I received an e-mail from the commit about >> releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch >> releng/13.0"), but it's unfortunately impossible to tell based on >> e-mail context which commit it branched off on. Notably, commit races >> happen and re@ isn't obligated to pick 'the latest at that exact time' >> as far as I'm aware -- presumably they have carte blanche to pick >> whichever commit they feel is a good choice. >> >> We didn't really have this issue with svn because there was a single >> commit that announced both implicitly in the addition summary as well >> as explicitly which commit was chosen as the branch point (referencing >> "svn commit: r339434 - stable/12"). >> >> We can of course discover what we care about in the git world by >> clicking on the link to go to cgit and exploring the parent, but this >> is decidedly not always convenient. >> >> I had thought of one solution, but it's not great; adding the parent >> commit hash to the mail when a new ref is pushed. That imposes some >> weird limitations that remove some of the benefit of git, e.g., re@ >> would have to push the branch in the first commit then push any >> follow-up unless we can slap it on 'the first commit in a push that >> created a new ref'. This is kind of silly when they can just prepare >> everything that needs to be done and push it with confidence in a >> single step. >> >> jhb@ pointed out on IRC another possible solution, and I'm wondering >> what the git wg and re@ think... apparently, in the dark ages that far >> predate me (CVS), we had something like a BP ("Branch Point") tag that >> served the same purpose. >> >> - Is this desirable information for anyone else to have? >> - Would it screw up anything we actively try to do? >> >> I imagine, for example, that re would just create an annotated >> RELENG_13_0_BP tag and push that, which would serve as the >> announcement that this is the commit for reference and perhaps also be >> good bisect targets. While `git merge-base` works well for simply >> matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP >> it's definitely quicker to conjure up the well-defined tag name than >> `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base >> releng/13.0 stable/13)` >> > > I do not have any comments on the solutions here, but I will make sure > it is brought up during the next working group call. Admittedly, > I probably should have explicitly stated releng/13.0 was branched from > stable/13, but I suppose part of me just figured it would be obvious > from a workflow perspective. But given I am personally so familiar with > the workflow in this case, it was a bad assumption on my part, either > intentional or otherwise. > > That said, I will be more thoughtful of this in the future, regardless > of what solution(s) (if any) are implemented. Thank you for pointing > this out. I don't know that we want all-caps tag names in a git world, btw. That was just something we did in CVS (and I do think we had tags like RELENG_2_2_BP and RELENG_3_BP). Part of the reason was that there were no changesets in CVS, so you really had to have a tag for sanity. I do think tags might be nice, e.g. if we had a stable-13-bp tag (or stable-13), then 'git describe --exclude "vendor/*"' on main would show the number of commits since 13 was branched which is more useful than what it shows now. Similarly, on stable/13 'git describe' would now be showing the number of commits since 13.0 was branched by default. I also think there's some merit to Kyle's argument that we can tell users 'git bisect releng-13.0-bp release/13.1' to bisect between releases. I'm sure there's some bikeshedding that can be had about tag names (- vs _, 'stable-13-bp' vs 'stable/13-bp' vs 'bp/stable/13'). In terms of sheer number of tags, I don't think this would add a ton of them (1 additional tag per stable and releng branch), and I would suggest we only start this for 13.x and not do it on older branches. We can always add this retroactively for older branches in the future if we found we really wanted/needed it. -- John Baldwin From owner-freebsd-git@freebsd.org Fri Feb 5 20:03:53 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA820528E3A for ; Fri, 5 Feb 2021 20:03:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXRFP680fz4T6F for ; Fri, 5 Feb 2021 20:03:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id t63so8218353qkc.1 for ; Fri, 05 Feb 2021 12:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J7JrVgUKIb+ylW7IGBgMJyoHrotwebYFNaMdNfPA/Uo=; b=0uO4wbNMAnVDrh3z5wQtOZseTy0jXPMjG/oMw1AG7H42q+vEdIJEvFna/gQjw1ooDY pFSwdeT14UwjoydtnQui0uh7x1z7Hts6DtyuaXcUkKRnf1r9/zv9/sCHL2mPRaCEB++l xKCYuHOveDzVwCJQrh7sVyDEGbPUnNo54vpfYDx/j1y9t4ylnT9uk9nKKf6kIlzYyhpe kWEkvPHl8CbPLFv4emQunSV8uJ7sx6vSPsB0Mx1VkhcxizSx0xcSjNsceoUnTimUlw0w P0xAK7ryplV2BqlQC4cCaxDbLKDIg+5bxoehp0VLZcA/2uSLfr/kSIO0BB5N2pyEvZDN UeyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J7JrVgUKIb+ylW7IGBgMJyoHrotwebYFNaMdNfPA/Uo=; b=RlzF4G9Q5B09EQVhfj6ik0CsCgC+Ag/TIadZ54HBNpf8eJuJi+fr2DmlUJnv+AoNLl zWSKlufYUnbOW5tXMtRsVo2VRJkUyfZuSO/EYV2+bazttp8q1ooZIVcra7vVi90FLuGk wIrZdB2cv7lHesul+jMEF8Z7RKIE92rwZE7BKkplj3Kkfoy2cpUciYP4DwAzttFnHHnZ tPo+t2JMeGHIwGP1xnsF78WjTN6ZnSoIjwP/8/ww+FbRup0QwFbx41YIjIecwh3YXdfY ezMN31YKsZc37GDQV8RZcBYXx/wAx7/lTotnl7PdHcK5f6tVQktz9gZ2wHYnzoK3jYuR /JgA== X-Gm-Message-State: AOAM5304hT23kH2F5enklcfXTdUaWnc5frnzu69aBOVwfsl1xTtFiBKJ oAECK4OAxPhU28/1fg0pnWo4JVld8HilhvshimGanA== X-Google-Smtp-Source: ABdhPJydwCHCR2QZCMpMfoJRYcyKztuysmzdoikLfbMGqHhSsObF7l1DpAl49h0aYMP6aQ6Z3WIEA6a5PlrMFWupLIc= X-Received: by 2002:a05:620a:110f:: with SMTP id o15mr5741415qkk.206.1612555432867; Fri, 05 Feb 2021 12:03:52 -0800 (PST) MIME-Version: 1.0 References: <20210205181609.GS77557@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Fri, 5 Feb 2021 13:03:41 -0700 Message-ID: Subject: Re: Branch point/branch point tags To: John Baldwin Cc: Glen Barber , Kyle Evans , freebsd-git , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 4DXRFP680fz4T6F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:03:54 -0000 On Fri, Feb 5, 2021 at 11:50 AM John Baldwin wrote: > On 2/5/21 10:16 AM, Glen Barber wrote: > > On Fri, Feb 05, 2021 at 12:02:52PM -0600, Kyle Evans wrote: > >> Hello! > >> > >> For some context: I received an e-mail from the commit about > >> releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch > >> releng/13.0"), but it's unfortunately impossible to tell based on > >> e-mail context which commit it branched off on. Notably, commit races > >> happen and re@ isn't obligated to pick 'the latest at that exact time' > >> as far as I'm aware -- presumably they have carte blanche to pick > >> whichever commit they feel is a good choice. > >> > >> We didn't really have this issue with svn because there was a single > >> commit that announced both implicitly in the addition summary as well > >> as explicitly which commit was chosen as the branch point (referencing > >> "svn commit: r339434 - stable/12"). > >> > >> We can of course discover what we care about in the git world by > >> clicking on the link to go to cgit and exploring the parent, but this > >> is decidedly not always convenient. > >> > >> I had thought of one solution, but it's not great; adding the parent > >> commit hash to the mail when a new ref is pushed. That imposes some > >> weird limitations that remove some of the benefit of git, e.g., re@ > >> would have to push the branch in the first commit then push any > >> follow-up unless we can slap it on 'the first commit in a push that > >> created a new ref'. This is kind of silly when they can just prepare > >> everything that needs to be done and push it with confidence in a > >> single step. > >> > >> jhb@ pointed out on IRC another possible solution, and I'm wondering > >> what the git wg and re@ think... apparently, in the dark ages that far > >> predate me (CVS), we had something like a BP ("Branch Point") tag that > >> served the same purpose. > >> > >> - Is this desirable information for anyone else to have? > >> - Would it screw up anything we actively try to do? > >> > >> I imagine, for example, that re would just create an annotated > >> RELENG_13_0_BP tag and push that, which would serve as the > >> announcement that this is the commit for reference and perhaps also be > >> good bisect targets. While `git merge-base` works well for simply > >> matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP > >> it's definitely quicker to conjure up the well-defined tag name than > >> `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base > >> releng/13.0 stable/13)` > >> > > > > I do not have any comments on the solutions here, but I will make sure > > it is brought up during the next working group call. Admittedly, > > I probably should have explicitly stated releng/13.0 was branched from > > stable/13, but I suppose part of me just figured it would be obvious > > from a workflow perspective. But given I am personally so familiar with > > the workflow in this case, it was a bad assumption on my part, either > > intentional or otherwise. > > > > That said, I will be more thoughtful of this in the future, regardless > > of what solution(s) (if any) are implemented. Thank you for pointing > > this out. > > I don't know that we want all-caps tag names in a git world, btw. That > was just something we did in CVS (and I do think we had tags like > RELENG_2_2_BP and RELENG_3_BP). Part of the reason was that there were > no changesets in CVS, so you really had to have a tag for sanity. > > I do think tags might be nice, e.g. if we had a stable-13-bp tag (or > stable-13), then 'git describe --exclude "vendor/*"' on main would > show the number of commits since 13 was branched which is more useful > than what it shows now. Similarly, on stable/13 'git describe' would > now be showing the number of commits since 13.0 was branched by > default. I also think there's some merit to Kyle's argument that we > can tell users 'git bisect releng-13.0-bp release/13.1' to bisect > between releases. I'm sure there's some bikeshedding that can be > had about tag names (- vs _, 'stable-13-bp' vs 'stable/13-bp' vs > 'bp/stable/13'). > > In terms of sheer number of tags, I don't think this would add a ton > of them (1 additional tag per stable and releng branch), and I would > suggest we only start this for 13.x and not do it on older branches. > We can always add this retroactively for older branches in the future > if we found we really wanted/needed it. > Do we need it? In the git world we can say stable/13..release/13.0 to get from wherever on the stable/13 branch it was branched to the tip of the branch. But you can also get this with 'git merge-base' as well, which is much more generic than dropping arbitrary tags. % git merge-base freebsd/stable/13 freebsd/releng/13.0 4c44dbde5491516eba8725dc51d39c1dcc817472 % git merge-base main freebsd/stable/13 679e4cdabdc5a93e5c0d7cdf3fc52202a8de02ef The whole reason we had it for CVS was because CVS was stupid and gave no way to refer to it. With git it's trivial to get this information with a single command one could use for these scenarios. This punts on all the 'what to name it' discussions too, which is an added bonus.. Warner From owner-freebsd-git@freebsd.org Fri Feb 5 20:36:38 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08991529C8F for ; Fri, 5 Feb 2021 20:36:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXRz60dZwz4WXV for ; Fri, 5 Feb 2021 20:36:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2d.google.com with SMTP id j13so4097823qvu.10 for ; Fri, 05 Feb 2021 12:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSul3M6ftFTnC5IyfH3p0yUVSFjJUV+aW0pHw1HYyx4=; b=y86vjnyJte7HTWXKBo/can0hBYO+WvkqzbCDhWMYd3XTp57HfRa+rsuUPlOLVY4YV4 AMriPILEUxxm1id8Ih+w9WBIBa3+pnPM3xJd0mCNCVHYruPNCzIGSnlkZgTHrAVWAcDa kTzJclGN2bAZAlycwZkYV0rLHHomfwtuEk5U0w5M7vh0pLLmWMUc9Enjgp4SMr1s9icn 8bC9yfBgupemic+EgZgfeeSWhlHS9AXByRhF/H2+tj4ozbtfEl0L60ddyLEpMvrhwVqh MTyxbvP8tWICzAIya3Lo9WC15Pw78fJ8OlX7W1VtV8BHa1Pi+CAE2iNqFDCwpQaIfAto 2FGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cSul3M6ftFTnC5IyfH3p0yUVSFjJUV+aW0pHw1HYyx4=; b=UqhAeVYd9YBzxWoRvBwa5JdtnlMRBsq0K03LKdbb6Qz1/71g8R9QMvqzYx6utjJr8U JyCZdKh4o8y25BkO9fJGz6k94wGvWZNUsy0KVmpde61w/b7AbQP/tX5LlRYQg73NQ2SG MnNegeZS5m2U6MifK+EH2pqPuL98KDg2j7UCD1Z2enXhHupBit7RB9HbHeQywja0vQVq 98m7cXO4mGFaeG1ydGN8+CvG6gVTIPoNIi9p9j2hUL7xQr1Q9oUaevX0cWZN7kSENxFS WC5eRXEOUXPovDCvkX2IGaCPTrFMXEEIlRtRIp0O/V/pmqGUEe9Cebbj304rNg1H8ntL 7tCQ== X-Gm-Message-State: AOAM532GaPsT8X7F5tGYYs+gYvwW6bjKtjf3tBw/21i9/I56hx9flYrw YuLFMIrUxZPlLrXpMrYLr6fEVHVIMcS2Bl/SxLk9gg== X-Google-Smtp-Source: ABdhPJz8WAOauvwLh/hGwGDW6hSopW47dS6WrrtqOCqtIgyOTx65p7ek8rL8Vw6KPJoyNOllY9nxgoAek4dPPlC62J0= X-Received: by 2002:a0c:abce:: with SMTP id k14mr6276235qvb.23.1612557392022; Fri, 05 Feb 2021 12:36:32 -0800 (PST) MIME-Version: 1.0 References: <20210205181609.GS77557@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Fri, 5 Feb 2021 13:36:21 -0700 Message-ID: Subject: Re: Branch point/branch point tags To: John Baldwin Cc: Glen Barber , Kyle Evans , freebsd-git , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 4DXRz60dZwz4WXV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=y86vjnyJ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f2d:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2d:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f2d:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-git]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:36:38 -0000 On Fri, Feb 5, 2021 at 1:03 PM Warner Losh wrote: > > > On Fri, Feb 5, 2021 at 11:50 AM John Baldwin wrote: > >> On 2/5/21 10:16 AM, Glen Barber wrote: >> > On Fri, Feb 05, 2021 at 12:02:52PM -0600, Kyle Evans wrote: >> >> Hello! >> >> >> >> For some context: I received an e-mail from the commit about >> >> releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch >> >> releng/13.0"), but it's unfortunately impossible to tell based on >> >> e-mail context which commit it branched off on. Notably, commit races >> >> happen and re@ isn't obligated to pick 'the latest at that exact time' >> >> as far as I'm aware -- presumably they have carte blanche to pick >> >> whichever commit they feel is a good choice. >> >> >> >> We didn't really have this issue with svn because there was a single >> >> commit that announced both implicitly in the addition summary as well >> >> as explicitly which commit was chosen as the branch point (referencing >> >> "svn commit: r339434 - stable/12"). >> >> >> >> We can of course discover what we care about in the git world by >> >> clicking on the link to go to cgit and exploring the parent, but this >> >> is decidedly not always convenient. >> >> >> >> I had thought of one solution, but it's not great; adding the parent >> >> commit hash to the mail when a new ref is pushed. That imposes some >> >> weird limitations that remove some of the benefit of git, e.g., re@ >> >> would have to push the branch in the first commit then push any >> >> follow-up unless we can slap it on 'the first commit in a push that >> >> created a new ref'. This is kind of silly when they can just prepare >> >> everything that needs to be done and push it with confidence in a >> >> single step. >> >> >> >> jhb@ pointed out on IRC another possible solution, and I'm wondering >> >> what the git wg and re@ think... apparently, in the dark ages that far >> >> predate me (CVS), we had something like a BP ("Branch Point") tag that >> >> served the same purpose. >> >> >> >> - Is this desirable information for anyone else to have? >> >> - Would it screw up anything we actively try to do? >> >> >> >> I imagine, for example, that re would just create an annotated >> >> RELENG_13_0_BP tag and push that, which would serve as the >> >> announcement that this is the commit for reference and perhaps also be >> >> good bisect targets. While `git merge-base` works well for simply >> >> matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP >> >> it's definitely quicker to conjure up the well-defined tag name than >> >> `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base >> >> releng/13.0 stable/13)` >> >> >> > >> > I do not have any comments on the solutions here, but I will make sure >> > it is brought up during the next working group call. Admittedly, >> > I probably should have explicitly stated releng/13.0 was branched from >> > stable/13, but I suppose part of me just figured it would be obvious >> > from a workflow perspective. But given I am personally so familiar with >> > the workflow in this case, it was a bad assumption on my part, either >> > intentional or otherwise. >> > >> > That said, I will be more thoughtful of this in the future, regardless >> > of what solution(s) (if any) are implemented. Thank you for pointing >> > this out. >> >> I don't know that we want all-caps tag names in a git world, btw. That >> was just something we did in CVS (and I do think we had tags like >> RELENG_2_2_BP and RELENG_3_BP). Part of the reason was that there were >> no changesets in CVS, so you really had to have a tag for sanity. >> >> I do think tags might be nice, e.g. if we had a stable-13-bp tag (or >> stable-13), then 'git describe --exclude "vendor/*"' on main would >> show the number of commits since 13 was branched which is more useful >> than what it shows now. Similarly, on stable/13 'git describe' would >> now be showing the number of commits since 13.0 was branched by >> default. I also think there's some merit to Kyle's argument that we >> can tell users 'git bisect releng-13.0-bp release/13.1' to bisect >> between releases. I'm sure there's some bikeshedding that can be >> had about tag names (- vs _, 'stable-13-bp' vs 'stable/13-bp' vs >> 'bp/stable/13'). >> >> In terms of sheer number of tags, I don't think this would add a ton >> of them (1 additional tag per stable and releng branch), and I would >> suggest we only start this for 13.x and not do it on older branches. >> We can always add this retroactively for older branches in the future >> if we found we really wanted/needed it. >> > > Do we need it? In the git world we can say stable/13..release/13.0 to get > from wherever on the stable/13 branch it was branched to the tip of the > branch. But you can also get this with 'git merge-base' as well, which is > much more generic than dropping arbitrary tags. > > % git merge-base freebsd/stable/13 freebsd/releng/13.0 > 4c44dbde5491516eba8725dc51d39c1dcc817472 > % git merge-base main freebsd/stable/13 > 679e4cdabdc5a93e5c0d7cdf3fc52202a8de02ef > > The whole reason we had it for CVS was because CVS was stupid and gave no > way to refer to it. With git it's trivial to get this information with a > single command one could use for these scenarios. > I forgot to include: % git rev-list --first-parent --count main..freebsd/stable/13 153 % git rev-list --first-parent --count freebsd/stable/13..freebsd/releng/13.0 2 which gives the 'git describe' info but in a more reliable manner due to the 'unexpectedly weird to many' way that it counts things. Warner > This punts on all the 'what to name it' discussions too, which is an added > bonus.. > > Warner > From owner-freebsd-git@freebsd.org Fri Feb 5 20:59:24 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0A68752A188 for ; Fri, 5 Feb 2021 20:59:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXSTR6sr1z4XM2; Fri, 5 Feb 2021 20:59:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:cd23:6cb6:5cbf:14e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 3F99425F7A; Fri, 5 Feb 2021 20:59:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Warner Losh Cc: Glen Barber , Kyle Evans , freebsd-git , FreeBSD Release Engineering Team References: <20210205181609.GS77557@FreeBSD.org> From: John Baldwin Subject: Re: Branch point/branch point tags Message-ID: <0e42286c-aaa3-8b99-bd4a-fae002d97743@FreeBSD.org> Date: Fri, 5 Feb 2021 12:59:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:59:24 -0000 On 2/5/21 12:03 PM, Warner Losh wrote: > On Fri, Feb 5, 2021 at 11:50 AM John Baldwin wrote: > >> On 2/5/21 10:16 AM, Glen Barber wrote: >>> On Fri, Feb 05, 2021 at 12:02:52PM -0600, Kyle Evans wrote: >>>> Hello! >>>> >>>> For some context: I received an e-mail from the commit about >>>> releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch >>>> releng/13.0"), but it's unfortunately impossible to tell based on >>>> e-mail context which commit it branched off on. Notably, commit races >>>> happen and re@ isn't obligated to pick 'the latest at that exact time' >>>> as far as I'm aware -- presumably they have carte blanche to pick >>>> whichever commit they feel is a good choice. >>>> >>>> We didn't really have this issue with svn because there was a single >>>> commit that announced both implicitly in the addition summary as well >>>> as explicitly which commit was chosen as the branch point (referencing >>>> "svn commit: r339434 - stable/12"). >>>> >>>> We can of course discover what we care about in the git world by >>>> clicking on the link to go to cgit and exploring the parent, but this >>>> is decidedly not always convenient. >>>> >>>> I had thought of one solution, but it's not great; adding the parent >>>> commit hash to the mail when a new ref is pushed. That imposes some >>>> weird limitations that remove some of the benefit of git, e.g., re@ >>>> would have to push the branch in the first commit then push any >>>> follow-up unless we can slap it on 'the first commit in a push that >>>> created a new ref'. This is kind of silly when they can just prepare >>>> everything that needs to be done and push it with confidence in a >>>> single step. >>>> >>>> jhb@ pointed out on IRC another possible solution, and I'm wondering >>>> what the git wg and re@ think... apparently, in the dark ages that far >>>> predate me (CVS), we had something like a BP ("Branch Point") tag that >>>> served the same purpose. >>>> >>>> - Is this desirable information for anyone else to have? >>>> - Would it screw up anything we actively try to do? >>>> >>>> I imagine, for example, that re would just create an annotated >>>> RELENG_13_0_BP tag and push that, which would serve as the >>>> announcement that this is the commit for reference and perhaps also be >>>> good bisect targets. While `git merge-base` works well for simply >>>> matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP >>>> it's definitely quicker to conjure up the well-defined tag name than >>>> `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base >>>> releng/13.0 stable/13)` >>>> >>> >>> I do not have any comments on the solutions here, but I will make sure >>> it is brought up during the next working group call. Admittedly, >>> I probably should have explicitly stated releng/13.0 was branched from >>> stable/13, but I suppose part of me just figured it would be obvious >>> from a workflow perspective. But given I am personally so familiar with >>> the workflow in this case, it was a bad assumption on my part, either >>> intentional or otherwise. >>> >>> That said, I will be more thoughtful of this in the future, regardless >>> of what solution(s) (if any) are implemented. Thank you for pointing >>> this out. >> >> I don't know that we want all-caps tag names in a git world, btw. That >> was just something we did in CVS (and I do think we had tags like >> RELENG_2_2_BP and RELENG_3_BP). Part of the reason was that there were >> no changesets in CVS, so you really had to have a tag for sanity. >> >> I do think tags might be nice, e.g. if we had a stable-13-bp tag (or >> stable-13), then 'git describe --exclude "vendor/*"' on main would >> show the number of commits since 13 was branched which is more useful >> than what it shows now. Similarly, on stable/13 'git describe' would >> now be showing the number of commits since 13.0 was branched by >> default. I also think there's some merit to Kyle's argument that we >> can tell users 'git bisect releng-13.0-bp release/13.1' to bisect >> between releases. I'm sure there's some bikeshedding that can be >> had about tag names (- vs _, 'stable-13-bp' vs 'stable/13-bp' vs >> 'bp/stable/13'). >> >> In terms of sheer number of tags, I don't think this would add a ton >> of them (1 additional tag per stable and releng branch), and I would >> suggest we only start this for 13.x and not do it on older branches. >> We can always add this retroactively for older branches in the future >> if we found we really wanted/needed it. >> > > Do we need it? In the git world we can say stable/13..release/13.0 to get > from wherever on the stable/13 branch it was branched to the tip of the > branch. But you can also get this with 'git merge-base' as well, which is > much more generic than dropping arbitrary tags. True, though one of Kyle's explicit points was to avoid forcing users to use merge-base. I think one thing to consider is the command line we tell users to use for bisecting and what is more friendly for users to use (who may not be git savvy). Using merge-base is probably fine, but all of the examples you gave probably look a bit intimidating to a non-developer user who is less familiar with git. We will probably just have to make sure we have some good recipes for things like "how to bisect between releases" because 'git bisect release/13.0 release/13.1' won't work. It is true that we can always wait to see whether or not there is a need over time (e.g. how do users on stable@ cope with using stable/13 via git instead of svn) since tags can be added retroactively. -- John Baldwin From owner-freebsd-git@freebsd.org Fri Feb 5 21:59:11 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F41F852B61B for ; Fri, 5 Feb 2021 21:59:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXTpQ6M9jz4bsy for ; Fri, 5 Feb 2021 21:59:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id l23so6112013qtq.13 for ; Fri, 05 Feb 2021 13:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zGwPnxZG+bOrCfgFVb9Y+F56ZBa2fuopFAARyFbJSa8=; b=dtaEh8VUaGTcfICFlRCPfvPVaEetVVhuv4Nx7nosXvXNamAzTx+ofSZB1F46ShHmye 7XAuBPwrtIfeIICp2saeV05o/hbB1Qm8Mc8WJZT3uNklle/Z2aEqujnRSIcFGk/KqNRq 6j9owALkKQCMV1+sGSvg8wJ68OoxakXoi0oYkX3dP/XQajoINuUe0+j+bNkQTrfeeo7N FQ2kmMsMpojipMGx+sgjDdJOIb4oXGA9OLDLmF+btW3vWGD8qXlNIOaYZJcAKP1AsyIl 4MGNART7dpUdqqzSPmtd+KnfZWowffG/ebXQ3yAXVYGKqfD1W4ZfXRziPlHdvZDidAMF F+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zGwPnxZG+bOrCfgFVb9Y+F56ZBa2fuopFAARyFbJSa8=; b=hqVsBDwzyzk2LfxdNuNek+reDPiW8fg7wo6XOHlk+oyOOkAClW0ZbAUgOn9Lw/SA9S JU75zbmd7y1MtUHeEa3a8RjUV2hCv89E8N4SAFPX8Aezxy7q9mAObM2WGH5JJSlykqhW BHI0JU7447bQhUZvivmyJWMtkYHolg3pW2/NxDwO+jXuMZ4L1XNrRtqIAGoBe7OyGkkn CHB9BJ3K86WVmCN+qgFQVZthXAmjyvCU2VVKJgxvkmZZ2Tbzb87Suno1S7VJVRkFc2P2 hFwAOVF5oDXU3vBy2l73bCs2lX3c+OH7xbl8EXjujbfzbKgiFC2uZyf7R3hyNkPfKiNk Tlqg== X-Gm-Message-State: AOAM531xsYlT2SOeh+J5J6waJkGOw5Gyp/2rAPhOC9XKUyPPqCby4jtU /G8lmqxmKcyvfbB4fM46Y3LkBlwx99wWGYT0V0jYSQ== X-Google-Smtp-Source: ABdhPJym+6yjJklyurOBISB4jEhm3c42Kq5APNjC3HAYiv5uZoYEl+NVrN5lFWGX2fstCrdHv1L7ieyFI0DQiQxbPyY= X-Received: by 2002:a05:622a:303:: with SMTP id q3mr6121951qtw.235.1612562349812; Fri, 05 Feb 2021 13:59:09 -0800 (PST) MIME-Version: 1.0 References: <20210205181609.GS77557@FreeBSD.org> <0e42286c-aaa3-8b99-bd4a-fae002d97743@FreeBSD.org> In-Reply-To: <0e42286c-aaa3-8b99-bd4a-fae002d97743@FreeBSD.org> From: Warner Losh Date: Fri, 5 Feb 2021 14:58:58 -0700 Message-ID: Subject: Re: Branch point/branch point tags To: John Baldwin Cc: Glen Barber , Kyle Evans , freebsd-git , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 4DXTpQ6M9jz4bsy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 21:59:11 -0000 On Fri, Feb 5, 2021 at 1:59 PM John Baldwin wrote: > On 2/5/21 12:03 PM, Warner Losh wrote: > > On Fri, Feb 5, 2021 at 11:50 AM John Baldwin wrote: > > > >> On 2/5/21 10:16 AM, Glen Barber wrote: > >>> On Fri, Feb 05, 2021 at 12:02:52PM -0600, Kyle Evans wrote: > >>>> Hello! > >>>> > >>>> For some context: I received an e-mail from the commit about > >>>> releng/13.0 being branched ("git: 638e531019fd - releng/13.0 - Branch > >>>> releng/13.0"), but it's unfortunately impossible to tell based on > >>>> e-mail context which commit it branched off on. Notably, commit races > >>>> happen and re@ isn't obligated to pick 'the latest at that exact > time' > >>>> as far as I'm aware -- presumably they have carte blanche to pick > >>>> whichever commit they feel is a good choice. > >>>> > >>>> We didn't really have this issue with svn because there was a single > >>>> commit that announced both implicitly in the addition summary as well > >>>> as explicitly which commit was chosen as the branch point (referencing > >>>> "svn commit: r339434 - stable/12"). > >>>> > >>>> We can of course discover what we care about in the git world by > >>>> clicking on the link to go to cgit and exploring the parent, but this > >>>> is decidedly not always convenient. > >>>> > >>>> I had thought of one solution, but it's not great; adding the parent > >>>> commit hash to the mail when a new ref is pushed. That imposes some > >>>> weird limitations that remove some of the benefit of git, e.g., re@ > >>>> would have to push the branch in the first commit then push any > >>>> follow-up unless we can slap it on 'the first commit in a push that > >>>> created a new ref'. This is kind of silly when they can just prepare > >>>> everything that needs to be done and push it with confidence in a > >>>> single step. > >>>> > >>>> jhb@ pointed out on IRC another possible solution, and I'm wondering > >>>> what the git wg and re@ think... apparently, in the dark ages that > far > >>>> predate me (CVS), we had something like a BP ("Branch Point") tag that > >>>> served the same purpose. > >>>> > >>>> - Is this desirable information for anyone else to have? > >>>> - Would it screw up anything we actively try to do? > >>>> > >>>> I imagine, for example, that re would just create an annotated > >>>> RELENG_13_0_BP tag and push that, which would serve as the > >>>> announcement that this is the commit for reference and perhaps also be > >>>> good bisect targets. While `git merge-base` works well for simply > >>>> matters, if you want to bisect from RELENG_13_0_BP to RELENG_13_1_BP > >>>> it's definitely quicker to conjure up the well-defined tag name than > >>>> `git bisect $(git merge-base releng/13.1 stable/13) $(git merge-base > >>>> releng/13.0 stable/13)` > >>>> > >>> > >>> I do not have any comments on the solutions here, but I will make sure > >>> it is brought up during the next working group call. Admittedly, > >>> I probably should have explicitly stated releng/13.0 was branched from > >>> stable/13, but I suppose part of me just figured it would be obvious > >>> from a workflow perspective. But given I am personally so familiar > with > >>> the workflow in this case, it was a bad assumption on my part, either > >>> intentional or otherwise. > >>> > >>> That said, I will be more thoughtful of this in the future, regardless > >>> of what solution(s) (if any) are implemented. Thank you for pointing > >>> this out. > >> > >> I don't know that we want all-caps tag names in a git world, btw. That > >> was just something we did in CVS (and I do think we had tags like > >> RELENG_2_2_BP and RELENG_3_BP). Part of the reason was that there were > >> no changesets in CVS, so you really had to have a tag for sanity. > >> > >> I do think tags might be nice, e.g. if we had a stable-13-bp tag (or > >> stable-13), then 'git describe --exclude "vendor/*"' on main would > >> show the number of commits since 13 was branched which is more useful > >> than what it shows now. Similarly, on stable/13 'git describe' would > >> now be showing the number of commits since 13.0 was branched by > >> default. I also think there's some merit to Kyle's argument that we > >> can tell users 'git bisect releng-13.0-bp release/13.1' to bisect > >> between releases. I'm sure there's some bikeshedding that can be > >> had about tag names (- vs _, 'stable-13-bp' vs 'stable/13-bp' vs > >> 'bp/stable/13'). > >> > >> In terms of sheer number of tags, I don't think this would add a ton > >> of them (1 additional tag per stable and releng branch), and I would > >> suggest we only start this for 13.x and not do it on older branches. > >> We can always add this retroactively for older branches in the future > >> if we found we really wanted/needed it. > >> > > > > Do we need it? In the git world we can say stable/13..release/13.0 to get > > from wherever on the stable/13 branch it was branched to the tip of the > > branch. But you can also get this with 'git merge-base' as well, which is > > much more generic than dropping arbitrary tags. > > True, though one of Kyle's explicit points was to avoid forcing users > to use merge-base. I think one thing to consider is the command line > we tell users to use for bisecting and what is more friendly for users > to use (who may not be git savvy). Using merge-base is probably fine, but > all of the examples you gave probably look a bit intimidating to a > non-developer user who is less familiar with git. We will probably just > have to make sure we have some good recipes for things like "how to > bisect between releases" because 'git bisect release/13.0 release/13.1' > won't work > It won't work today with svn either. You have to know to go back to stable/13 branch and you'd have to find the branch points for both 13.0 and 13.1, which we don't splat tags down on. You'd have to work that out by hand as well since svn had no bisect command. > It is true that we can always wait to see whether or not there is a need > over time (e.g. how do users on stable@ cope with using stable/13 via > git instead of svn) since tags can be added retroactively. > % git checkout release/13.1 % git bisect start % git bisect bad % git bisect good `git merge-base stable/13 release/13.0` isn't terrible and generalizes well... It isn't exactly bisecting between 13.0 and 13.1, but it's close enough that the delta can be safely ignored (last-minute changes, security advisories and engineering notices are safe enough they shouldn't cause issues)... I think we absolutely need to document these things, of course (as well as my examples, which generally aren't things people would need/want to do except occasionally). I've started the drudgery of getting things converted from md to asciidoc and moving content into the handbook and other places in our tree. I think a lot of the need for a tag will be driven by how good the docs are since the commands aren't super-long... I'd expect the people who aren't git savvy will read our docs and follow them... I'll also note that other projects that have a similar branching structure to ours don't explicitly tag the branch point. So there's not a design pattern from the rest of the open source community we can easily draw upon either. Warner