Branch point/branch point tags

[Glen Barber]

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.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20210205/577560e5/attachment.sig>