From owner-freebsd-git@freebsd.org Fri Feb 5 18:03:06 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 5B6B854DF45 for ; Fri, 5 Feb 2021 18:03:06 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXNZ226y2z3rCy; Fri, 5 Feb 2021 18:03:06 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 3B98C25B06; Fri, 5 Feb 2021 18:03:06 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f171.google.com with SMTP id n15so7760025qkh.8; Fri, 05 Feb 2021 10:03:06 -0800 (PST) X-Gm-Message-State: AOAM530cVz98NS8gHJzcJM9Oo2gaKE0PAv+m4lhoTck56+478D2Xnkri l45IqwB8fC48Vvg3wELY0jMwKM9pVcuXEnw6MQU= X-Google-Smtp-Source: ABdhPJycsAJ06NiRYU4lf03GNS7u64nP4FE+d4GeYLW7Mjbp+Jwa1Zwjtu034JIyVIUxVcRVZezr1t2801Kkkq3Yygs= X-Received: by 2002:a37:745:: with SMTP id 66mr5995477qkh.120.1612548185585; Fri, 05 Feb 2021 10:03:05 -0800 (PST) MIME-Version: 1.0 From: Kyle Evans Date: Fri, 5 Feb 2021 12:02:52 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Branch point/branch point tags To: freebsd-git Cc: FreeBSD Release Engineering Team , John Baldwin Content-Type: text/plain; charset="UTF-8" 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 18:03:06 -0000 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