From nobody Sun Dec 04 01:50:00 2022 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 4NPqPR6jKJz4k2lX for ; Sun, 4 Dec 2022 01:50:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPqPR4Pb1z3wlj; Sun, 4 Dec 2022 01:50:03 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; none Received: from odin.corp.delphij.net (unknown [IPv6:2001:470:48ca:5:c85f:30e6:be8a:bedb]) by anubis.delphij.net (Postfix) with ESMTPSA id 17C9A3116C; Sat, 3 Dec 2022 17:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1670118602; x=1670133002; bh=88GPJuAj8zWW7egRg8niJLtPW2OhKCi2JAtoH6ui+/A=; h=Date:Reply-To:To:Cc:References:From:Subject:In-Reply-To; b=GBkkhSHgjzKqUu0+d0KMSigbMa42Zv/6z6Iqa1ar1RvBfYWSPFwFx6sZ18m7cvYfn iPTZg+WAjrWbCZn7+61srKJqWDnTd7jhsqqRqU08FOEoj6wnLRPiDvClIycBocxKr0 Y5s8bdQrJad/i7g9qVNeYthcyF7wmUXRhCdGEoPOFPRFcDmMvDrUkgmzAOnd7VrpUr Oms1DotsUQ0Awim2tWHDPPKWiUf7PpYYIUyqndwoZ6fZ1ssSUNj2Uf6lHvbft59DIN TiynntNAsBYjE+cOOOvpmQBNAvgFiuF/uTT3Ns3AXIEDMpn2BN2r4eZzB+FoJVhVVj HXqon7t5DNG9Q== Message-ID: <303e6bdd-6a9d-ff92-023b-f4f5093797c0@delphij.net> Date: Sat, 3 Dec 2022 17:50:00 -0800 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 User-Agent: Thunderbird Reply-To: d@delphij.net Content-Language: en-US To: Nuno Teixeira , Warner Losh Cc: d@delphij.net, freebsd-git@freebsd.org References: From: Xin Li Subject: Re: git-switch(1) then git-pull(1) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4NPqPR4Pb1z3wlj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 2022-12-03 10:15 AM, Nuno Teixeira wrote: > Really nice. > > I'm thinking on 3 trees for ports: > > - main (push) > - 2022Qn (cherry-pick, push) > - test (push to main when testing done) > > $ git clone https://git.freebsd.org/ports > ports/main > $ cd ports/main > $ git worktree add ../2022Q4 -b 2022Q4 origin/2022Q4 > $ git worktree add ../test -b main origin/main The third step would fail, because you have checked out main on ports/main. You would want to do this instead: $ git worktree add ../test -b test origin/main > My question is how do I push a commit from 'test' to 'main'? You can do: $ git push origin test:main -n (which will tell the SHA1s and you can inspect with git log; remove -n once satisfactory, or git pull --rebase as needed) > This sugestion is because I can have several ports in testing fase on > 'test' branch and choose a specific commit to push to 'main' (local > branch) and then do a final push. In this case I'd create multiple branches (to the extent that changes can be isolated in a self-containing manner), and have one branch for testing. So the setup would roughly be: you have B1, B2, B3 working on 3 different stuff which almost don't touch each other. Conceptually, you can consider origin/main as a working branch used by someone else, too. Now you want to test the stuff, e.g. with poudriere, or some integrated test of src/, you would create a new branch T for that, like: (first time) $ git worktree add ../testspace -b test origin/main $ cd ../testspace (blow away everything and reset to a known vanilla state) $ cd ../testspace $ git reset --hard origin/main # Reset branch to origin/main Then: $ git merge B1 $ git merge B2 $ git merge B3 Now you have all your work merged into the test space, do whatever tests you want. When the result is satisfactory, perform a 'git rebase origin/main' and squash commits if needed. Assuming you saw some changes would be needed for B2, you would make the changes in B2's worktree, and redo the merge in 'testspace' with: $ git merge B2 Or let's say origin/main moved, you can do: $ git fetch origin $ git merge origin/main and continue to work. If for whatever reason you feel B2 is not yet ready for prime time, do a reset and merge just B1 and B3: $ cd ../testspace $ git reset --hard origin/main # Reset branch to origin/main $ git merge B1 $ git merge B3 Finally: $ git rebase origin/main then T would be what you would be pushing. The benefit of this approach is that you don't really need to rebase often on your work branch (they will make the history harder to understand) and you got to choose when to do that, or just omit one branch at push time, etc., so it's very flexible when working on something really big. The downside is slightly more 'git merge' work: usually they can be done automatically by git, however. > > Does this makes sense? > > > > > > > Warner Losh > escreveu no dia > sábado, 3/12/2022 à(s) 16:16: > > > > On Sat, Dec 3, 2022 at 8:59 AM Nuno Teixeira > wrote: > > Hello, > > $ git clone https://git.freebsd.org/ports > ports/main > $ cd ports/main > $ git worktree add ../2022Q4 -b 2022Q4 origin/2022Q4 > > > So we will have ports/{main,2022Q4} and cd to main or 2022Q4 > according if commit is to main or quarterly? > > I will try this soon because swithing from branches is not the > best way (but I used it for about 1 year without problems). > > > I do this for my src commits. I have 3 trees: 'head', 'stable-13' > and 'stable-12'. I have a lot of branches off of head > for work in progress that I switch between all the time to refine, > finish  and land them. For especially large projects > I'll have a separate work tree, but usually the changes are small > enough that this works fine. I have a script that > rebases everything once and a while to keep my branches in sync. For > stable-12 I have a stable/12 branch locally > that mirrors upstream. I also have a stable/mfc12 branche that I > 'insta-MFC' changes that I commit to head that need > time to cook before being pushed. I do this so I don't lose things. > I then rebase the stable/mfc12 onto stable/12 and push > when the time comes (doing the rebase dance as needed). > > Warner > > > > -- > Nuno Teixeira > FreeBSD Committer (ports)