Date: Fri, 5 Feb 2021 13:36:21 -0700 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Glen Barber <gjb@freebsd.org>, Kyle Evans <kevans@freebsd.org>, freebsd-git <freebsd-git@freebsd.org>, FreeBSD Release Engineering Team <re@freebsd.org> Subject: Re: Branch point/branch point tags Message-ID: <CANCZdfoCXTxe6e5Tipce7wRd03e4HGXe=qLANZNr4Kcc1VwEVQ@mail.gmail.com> In-Reply-To: <CANCZdfr-2fWPP6uf4ALMrm2Q6cx-3xX7_2i4DatbhxSi17ZMwg@mail.gmail.com> References: <CACNAnaGHWgGCPLmiVV_i6E6OydvsAMfLsE3yD_U2WmwjPt6OFg@mail.gmail.com> <20210205181609.GS77557@FreeBSD.org> <ec4cb8ae-7597-e420-05ba-6e10ab0e180c@FreeBSD.org> <CANCZdfr-2fWPP6uf4ALMrm2Q6cx-3xX7_2i4DatbhxSi17ZMwg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 5, 2021 at 1:03 PM Warner Losh <imp@bsdimp.com> wrote:
>
>
> On Fri, Feb 5, 2021 at 11:50 AM John Baldwin <jhb@freebsd.org> 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
> 4c44dbde5491516eba8725dc51d39c1dcc817472
> % git merge-base main freebsd/stable/13
> 679e4cdabdc5a93e5c0d7cdf3fc52202a8de02ef
>
> 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.
>
I forgot to include:
% git rev-list --first-parent --count main..freebsd/stable/13
153
% git rev-list --first-parent --count freebsd/stable/13..freebsd/releng/13.0
2
which gives the 'git describe' info but in a more reliable manner due to
the 'unexpectedly weird to many' way that it counts things.
Warner
> This punts on all the 'what to name it' discussions too, which is an added
> bonus..
>
> Warner
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoCXTxe6e5Tipce7wRd03e4HGXe=qLANZNr4Kcc1VwEVQ>