Branch point/branch point tags

Warner Losh imp at
Fri Feb 5 20:03:54 UTC 2021

On Fri, Feb 5, 2021 at 11:50 AM John Baldwin <jhb at> 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
% git merge-base main freebsd/stable/13

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


More information about the freebsd-git mailing list