From nobody Wed Mar 6 00:37:07 2024 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 4TqD605TTjz5DljV for ; Wed, 6 Mar 2024 00:37:12 +0000 (UTC) (envelope-from bz@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 4TqD603DSNz41SR; Wed, 6 Mar 2024 00:37:12 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709685432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qa1lgLGI5cQi+1PFp/d472NqufgI33g2MFKKCEG+YbU=; b=DOJk3VflcbJNTb+X4lJLZQwUOwN1tzN0K8ts6U2u/C8ni9cUXRC5YPlu9tWfT36K95/of1 hjKqXi+MH7lmbae/PinRDzoU3k7tg4LTa4jPrg7GfbZak/JWg3S6HmZkNNKUb7yDTBfv8b ZTjlZbNvcHoPzbrbjorP4KIk7rWfNRVy8Z/xmr2vuEJIO7U9mjLo0xsjYfja4faRwYLoib M7OpRIxrJKLM+iYTTeiSxCsWAt6t+tH1WEmvI6UA4cseXswUf7xHIkts7UR2fKepOsA/Ov fvEP/ADgnM4pXrIXK373PGR1UevfioFOTyDPM5PqofcqKdD1Nq84IOBnzR9GnQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1709685432; a=rsa-sha256; cv=none; b=idaFvzl3ZQbXyIyga7+dw9co3eRwGItPOmHJ1Iiei9EYgfV/Jz6o5ILicHol3Y2Ft3Uy9V ZRuwa0OrbEX5NL8iXU6W8taXZ8VTe5dKgB9LCe/kIDupBIOh3RUj1ieDHEd6tWdYm6WfUy WCJsQ+RE1rcowRNEle5eOwhewHE6c+2FzpjfBq3QHH9hmrBbhH3I/0CdxLRb+CECuRzRyq bvIjGnIR6IsRvN2QKxnidbmnAQMi7KFk8jxL68hBfVoSrj6gteln/meq+/Vh5NqZNrlMhY ttwujxbsE7RLWMSCgnGPwQgoIAE5qQR8fFI1TCCBBoa/Qdy0Vm0OeqS+PUvlyA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709685432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qa1lgLGI5cQi+1PFp/d472NqufgI33g2MFKKCEG+YbU=; b=eHQ1XVxNfH+o/+Fyfn38SGbvbzPsvGW25VFTcmf35vb1t54X1WO4/kIOlrgEUb1VVufGHd 4azL9UGQab8IZlrFN0XdVy7EG3CWm4GksTlN4qu3xa1l21adcypP33V2FapeAPG8HrK6Zj 26H0t9aiXB4frnvYJi5QsZIZazXsaaPdR/chO4OJvCBzPiMJ/AoY++4xY2t8ewdlMDcM1o HbwXUAf928713zlJ7x2btCfoXuxiHq6PnDAQ9shPkjrcD5Z0W0m/o/C2KoWpio8InrPE78 VQPRy3uYadmLdi9k5DljLyJlkdfZWVh6F7oJSmiDU3pz2FR2/WDloLhP44Bfsw== Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TqD601RStz1Kt5; Wed, 6 Mar 2024 00:37:12 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D36158D4A212; Wed, 6 Mar 2024 00:37:09 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id EFCBE2D029D8; Wed, 6 Mar 2024 00:37:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id SmhjcYxkQeaW; Wed, 6 Mar 2024 00:37:08 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F210E2D029D2; Wed, 6 Mar 2024 00:37:07 +0000 (UTC) Date: Wed, 6 Mar 2024 00:37:07 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: freebsd-git@freebsd.org Subject: Re: vendor imports beyond the committers guide? In-Reply-To: Message-ID: <5pps4nrs-or51-9018-sqp4-7q69s4780r61@serrofq.bet> References: 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: multipart/mixed; boundary="1098556516-150881356-1709685428=:2366" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-150881356-1709685428=:2366 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 5 Mar 2024, Warner Losh wrote: > On Tue, Mar 5, 2024 at 2:46 PM Bjoern A. Zeeb wrote: > >> Hi, >> >> there's the edge case when we already have code in contrib which was >> previously directly committed and now should come out of a vendor >> branch. >> >> (1) how does one properly seed that case? >> > > Was it direct committed to contrib? Or somewhere else? If you are moving it > to contrib, just follow the process in the handbook + delete the old code > in the > same commit as you merge the vendor branch in (so the old history will be > available more often)... > > If it was direct committed to contrib, then it's a vendor import + subtree > merge > + maybe fixups for FreeBSD. Vendor merges are just a convenience so that > future vendor events are constrained... > > These details likely need to be documented, but what's the details here that > you need to do? I may want to track the (unchanged) versions of the LinuxKPI based wifi drivers in sys/contrib/dev so we can more easily diff against the latest upstream import and ship changes back etc. >> (2) given I couldn't see that mentioned either anywhere, for local >> changes, they only live in main and stable/ but vendor doesn't have them >> so in case of conflict they'll show up with the merge from vendor to >> main and need to be resolved then? >> > > stable branches don't care about vendor branches (except in some rare cares > that almost certainly won't pop up here). You are just merging changes in > main, > via cherry-picking, into stable. Right and local changes are in main and in case of conflict show up during the merge from vendor to main and get resolved during that merge like merge conflicts? Sorry, may sound too stupid question but I never worked with vendor branches in cvs/svn/or git before. -- Bjoern A. Zeeb r15:7 --1098556516-150881356-1709685428=:2366--