Date: Fri, 5 Feb 2021 18:16:09 +0000 From: Glen Barber <gjb@freebsd.org> To: Kyle Evans <kevans@freebsd.org> Cc: freebsd-git <freebsd-git@freebsd.org>, FreeBSD Release Engineering Team <re@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: Branch point/branch point tags Message-ID: <20210205181609.GS77557@FreeBSD.org> In-Reply-To: <CACNAnaGHWgGCPLmiVV_i6E6OydvsAMfLsE3yD_U2WmwjPt6OFg@mail.gmail.com> References: <CACNAnaGHWgGCPLmiVV_i6E6OydvsAMfLsE3yD_U2WmwjPt6OFg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210205181609.GS77557>