From owner-freebsd-git@freebsd.org Fri Feb 5 20:36:38 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08991529C8F for ; Fri, 5 Feb 2021 20:36:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXRz60dZwz4WXV for ; Fri, 5 Feb 2021 20:36:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2d.google.com with SMTP id j13so4097823qvu.10 for ; Fri, 05 Feb 2021 12:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSul3M6ftFTnC5IyfH3p0yUVSFjJUV+aW0pHw1HYyx4=; b=y86vjnyJte7HTWXKBo/can0hBYO+WvkqzbCDhWMYd3XTp57HfRa+rsuUPlOLVY4YV4 AMriPILEUxxm1id8Ih+w9WBIBa3+pnPM3xJd0mCNCVHYruPNCzIGSnlkZgTHrAVWAcDa kTzJclGN2bAZAlycwZkYV0rLHHomfwtuEk5U0w5M7vh0pLLmWMUc9Enjgp4SMr1s9icn 8bC9yfBgupemic+EgZgfeeSWhlHS9AXByRhF/H2+tj4ozbtfEl0L60ddyLEpMvrhwVqh MTyxbvP8tWICzAIya3Lo9WC15Pw78fJ8OlX7W1VtV8BHa1Pi+CAE2iNqFDCwpQaIfAto 2FGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cSul3M6ftFTnC5IyfH3p0yUVSFjJUV+aW0pHw1HYyx4=; b=UqhAeVYd9YBzxWoRvBwa5JdtnlMRBsq0K03LKdbb6Qz1/71g8R9QMvqzYx6utjJr8U JyCZdKh4o8y25BkO9fJGz6k94wGvWZNUsy0KVmpde61w/b7AbQP/tX5LlRYQg73NQ2SG MnNegeZS5m2U6MifK+EH2pqPuL98KDg2j7UCD1Z2enXhHupBit7RB9HbHeQywja0vQVq 98m7cXO4mGFaeG1ydGN8+CvG6gVTIPoNIi9p9j2hUL7xQr1Q9oUaevX0cWZN7kSENxFS WC5eRXEOUXPovDCvkX2IGaCPTrFMXEEIlRtRIp0O/V/pmqGUEe9Cebbj304rNg1H8ntL 7tCQ== X-Gm-Message-State: AOAM532GaPsT8X7F5tGYYs+gYvwW6bjKtjf3tBw/21i9/I56hx9flYrw YuLFMIrUxZPlLrXpMrYLr6fEVHVIMcS2Bl/SxLk9gg== X-Google-Smtp-Source: ABdhPJz8WAOauvwLh/hGwGDW6hSopW47dS6WrrtqOCqtIgyOTx65p7ek8rL8Vw6KPJoyNOllY9nxgoAek4dPPlC62J0= X-Received: by 2002:a0c:abce:: with SMTP id k14mr6276235qvb.23.1612557392022; Fri, 05 Feb 2021 12:36:32 -0800 (PST) MIME-Version: 1.0 References: <20210205181609.GS77557@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Fri, 5 Feb 2021 13:36:21 -0700 Message-ID: Subject: Re: Branch point/branch point tags To: John Baldwin Cc: Glen Barber , Kyle Evans , freebsd-git , FreeBSD Release Engineering Team X-Rspamd-Queue-Id: 4DXRz60dZwz4WXV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=y86vjnyJ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f2d:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2d:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f2d:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-git]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:36:38 -0000 On Fri, Feb 5, 2021 at 1:03 PM Warner Losh wrote: > > > On Fri, Feb 5, 2021 at 11:50 AM John Baldwin 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 >