From owner-freebsd-git@freebsd.org Tue May 18 17:49:52 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 964FC652BB3 for ; Tue, 18 May 2021 17:49:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 4Fl3Rg6z0Lz3mqX; Tue, 18 May 2021 17:49:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x729.google.com with SMTP id 76so10083410qkn.13; Tue, 18 May 2021 10:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=IGEAw1+MEvcY4icFkNgG8X9BU0gYd2cG+FmRmPh8Rk0=; b=PwGnlOlvPZx6LatTQ+AsShxZb/UQI84btYpHuXVznu8CObYk8tkAnnpN1YJ2Y6AaC9 wQo1V67oceg/bgs6kyC8JuBfohS3rIf5atw6wezapYBJJ4+huR4AWm4DDV8ug7N2rUFn XlZuM6DMF/vP3AXpqZ+9Vmu7v3XFbcPsY0B5LC/VnX/c5ebH3zRX6GxM5FZOoEbhIXvZ lZ6PexhcIkjSdnr26DajOY+Bp4Y5zGJwX/zXKSLxb8hgpY77OiudqYqCOyyzTDSiLx59 tINutCOgd/CI320hH0D+q1CFptf66oxaP3UfWNepnh1rR7pWIVCRlcr8uZ4+E/XCJh5w BVnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=IGEAw1+MEvcY4icFkNgG8X9BU0gYd2cG+FmRmPh8Rk0=; b=k4hr+GAOJRXvfMJih/B385yzBT/5GAYnpoQE1Ln3IuuWxxWe3Ca/kitnGsC4G/J+XC eqKGyb1iIPCLul0OkGLhNCOSnjyLjOAFu/JAywJ9aTShJvtD+c42bfNjyju1B2z4NRLb zmMmD8a4bPb6QGI2vP1ofXolUdMbiSQlN8rLdO68x9pEm4zcqLTKrX0S9fYGH5HeRJhA xhUjRZ8UobNl8TYZUJrG33qtFTts3zk1kiW/ZycAunp4kIQc6OBA1y0uulBCDvKNzT56 97epDdaFkDr2iMJFQD9UWqrEf1K4sEoASJBjiXqeGAa7Tub8qhhA4d/oLo3yikmdhoYs exWQ== X-Gm-Message-State: AOAM532OAK7ofKjJRSNmYYN4iOcjER+Bs2pGcEItgNsyXB++78tNCjsz l8ohYV68W69J+//3dJP791rKw6EG0VhpaA== X-Google-Smtp-Source: ABdhPJxSmvcEBZX3H3pC0vb+fiC2SNamfooLSnnfSsJ5pV9OvZntV11DV9oaX6DjMPA0v/n07tFd3Q== X-Received: by 2002:a37:6388:: with SMTP id x130mr6917881qkb.485.1621360190758; Tue, 18 May 2021 10:49:50 -0700 (PDT) Received: from nuc ([142.126.159.38]) by smtp.gmail.com with ESMTPSA id 75sm13073297qkl.119.2021.05.18.10.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 May 2021 10:49:50 -0700 (PDT) Sender: Mark Johnston Date: Tue, 18 May 2021 13:46:47 -0400 From: Mark Johnston To: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= Cc: freebsd-git@freebsd.org Subject: Re: vendor/illumos merges Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4Fl3Rg6z0Lz3mqX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PwGnlOlv; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::729 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.64 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.948]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::729:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.980]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.99)[0.985]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::729:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::729:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-git] 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: Tue, 18 May 2021 17:49:52 -0000 On Sun, Apr 25, 2021 at 04:02:22PM +0200, Ulrich Spörlein wrote: > On Sat, 2021-04-24 at 11:08:58 -0400, Mark Johnston wrote: > >On Sat, Apr 24, 2021 at 12:44:40PM +0200, Ulrich Spörlein wrote: > >> On Fri, 2021-04-23 at 17:26:33 -0400, Mark Johnston wrote: > >> >Hi, > >> > > >> >Now that FreeBSD uses OpenZFS as the upstream for ZFS, vendor/illumos is > >> >mostly unused. However, we still use illumos as an upstream for CTF > >> >tools and DTrace, though there haven't been any imports in a while. > >> > > >> >illumos has put a lot of work into their CTF toolchain, and I'd like to > >> >import that. There are a couple of snags that I'd appreciate some > >> >guidance on. > >> > > >> >First, I believe I should delete now-unused ZFS code from the vendor > >> >branch and merge the result to main. I did this locally and got an > >> >empty merge, which is what I'd expect. Is there any problem with this? > >> > >> Why would you record this empty merge? If you clean up vendor/foo, just > >> do that but don't merge a no-op back into main (nothing changed, after > >> all). > > > >Ok, I guess there is no reason to merge that change separately. It > >will end up being merged with subsequent imports though. > > > >> >Second, with Subversion we had both vendor/illumos and > >> >vendor-sys/illumos, and now we just have the former, seemingly with > >> >sys/* bits imported from vendor-sys. Some of the upstream commits touch > >> >both userspace and kernel bits, but the merge targets for these in > >> >FreeBSD are different: cddl/contrib/opensolaris vs. > >> >sys/cddl/contrib/opensolaris. How should I merge into main in this > >> >case? I don't really see any options other than to split each offending > >> >upstream commit into two parts, one for userspace and one for the > >> >kernel, and merge them separately. > >> > > >> >If it helps to look at the branch where I staged the upstream commits, > >> >I've pushed it to vendor/illumos2 in https://github.com/markjdb/freebsd > >> >. > >> > >> Can you clarify why the merging of the two might be an issue? Note that > >> unlike subversion, in git there's no "merge a certain subtree" handling, > >> all that is recorded is a tree of some form and then a set of parents or > >> ancestor commits. (git is a content tracker, not really a VCS :) > >> > >> I was under the impression that userland and kernel imports/merges need > >> to happen at the same time anyway, so I assume you would import all the > >> bits under vendor/foo in 1 commit and then merge them in 1 commit into > >> main. Is that not how it goes? > > > >How can I do that with git subtree merge? Suppose an illumos commit > >modifies cmd/dtrace/foo.c (userspace) and uts/common/dtrace/foo.c > >(kernel). That maps to cddl/contrib/opensolaris/cmd/dtrace/foo.c and > >sys/cddl/contrib/opensolaris/uts/common/dtrace/foo.c in FreeBSD, > >respectively. So to do a subtree merge, I need to use distinct prefixes > >depending on whether I'm importing userspace or kernel changes. When > >they are mixed together, it's not clear to me how I can merge at all. > > > >I see that for OpenZFS we keep all code, including userspace code, under > >sys/contrib/openzfs, so it doesn't have this problem. > > I don't think you want a subtree merge, especially as things are > scattered all over the place. Also note that none of this subtree magic > is in any way recorded in the git data, all it does is help you with the > 3-way merges (or whatever). > > So I would do: > - import whatever you need into contrib/foo, commit normally. > - munge /usr/src to have every kernel and userland stuff (not sure what > other merge tools exist, just make sure to copy over file deletions as > well :). You could rsync --del two times with the right source/dest > pairs, or export a diff/patch from step 1 and apply it under the right > prefixes. test, test, test. > - write out this tree to git using: git write-tree > - then commit this using: git commit-tree -m "my message" -p HEAD -p > origin/vendor/illumos > - bump main to point to that hash using git update-ref > - git log --graph and inspect the hell out of this > - git push, then curse that we disallow merge commits and you need to > `git pull --rebase` to advance to the latest published head and that > might mess up your merge commit pretty bad :( > > > Maybe 2x git subtree merge + then rewriting and squashing them into 1 > would work. But I fear it will record 3 parents, not 2 parents. > > Whatever you do, maybe please push to your private Github clone or our > dev repo first and tell us where to look, so we can inspect whether it > looks ok. I followed your suggestions and have what looks like a clean result. Basically I did two subtree merges and committed the result. I pushed it here: https://github.com/markjdb/freebsd/tree/ff/illumos-merge The merge is the second-last commit on that branch. Rebasing the merge is painful, partly because there are some old ZFS commits in the illumos vendor branch which git tries to merge. Rename detection leads to some really weird conflicts as well. I'm not sure how to handle this: there's a lot of room to make mistakes when rebasing, so I would want to be careful and do extra testing before pushing the final merge, but during that window it's likely that I will end up having to rebase again. I should perhaps remove all ZFS bits from the vendor branch, and merge it into main first before importing other stuff. From nobody Wed May 19 12:37:44 2021 X-Original-To: git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 91C4D86BD4C for ; Wed, 19 May 2021 12:37:59 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlXTL5B57z3mdw for ; Wed, 19 May 2021 12:37:55 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5BB9B8D4A129 for ; Wed, 19 May 2021 12:37:48 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9D2C0E708CB for ; Wed, 19 May 2021 12:37:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id LnZP-XhUvWoa for ; Wed, 19 May 2021 12:37:45 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A0907E707AE for ; Wed, 19 May 2021 12:37:45 +0000 (UTC) Date: Wed, 19 May 2021 12:37:44 +0000 (UTC) From: "Bjoern A. Zeeb" To: git@FreeBSD.org Subject: src tools/tools/git/hooks/prepare-commit-msg ? Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4FlXTL5B57z3mdw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[195.201.62.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[git@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[195.201.62.131:from:127.0.2.255]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[git] Hi, before committer's guide (CG) git docs on Warner's github the tags were documented as "Foo-bar:" ineast of the old "Foo bar": ; see: https://github.com/bsdimp/freebsd-git-docs/blob/096afef4a8b9d8964f9edaf3d15e484b1ead83d3/meta.md (with the later fix for Phabricator). It seems tools/tools/git/hooks/prepare-commit-msg in the source tree was never updated to that? I can find a reference to the hook in the ports (not in the src) section "5.2.6.1. Commit message formats" of the CG and the referenced file for ports also was never changed it seems. Did we drop the idea of adding the "-" into the "tags"? I am asking because I kept using them from back then and noticed that I am missing a lot of MFC reminders (though I thought that was adjusted to cope with the '-' as well). So I am trying to sort out the official format before opening the next can. /bz -- Bjoern A. Zeeb r15:7 From nobody Wed May 19 19:04:57 2021 X-Original-To: freebsd-git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9984F624A9A for ; Wed, 19 May 2021 19:05:11 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 4Flj461VrBz3qNH; Wed, 19 May 2021 19:05:09 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mail-wm1-f51.google.com with SMTP id u133so7839320wmg.1; Wed, 19 May 2021 12:05:09 -0700 (PDT) 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=VcVilJajRw8sX2OLpKHpfbJnJ+ag1cTNZyN4U/mSyP4=; b=h93wn2cnePUSYt1uvLMa5dOf3dvEwspitpksACy+tHQWgOn+WK/NTaiJqLijG5WTJA hjmVHDdZuLOHdPuF0OrcvbS2r8/UXliZ/kIb77DWsqqVcI72kRBTq/BB9X+hgMmlKQGW kRA3DQCGed4ulfpSv/CTxnDQ2iXSt3xpPGfpP/MVvwRm8CEVMDHtRtJ6h/7Z5GWQgp2c lrzC0VIza/1OTuz5FxnR4/4ISlBxDeapl9ZrFyQOpe6qHJ3eVewIn2Au74GUaBdzsPux mO+w4YIUrMWQuIBqITF/LnVG5crBtoXZQblidU7TDoBhcqsOLeRTA5C3LXDgjfL1hvf5 RB/Q== X-Gm-Message-State: AOAM531lhwg8A/TP6KcUZLuiR+yahSZQ3iBGkuZITOWfBN3mccF+BLfk CuHX8egLRpNmWUrInQY2O/GfRSozS5zMDJvs5B3z43JA X-Google-Smtp-Source: ABdhPJxyd3Z5NhhCyyRAIJFaAY1eGeFwLIToBp4yifkFqsHVdlQawq+sA+pNDfFo/ZpyyYh51eI0HBGRPLq0cgr57nY= X-Received: by 2002:a1c:98c6:: with SMTP id a189mr655660wme.178.1621451108260; Wed, 19 May 2021 12:05:08 -0700 (PDT) List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Date: Wed, 19 May 2021 21:04:57 +0200 Message-ID: Subject: Re: vendor/illumos merges To: Mark Johnston Cc: freebsd-git@freebsd.org Content-Type: multipart/alternative; boundary="00000000000054214305c2b38120" X-Rspamd-Queue-Id: 4Flj461VrBz3qNH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of uspoerlein@gmail.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=uspoerlein@gmail.com X-Spamd-Result: default: False [-1.47 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_MIXED_CHARSET(0.83)[subject]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.128.51:from]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[209.85.128.51:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.30)[-0.303]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.51:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[uqs@freebsd.org,uspoerlein@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.51:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[uqs@freebsd.org,uspoerlein@gmail.com]; MAILMAN_DEST(0.00)[freebsd-git]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes --00000000000054214305c2b38120 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2021 at 7:49 PM Mark Johnston wrote: > On Sun, Apr 25, 2021 at 04:02:22PM +0200, Ulrich Sp=C3=B6rlein wrote: > > On Sat, 2021-04-24 at 11:08:58 -0400, Mark Johnston wrote: > > >On Sat, Apr 24, 2021 at 12:44:40PM +0200, Ulrich Sp=C3=B6rlein wrote: > > >> On Fri, 2021-04-23 at 17:26:33 -0400, Mark Johnston wrote: > > >> >Hi, > > >> > > > >> >Now that FreeBSD uses OpenZFS as the upstream for ZFS, > vendor/illumos is > > >> >mostly unused. However, we still use illumos as an upstream for CT= F > > >> >tools and DTrace, though there haven't been any imports in a while. > > >> > > > >> >illumos has put a lot of work into their CTF toolchain, and I'd lik= e > to > > >> >import that. There are a couple of snags that I'd appreciate some > > >> >guidance on. > > >> > > > >> >First, I believe I should delete now-unused ZFS code from the vendo= r > > >> >branch and merge the result to main. I did this locally and got an > > >> >empty merge, which is what I'd expect. Is there any problem with > this? > > >> > > >> Why would you record this empty merge? If you clean up vendor/foo, > just > > >> do that but don't merge a no-op back into main (nothing changed, aft= er > > >> all). > > > > > >Ok, I guess there is no reason to merge that change separately. It > > >will end up being merged with subsequent imports though. > > > > > >> >Second, with Subversion we had both vendor/illumos and > > >> >vendor-sys/illumos, and now we just have the former, seemingly with > > >> >sys/* bits imported from vendor-sys. Some of the upstream commits > touch > > >> >both userspace and kernel bits, but the merge targets for these in > > >> >FreeBSD are different: cddl/contrib/opensolaris vs. > > >> >sys/cddl/contrib/opensolaris. How should I merge into main in this > > >> >case? I don't really see any options other than to split each > offending > > >> >upstream commit into two parts, one for userspace and one for the > > >> >kernel, and merge them separately. > > >> > > > >> >If it helps to look at the branch where I staged the upstream > commits, > > >> >I've pushed it to vendor/illumos2 in > https://github.com/markjdb/freebsd > > >> >. > > >> > > >> Can you clarify why the merging of the two might be an issue? Note > that > > >> unlike subversion, in git there's no "merge a certain subtree" > handling, > > >> all that is recorded is a tree of some form and then a set of parent= s > or > > >> ancestor commits. (git is a content tracker, not really a VCS :) > > >> > > >> I was under the impression that userland and kernel imports/merges > need > > >> to happen at the same time anyway, so I assume you would import all > the > > >> bits under vendor/foo in 1 commit and then merge them in 1 commit in= to > > >> main. Is that not how it goes? > > > > > >How can I do that with git subtree merge? Suppose an illumos commit > > >modifies cmd/dtrace/foo.c (userspace) and uts/common/dtrace/foo.c > > >(kernel). That maps to cddl/contrib/opensolaris/cmd/dtrace/foo.c and > > >sys/cddl/contrib/opensolaris/uts/common/dtrace/foo.c in FreeBSD, > > >respectively. So to do a subtree merge, I need to use distinct prefix= es > > >depending on whether I'm importing userspace or kernel changes. When > > >they are mixed together, it's not clear to me how I can merge at all. > > > > > >I see that for OpenZFS we keep all code, including userspace code, und= er > > >sys/contrib/openzfs, so it doesn't have this problem. > > > > I don't think you want a subtree merge, especially as things are > > scattered all over the place. Also note that none of this subtree magic > > is in any way recorded in the git data, all it does is help you with th= e > > 3-way merges (or whatever). > > > > So I would do: > > - import whatever you need into contrib/foo, commit normally. > > - munge /usr/src to have every kernel and userland stuff (not sure what > > other merge tools exist, just make sure to copy over file deletions as > > well :). You could rsync --del two times with the right source/dest > > pairs, or export a diff/patch from step 1 and apply it under the right > > prefixes. test, test, test. > > - write out this tree to git using: git write-tree > > - then commit this using: git commit-tree -m "my message" -p HEAD -p > > origin/vendor/illumos > > - bump main to point to that hash using git update-ref > > - git log --graph and inspect the hell out of this > > - git push, then curse that we disallow merge commits and you need to > > `git pull --rebase` to advance to the latest published head and that > > might mess up your merge commit pretty bad :( > > > > > > Maybe 2x git subtree merge + then rewriting and squashing them into 1 > > would work. But I fear it will record 3 parents, not 2 parents. > > > > Whatever you do, maybe please push to your private Github clone or our > > dev repo first and tell us where to look, so we can inspect whether it > > looks ok. > > I followed your suggestions and have what looks like a clean result. > Basically I did two subtree merges and committed the result. > > I pushed it here: > https://github.com/markjdb/freebsd/tree/ff/illumos-merge > The merge is the second-last commit on that branch. > > Rebasing the merge is painful, partly because there are some old ZFS > commits in the illumos vendor branch which git tries to merge. Rename > detection leads to some really weird conflicts as well. I'm not sure > how to handle this: there's a lot of room to make mistakes when > rebasing, so I would want to be careful and do extra testing before > pushing the final merge, but during that window it's likely that I will > end up having to rebase again. > > I should perhaps remove all ZFS bits from the vendor branch, and merge > it into main first before importing other stuff. > I see only 1 merge commit in there, is that the expected outcome? The output of git show -p --first-parent 23a19903267ee799cbddc35eb3e6f978ac1b4f38 looks mostly sane though, does it look like the changes that you'd like to bring into main? Warner, could you please also have a look? Cheers Uli --00000000000054214305c2b38120 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 18, 2021 at 7:49 PM Mark = Johnston <markj@freebsd.org>= wrote:
On Sun, = Apr 25, 2021 at 04:02:22PM +0200, Ulrich Sp=C3=B6rlein wrote:
> On Sat, 2021-04-24 at 11:08:58 -0400, Mark Johnston wrote:
> >On Sat, Apr 24, 2021 at 12:44:40PM +0200, Ulrich Sp=C3=B6rlein wro= te:
> >> On Fri, 2021-04-23 at 17:26:33 -0400, Mark Johnston wrote: > >> >Hi,
> >> >
> >> >Now that FreeBSD uses OpenZFS as the upstream for ZFS, ve= ndor/illumos is
> >> >mostly unused.=C2=A0 However, we still use illumos as an = upstream for CTF
> >> >tools and DTrace, though there haven't been any impor= ts in a while.
> >> >
> >> >illumos has put a lot of work into their CTF toolchain, a= nd I'd like to
> >> >import that.=C2=A0 There are a couple of snags that I'= ;d appreciate some
> >> >guidance on.
> >> >
> >> >First, I believe I should delete now-unused ZFS code from= the vendor
> >> >branch and merge the result to main.=C2=A0 I did this loc= ally and got an
> >> >empty merge, which is what I'd expect.=C2=A0 Is there= any problem with this?
> >>
> >> Why would you record this empty merge? If you clean up vendor= /foo, just
> >> do that but don't merge a no-op back into main (nothing c= hanged, after
> >> all).
> >
> >Ok, I guess there is no reason to merge that change separately.=C2= =A0 It
> >will end up being merged with subsequent imports though.
> >
> >> >Second, with Subversion we had both vendor/illumos and > >> >vendor-sys/illumos, and now we just have the former, seem= ingly with
> >> >sys/* bits imported from vendor-sys.=C2=A0 Some of the up= stream commits touch
> >> >both userspace and kernel bits, but the merge targets for= these in
> >> >FreeBSD are different: cddl/contrib/opensolaris vs.
> >> >sys/cddl/contrib/opensolaris.=C2=A0 How should I merge in= to main in this
> >> >case?=C2=A0 I don't really see any options other than= to split each offending
> >> >upstream commit into two parts, one for userspace and one= for the
> >> >kernel, and merge them separately.
> >> >
> >> >If it helps to look at the branch where I staged the upst= ream commits,
> >> >I've pushed it to vendor/illumos2 in https:/= /github.com/markjdb/freebsd
> >> >.
> >>
> >> Can you clarify why the merging of the two might be an issue?= Note that
> >> unlike subversion, in git there's no "merge a certai= n subtree" handling,
> >> all that is recorded is a tree of some form and then a set of= parents or
> >> ancestor commits. (git is a content tracker, not really a VCS= :)
> >>
> >> I was under the impression that userland and kernel imports/m= erges need
> >> to happen at the same time anyway, so I assume you would impo= rt all the
> >> bits under vendor/foo in 1 commit and then merge them in 1 co= mmit into
> >> main. Is that not how it goes?
> >
> >How can I do that with git subtree merge?=C2=A0 Suppose an illumos= commit
> >modifies cmd/dtrace/foo.c (userspace) and uts/common/dtrace/foo.c<= br> > >(kernel).=C2=A0 That maps to cddl/contrib/opensolaris/cmd/dtrace/f= oo.c and
> >sys/cddl/contrib/opensolaris/uts/common/dtrace/foo.c in FreeBSD, > >respectively.=C2=A0 So to do a subtree merge, I need to use distin= ct prefixes
> >depending on whether I'm importing userspace or kernel changes= .=C2=A0 When
> >they are mixed together, it's not clear to me how I can merge = at all.
> >
> >I see that for OpenZFS we keep all code, including userspace code,= under
> >sys/contrib/openzfs, so it doesn't have this problem.
>
> I don't think you want a subtree merge, especially as things are <= br> > scattered all over the place. Also note that none of this subtree magi= c
> is in any way recorded in the git data, all it does is help you with t= he
> 3-way merges (or whatever).
>
> So I would do:
> - import whatever you need into contrib/foo, commit normally.
> - munge /usr/src to have every kernel and userland stuff (not sure wha= t
> other merge tools exist, just make sure to copy over file deletions as=
> well :). You could rsync --del two times with the right source/dest > pairs, or export a diff/patch from step 1 and apply it under the right=
> prefixes. test, test, test.
> - write out this tree to git using: git write-tree
> - then commit this using: git commit-tree -m "my message" -p= HEAD -p
> origin/vendor/illumos <tree hash from previous command>
> - bump main to point to that hash using git update-ref
> - git log --graph and inspect the hell out of this
> - git push, then curse that we disallow merge commits and you need to =
> `git pull --rebase` to advance to the latest published head and that <= br> > might mess up your merge commit pretty bad :(
>
>
> Maybe 2x git subtree merge + then rewriting and squashing them into 1 =
> would work. But I fear it will record 3 parents, not 2 parents.
>
> Whatever you do, maybe please push to your private Github clone or our=
> dev repo first and tell us where to look, so we can inspect whether it=
> looks ok.

I followed your suggestions and have what looks like a clean result.
Basically I did two subtree merges and committed the result.

I pushed it here:
https://github.com/markjdb/freebsd/tree/ff/i= llumos-merge
The merge is the second-last commit on that branch.

Rebasing the merge is painful, partly because there are some old ZFS
commits in the illumos vendor branch which git tries to merge.=C2=A0 Rename=
detection leads to some really weird conflicts as well.=C2=A0 I'm not s= ure
how to handle this: there's a lot of room to make mistakes when
rebasing, so I would want to be careful and do extra testing before
pushing the final merge, but during that window it's likely that I will=
end up having to rebase again.

I should perhaps remove all ZFS bits from the vendor branch, and merge
it into main first before importing other stuff.

<= /div>
I see only 1 merge commit in there, is that the expected outcome?=

The output of
git show -p --first-paren= t 23a19903267ee799cbddc35eb3e6f978ac1b4f38
looks mostly sane = though, does it look like the changes that you'd like to bring into mai= n?

Warner, could you please also have a look?

Cheers
Uli
--00000000000054214305c2b38120-- From nobody Wed May 19 19:08:49 2021 X-Original-To: freebsd-git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5497F8B1364 for ; Wed, 19 May 2021 19:08:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 4Flj8M1YFzz3s5m; Wed, 19 May 2021 19:08:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf31.google.com with SMTP id q6so7372730qvb.2; Wed, 19 May 2021 12:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=x389GeFtfw8lj1/IPscnikVYSYj5+b2yIfdXOGCmp0Y=; b=BlxfLbiVJPTkCon+Be7ouE4Ix4+eLm4swE2NDtVIusazUZlSclZbroh1E30ecogW9P dx+Sxg0wUh8RxFAjur64M8fIqfOvWyIFlTbAb75YcCrvIP7fNoo4efRimGaty02/ph2C 53J9Zimn60nwSOuehk1Y8MP7qfY39dL8OT5pRwHFYS2zMiJ4dce+EaC6UHERFgMI2tSY HP+biV9rlIgHk3JIUJU83xsbE3Id20XGVCtIUIbHbn9w46ctB1CNPWrgVLg3AqmhmO7I o7jw1/sHmnaOK06x70VscKfBzCgKFUNCVgT6znN7//iqJT1VuOEfHu9neTOLT+Lru/IB KoLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=x389GeFtfw8lj1/IPscnikVYSYj5+b2yIfdXOGCmp0Y=; b=pcHi+NcmoclLOB/rDHBwZI8ri/ywwxAYNRPDuOCFGvJfDhCcOTUTeR237wW86K0U46 p7eXX1zYNMFRakQ3jDmDaw4Wj20uiKyHoj4wqdnSrWqvUUWbHXTe/emMWIOq6kQQfWpG WD8w3Olhxd46RjCyhem1/Rzi5koubVCkQPTA0aneZJV8XaQR03ri7NC9mno/Axsze83g OdvAB1HLpJpIw6efw0fPrzUWb5KXeB5/LKx6bP7Mssxhvjte8+XkVXvISMnIiZfLaq68 X3mqBmds/faX7Myj/hD6lSCmarVJAaPJynUG5n0fk2Ixo35K6z+uQm3/MGyB4IgoJpY9 vnkw== X-Gm-Message-State: AOAM530mZcZRnOVDNd+5BTZlPFLVmFs1UsAdHBh2zggBo2Qs7LbAp9yA +pSyllyFmupUnE11MkSk/i2DcVOOtSg= X-Google-Smtp-Source: ABdhPJxhTNV45JxL6YQuNcJGjhkyY83Cv+sjQX0VmF4Qjf/HmE4Y1eu3dis9vMQQdjnNyncKSlxOoA== X-Received: by 2002:ad4:5310:: with SMTP id y16mr1049134qvr.39.1621451329912; Wed, 19 May 2021 12:08:49 -0700 (PDT) Received: from nuc ([142.126.156.186]) by smtp.gmail.com with ESMTPSA id d200sm446155qkc.44.2021.05.19.12.08.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 12:08:48 -0700 (PDT) Sender: Mark Johnston Date: Wed, 19 May 2021 15:08:49 -0400 From: Mark Johnston To: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= Cc: freebsd-git@freebsd.org Subject: Re: vendor/illumos merges Message-ID: References: List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4Flj8M1YFzz3s5m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] On Wed, May 19, 2021 at 09:04:57PM +0200, Ulrich Spörlein wrote: > On Tue, May 18, 2021 at 7:49 PM Mark Johnston wrote: > > > On Sun, Apr 25, 2021 at 04:02:22PM +0200, Ulrich Spörlein wrote: > > > On Sat, 2021-04-24 at 11:08:58 -0400, Mark Johnston wrote: > > > >On Sat, Apr 24, 2021 at 12:44:40PM +0200, Ulrich Spörlein wrote: > > > >> On Fri, 2021-04-23 at 17:26:33 -0400, Mark Johnston wrote: > > > >> >Hi, > > > >> > > > > >> >Now that FreeBSD uses OpenZFS as the upstream for ZFS, > > vendor/illumos is > > > >> >mostly unused. However, we still use illumos as an upstream for CTF > > > >> >tools and DTrace, though there haven't been any imports in a while. > > > >> > > > > >> >illumos has put a lot of work into their CTF toolchain, and I'd like > > to > > > >> >import that. There are a couple of snags that I'd appreciate some > > > >> >guidance on. > > > >> > > > > >> >First, I believe I should delete now-unused ZFS code from the vendor > > > >> >branch and merge the result to main. I did this locally and got an > > > >> >empty merge, which is what I'd expect. Is there any problem with > > this? > > > >> > > > >> Why would you record this empty merge? If you clean up vendor/foo, > > just > > > >> do that but don't merge a no-op back into main (nothing changed, after > > > >> all). > > > > > > > >Ok, I guess there is no reason to merge that change separately. It > > > >will end up being merged with subsequent imports though. > > > > > > > >> >Second, with Subversion we had both vendor/illumos and > > > >> >vendor-sys/illumos, and now we just have the former, seemingly with > > > >> >sys/* bits imported from vendor-sys. Some of the upstream commits > > touch > > > >> >both userspace and kernel bits, but the merge targets for these in > > > >> >FreeBSD are different: cddl/contrib/opensolaris vs. > > > >> >sys/cddl/contrib/opensolaris. How should I merge into main in this > > > >> >case? I don't really see any options other than to split each > > offending > > > >> >upstream commit into two parts, one for userspace and one for the > > > >> >kernel, and merge them separately. > > > >> > > > > >> >If it helps to look at the branch where I staged the upstream > > commits, > > > >> >I've pushed it to vendor/illumos2 in > > https://github.com/markjdb/freebsd > > > >> >. > > > >> > > > >> Can you clarify why the merging of the two might be an issue? Note > > that > > > >> unlike subversion, in git there's no "merge a certain subtree" > > handling, > > > >> all that is recorded is a tree of some form and then a set of parents > > or > > > >> ancestor commits. (git is a content tracker, not really a VCS :) > > > >> > > > >> I was under the impression that userland and kernel imports/merges > > need > > > >> to happen at the same time anyway, so I assume you would import all > > the > > > >> bits under vendor/foo in 1 commit and then merge them in 1 commit into > > > >> main. Is that not how it goes? > > > > > > > >How can I do that with git subtree merge? Suppose an illumos commit > > > >modifies cmd/dtrace/foo.c (userspace) and uts/common/dtrace/foo.c > > > >(kernel). That maps to cddl/contrib/opensolaris/cmd/dtrace/foo.c and > > > >sys/cddl/contrib/opensolaris/uts/common/dtrace/foo.c in FreeBSD, > > > >respectively. So to do a subtree merge, I need to use distinct prefixes > > > >depending on whether I'm importing userspace or kernel changes. When > > > >they are mixed together, it's not clear to me how I can merge at all. > > > > > > > >I see that for OpenZFS we keep all code, including userspace code, under > > > >sys/contrib/openzfs, so it doesn't have this problem. > > > > > > I don't think you want a subtree merge, especially as things are > > > scattered all over the place. Also note that none of this subtree magic > > > is in any way recorded in the git data, all it does is help you with the > > > 3-way merges (or whatever). > > > > > > So I would do: > > > - import whatever you need into contrib/foo, commit normally. > > > - munge /usr/src to have every kernel and userland stuff (not sure what > > > other merge tools exist, just make sure to copy over file deletions as > > > well :). You could rsync --del two times with the right source/dest > > > pairs, or export a diff/patch from step 1 and apply it under the right > > > prefixes. test, test, test. > > > - write out this tree to git using: git write-tree > > > - then commit this using: git commit-tree -m "my message" -p HEAD -p > > > origin/vendor/illumos > > > - bump main to point to that hash using git update-ref > > > - git log --graph and inspect the hell out of this > > > - git push, then curse that we disallow merge commits and you need to > > > `git pull --rebase` to advance to the latest published head and that > > > might mess up your merge commit pretty bad :( > > > > > > > > > Maybe 2x git subtree merge + then rewriting and squashing them into 1 > > > would work. But I fear it will record 3 parents, not 2 parents. > > > > > > Whatever you do, maybe please push to your private Github clone or our > > > dev repo first and tell us where to look, so we can inspect whether it > > > looks ok. > > > > I followed your suggestions and have what looks like a clean result. > > Basically I did two subtree merges and committed the result. > > > > I pushed it here: > > https://github.com/markjdb/freebsd/tree/ff/illumos-merge > > The merge is the second-last commit on that branch. > > > > Rebasing the merge is painful, partly because there are some old ZFS > > commits in the illumos vendor branch which git tries to merge. Rename > > detection leads to some really weird conflicts as well. I'm not sure > > how to handle this: there's a lot of room to make mistakes when > > rebasing, so I would want to be careful and do extra testing before > > pushing the final merge, but during that window it's likely that I will > > end up having to rebase again. > > > > I should perhaps remove all ZFS bits from the vendor branch, and merge > > it into main first before importing other stuff. > > > > I see only 1 merge commit in there, is that the expected outcome? Yes. I should probably do this as two separate merge commits as I suggested above, but I wanted to know if I had done anything incorrectly in this attempt before spending more time on it. The branch isn't ready to merge yet in any case, there are some upstream bugs to squash. > The output of > git show -p --first-parent 23a19903267ee799cbddc35eb3e6f978ac1b4f38 > looks mostly sane though, does it look like the changes that you'd like to > bring into main? Yes, that's correct. > Warner, could you please also have a look? > > Cheers > Uli From nobody Wed May 19 20:43:26 2021 X-Original-To: freebsd-git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 98DB0623FF2 for ; Wed, 19 May 2021 20:43:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FllFc37f3z3j2J for ; Wed, 19 May 2021 20:43:32 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D15C48D4A129 for ; Wed, 19 May 2021 20:43:29 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9CFECE708CB for ; Wed, 19 May 2021 20:43:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id XPO2sbz7GiHZ for ; Wed, 19 May 2021 20:43:27 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:a526:473:bb5b:712]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5934EE707AE for ; Wed, 19 May 2021 20:43:27 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-git@freebsd.org Subject: src tools/tools/git/hooks/prepare-commit-msg ? Date: Wed, 19 May 2021 20:43:26 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <020E2624-7CF1-4277-9440-12E25F7DF865@lists.zabbadoz.net> References: List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4FllFc37f3z3j2J X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-2.29 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[195.201.62.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[195.201.62.131:from:127.0.2.255]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-git] Hi, (sorry in case this is a duplicate; not sure where git@ went; couldn=E2=80= =99t = see the original in the archives) before committer's guide (CG) git docs on Warner's github the tags were documented as "Foo-bar:" instead of the old "Foo bar": ; see: https://github.com/bsdimp/freebsd-git-docs/blob/096afef4a8b9d8964f9edaf3d= 15e484b1ead83d3/meta.md (with the later fix for Phabricator). It seems tools/tools/git/hooks/prepare-commit-msg in the source tree was never updated to that? I can find a reference to the hook in the ports (not in the src) section "5.2.6.1. Commit message formats" of the CG and the referenced file for ports also was also not changed it seems. Did we drop the idea of adding the "-" into the "tags"? I am asking because I kept using them from back then and noticed that I am missing a lot of MFC reminders (though I thought that was adjusted to cope with the '-' as well). So I am trying to sort out the official format before opening the next can. /bz From nobody Thu May 20 23:20:09 2021 X-Original-To: git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4620C8B4977 for ; Thu, 20 May 2021 23:20:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 4FmQh53NyXz4R9s for ; Thu, 20 May 2021 23:20:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x735.google.com with SMTP id 76so17980474qkn.13 for ; Thu, 20 May 2021 16:20:21 -0700 (PDT) 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=/2bWzFAo+jcLfA5g80N/DFQE0QWjUs81jcjWt7H7N/g=; b=2NwcwsQEO/pkpgaiCJpBNV0Coqj7ZlHIDiYMZtDu6qqOCODit6a7QHLSFX6yMcRIe8 /SwhOuZJYS/FXKRN0Vhh6DpNJoVZiP/I5n4jG1kdQVWaMq5DnDvwylu+nzF6FSRyLeKn MzRUHvLBA13AgSwU0X6tq5Ti9IpsNUSXe/5wBKuTPfrquVjLz7KqKSabqpLL+MFHaBpM gSoGxhrDpoL9wfTBmKQpcduiHlOPMjFZ611qPjTUaLQwQiBvldVHXPvm5GwajJmb2nZi 8utnr0uzbB2le4jjSnetgRBEUr+hG3pxIbwdozpvKzWtozr63VjtiCaaLpuLR/TS5um6 VE5Q== 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=/2bWzFAo+jcLfA5g80N/DFQE0QWjUs81jcjWt7H7N/g=; b=FYeCMBriBOCd6i/kboMyItW8IfGVzpe9H5bsJtLkqhbN+QGJeo/0x3fNyV6hG+6v5R zk5dcntkvYZ5OaSSr0sQGdkgZrpROrhdXtN7eA3R/07zIiDfI2DUwCT7vvlNrOXMDqmq OG9GftSPTHKp8FGLy8ZNH+tUhQY8Xhlm5aLDucKxh3PNcviPrRZt3Mw3p5GmJXKY+wMH gozAjxt/9utp0I3zfLzbZ7eqfISvqwEJ5hFHrGsCo5iC8sMZz8C/WDwyMuTlg6wtChCk bi8Gk8nAbwoBQDb5lpuCMGEQ58kJEk/PgI6wCCfXJ2AcHVVgUtvag56O26zz/7z41hG9 mDPw== X-Gm-Message-State: AOAM533P4F++e1X74jYo5rb159JnqmDEfbQETqC71tuJnQKLJ0n75J+3 Lz7/ubrjQ62mHoX/XmPa3ufU6ZlQK4RnjiBh51M4Y2YZJCw= X-Google-Smtp-Source: ABdhPJxivbdp2w0lZ6Glm1xex3YJV6X/GPVENoAMfk7g51DoIjq7QIcz2L1lMv8x/rTNE9bstvlZUTkSNIp1VAvgB4k= X-Received: by 2002:a37:7685:: with SMTP id r127mr8137737qkc.359.1621552820641; Thu, 20 May 2021 16:20:20 -0700 (PDT) List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 20 May 2021 17:20:09 -0600 Message-ID: Subject: Re: src tools/tools/git/hooks/prepare-commit-msg ? To: "Bjoern A. Zeeb" Cc: git@freebsd.org Content-Type: multipart/alternative; boundary="000000000000dbf6e405c2cb2f19" X-Rspamd-Queue-Id: 4FmQh53NyXz4R9s X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=2NwcwsQE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::735) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.95 / 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(-0.95)[-0.952]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[git@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::735:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::735:from]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::735:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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:~]; SUBJECT_ENDS_QUESTION(1.00)[]; 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)[git]; RCVD_COUNT_TWO(0.00)[2] --000000000000dbf6e405c2cb2f19 Content-Type: text/plain; charset="UTF-8" Hi Bjoern, Sorry to take a little to get back to you... I was on travel and got behind... On Wed, May 19, 2021 at 6:38 AM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > Hi, > > before committer's guide (CG) git docs on Warner's github the tags were > documented as "Foo-bar:" ineast of the old "Foo bar": ; see: > > https://github.com/bsdimp/freebsd-git-docs/blob/096afef4a8b9d8964f9edaf3d15e484b1ead83d3/meta.md > (with the later fix for Phabricator). > > It seems tools/tools/git/hooks/prepare-commit-msg in the source tree > was never updated to that? > > I can find a reference to the hook in the ports (not in the src) section > "5.2.6.1. Commit message formats" of the CG and the referenced file > for ports also was never changed it seems. > > Did we drop the idea of adding the "-" into the "tags"? > > > I am asking because I kept using them from back then and noticed that > I am missing a lot of MFC reminders (though I thought that was > adjusted to cope with the '-' as well). So I am trying to sort out > the official format before opening the next can. > I think that you should omit them, and if we still document them like that we should change it. The git group tried to promulgate the change, but it has had poor uptake. Either that, or we need to make the mfc stuff work again... Though given the numbers of people that have used the '-' versions appears to be low, I think we'll need to relaunch in the future instead. Warner > /bz > > -- > Bjoern A. Zeeb r15:7 > > --000000000000dbf6e405c2cb2f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bjoern,

Sorry to ta= ke a little to get back to you... I was on travel and got behind...

On= Wed, May 19, 2021 at 6:38 AM Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:
Hi,

before committer's guide (CG) git docs on Warner's github the tags = were
documented as "Foo-bar:" ineast of the old "Foo bar":= =C2=A0 ; see:
http= s://github.com/bsdimp/freebsd-git-docs/blob/096afef4a8b9d8964f9edaf3d15e484= b1ead83d3/meta.md
(with the later fix for Phabricator).

It seems tools/tools/git/hooks/prepare-commit-msg in the source tree
was never updated to that?

I can find a reference to the hook in the ports (not in the src) section "5.2.6.1. Commit message formats" of the CG and the referenced fi= le
for ports also was never changed it seems.

Did we drop the idea of adding the "-" into the "tags"?=


I am asking because I kept using them from back then and noticed that
I am missing a lot of MFC reminders (though I thought that was
adjusted to cope with the '-' as well).=C2=A0 So I am trying to sor= t out
the official format before opening the next can.

<= /div>
I think that you should omit them, and if we still document them = like that
we should change it. The git group tried to promulgate = the change, but
it has had poor uptake.

= Either that, or we need to make the mfc stuff work again... Though given th= e
numbers of people that have used the '-' versions appea= rs to be low, I think
we'll need to relaunch in the future in= stead.

Warner
=C2=A0
/bz

--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7

--000000000000dbf6e405c2cb2f19-- From nobody Sun May 23 13:17:32 2021 X-Original-To: git@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 601599ECAD4 for ; Sun, 23 May 2021 13:17:36 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::4]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fp19C6GzKz4X5Z for ; Sun, 23 May 2021 13:17:35 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by fc.opsec.eu with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1lknz2-000JMP-Sm for git@freebsd.org; Sun, 23 May 2021 15:17:32 +0200 Date: Sun, 23 May 2021 15:17:32 +0200 From: Kurt Jaeger To: git@freebsd.org Subject: commit to gitrepo-dev ends up in gitrepo.FreeBSD.org ? Message-ID: References: <202105231312.14NDCcOm011888@gitrepo.freebsd.org> List-Id: Discussion of git use in the FreeBSD project List-Archive: https://lists.freebsd.org/archives/freebsd-git List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-git@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202105231312.14NDCcOm011888@gitrepo.freebsd.org> X-Rspamd-Queue-Id: 4Fp19C6GzKz4X5Z X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE] Hi! This is *really* strange. I've tried to test-commit to the test repo using git push git@gitrepo-dev.FreeBSD.org:ports.git and it ended up in the production repo somehow ? fc$ git push git@gitrepo-dev.FreeBSD.org:ports.git Enumerating objects: 13, done. Counting objects: 100% (13/13), done. Delta compression using up to 32 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 775 bytes | 775.00 KiB/s, done. Any ideas how that happened ? > The branch main has been updated by pi: > > URL: https://cgit.FreeBSD.org/ports/commit/?id=037d21f4ad085c17f2f1511461cd80c125564fc2 > > commit 037d21f4ad085c17f2f1511461cd80c125564fc2 > Author: Kurt Jaeger > AuthorDate: 2021-05-23 13:10:48 +0000 > Commit: Kurt Jaeger > CommitDate: 2021-05-23 13:12:25 +0000 > > net/openbgpd6: update 6.8 -> 6.9 > > Changes: https://marc.info/?l=openbgpd-users&m=161977120713468&w=2 > --- > net/openbgpd6/Makefile | 2 +- > net/openbgpd6/distinfo | 6 +++--- > net/openbgpd6/files/patch-src_bgpd_bgpd.h | 23 ----------------------- > net/openbgpd6/files/patch-src_bgpd_rde.c | 15 --------------- > net/openbgpd6/files/patch-src_bgpd_session.c | 18 ------------------ > net/openbgpd6/files/patch-src_bgpd_session.h | 20 -------------------- > 6 files changed, 4 insertions(+), 80 deletions(-) > > diff --git a/net/openbgpd6/Makefile b/net/openbgpd6/Makefile > index caf404ad03a1..19c49e5ac094 100644 > --- a/net/openbgpd6/Makefile > +++ b/net/openbgpd6/Makefile > @@ -1,5 +1,5 @@ > PORTNAME= openbgpd > -PORTVERSION= 6.8p0 > +PORTVERSION= 6.9p0 > CATEGORIES= net > MASTER_SITES= OPENBSD/OpenBGPD > PKGNAMESUFFIX= 6 > diff --git a/net/openbgpd6/distinfo b/net/openbgpd6/distinfo > index 55f85e71f623..33a80f613768 100644 > --- a/net/openbgpd6/distinfo > +++ b/net/openbgpd6/distinfo > @@ -1,3 +1,3 @@ > -TIMESTAMP = 1603267757 > -SHA256 (openbgpd-6.8p0.tar.gz) = 61487aed98071d9e975e9c38d1bfa0731dd7e55623f655372c318e665d928ff8 > -SIZE (openbgpd-6.8p0.tar.gz) = 701164 > +TIMESTAMP = 1620376440 > +SHA256 (openbgpd-6.9p0.tar.gz) = b4a4a5cc240abeb7004594238523471bd1942a0786d1634a2d79c15da85c60bb > +SIZE (openbgpd-6.9p0.tar.gz) = 719173 > diff --git a/net/openbgpd6/files/patch-src_bgpd_bgpd.h b/net/openbgpd6/files/patch-src_bgpd_bgpd.h > deleted file mode 100644 > index 14df54585928..000000000000 > --- a/net/openbgpd6/files/patch-src_bgpd_bgpd.h > +++ /dev/null > @@ -1,23 +0,0 @@ > ---- src/bgpd/bgpd.h.orig 2020-05-19 09:24:33 UTC > -+++ src/bgpd/bgpd.h > -@@ -130,7 +130,8 @@ enum bgpd_process { > - PROC_MAIN, > - PROC_SE, > - PROC_RDE > --} bgpd_process; > -+}; > -+extern enum bgpd_process bgpd_process; > - > - enum reconf_action { > - RECONF_NONE, > -@@ -532,6 +533,10 @@ enum imsg_type { > - IMSG_XON, > - IMSG_XOFF > - }; > -+ > -+extern struct imsgbuf *ibuf_se; > -+extern struct imsgbuf *ibuf_rde; > -+extern struct imsgbuf *ibuf_main; > - > - struct demote_msg { > - char demote_group[IFNAMSIZ]; > diff --git a/net/openbgpd6/files/patch-src_bgpd_rde.c b/net/openbgpd6/files/patch-src_bgpd_rde.c > deleted file mode 100644 > index e8204a8b1661..000000000000 > --- a/net/openbgpd6/files/patch-src_bgpd_rde.c > +++ /dev/null > @@ -1,15 +0,0 @@ > ---- src/bgpd/rde.c.orig 2020-05-04 14:45:09 UTC > -+++ src/bgpd/rde.c > -@@ -99,11 +99,9 @@ void rde_shutdown(void); > - int ovs_match(struct prefix *, u_int32_t); > - > - volatile sig_atomic_t rde_quit = 0; > --struct bgpd_config *conf, *nconf; > -+static struct bgpd_config *conf, *nconf; > - struct filter_head *out_rules, *out_rules_tmp; > --struct imsgbuf *ibuf_se; > - struct imsgbuf *ibuf_se_ctl; > --struct imsgbuf *ibuf_main; > - struct rde_memstats rdemem; > - int softreconfig; > - > diff --git a/net/openbgpd6/files/patch-src_bgpd_session.c b/net/openbgpd6/files/patch-src_bgpd_session.c > deleted file mode 100644 > index fbb2ecf5b0c4..000000000000 > --- a/net/openbgpd6/files/patch-src_bgpd_session.c > +++ /dev/null > @@ -1,18 +0,0 @@ > ---- src/bgpd/session.c.orig 2020-05-19 09:24:33 UTC > -+++ src/bgpd/session.c > -@@ -100,13 +100,13 @@ void session_template_clone(struct peer *, struct so > - u_int32_t, u_int32_t); > - int session_match_mask(struct peer *, struct bgpd_addr *); > - > --struct bgpd_config *conf, *nconf; > -+static struct bgpd_config *conf, *nconf; > -+struct ctl_conns ctl_conns; > - struct bgpd_sysdep sysdep; > - volatile sig_atomic_t session_quit; > - int pending_reconf; > - int csock = -1, rcsock = -1; > - u_int peer_cnt; > --struct imsgbuf *ibuf_rde; > - struct imsgbuf *ibuf_rde_ctl; > - struct imsgbuf *ibuf_main; > - > diff --git a/net/openbgpd6/files/patch-src_bgpd_session.h b/net/openbgpd6/files/patch-src_bgpd_session.h > deleted file mode 100644 > index 9fbb480caf01..000000000000 > --- a/net/openbgpd6/files/patch-src_bgpd_session.h > +++ /dev/null > @@ -1,20 +0,0 @@ > ---- src/bgpd/session.h.orig 2020-05-18 19:17:41 UTC > -+++ src/bgpd/session.h > -@@ -18,6 +18,7 @@ > - > - #include > - #include > -+#include > - #include > - > - #define MAX_BACKLOG 5 > -@@ -146,7 +147,8 @@ struct ctl_conn { > - int terminate; > - }; > - > --TAILQ_HEAD(ctl_conns, ctl_conn) ctl_conns; > -+TAILQ_HEAD(ctl_conns, ctl_conn); > -+extern struct ctl_conns ctl_conns; > - > - struct peer_stats { > - unsigned long long msg_rcvd_open; -- pi@FreeBSD.org +49 171 3101372 Now what ?