Date: Fri, 5 Feb 2021 12:02:52 -0600 From: Kyle Evans <kevans@freebsd.org> To: freebsd-git <freebsd-git@freebsd.org> Cc: FreeBSD Release Engineering Team <re@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Branch point/branch point tags Message-ID: <CACNAnaGHWgGCPLmiVV_i6E6OydvsAMfLsE3yD_U2WmwjPt6OFg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaGHWgGCPLmiVV_i6E6OydvsAMfLsE3yD_U2WmwjPt6OFg>