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--