From owner-freebsd-git@freebsd.org Sun Nov 29 18:26:29 2020 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 013A54A9CDC for ; Sun, 29 Nov 2020 18:26:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4CkcJN40ZWz3GYJ for ; Sun, 29 Nov 2020 18:26:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 876F54A9CDB; Sun, 29 Nov 2020 18:26:28 +0000 (UTC) Delivered-To: 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 872CA4A9EA6 for ; Sun, 29 Nov 2020 18:26:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 4CkcJN3BjQz3Gf9 for ; Sun, 29 Nov 2020 18:26:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x732.google.com with SMTP id h20so8962374qkk.4 for ; Sun, 29 Nov 2020 10:26:28 -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=yDOYbG0YzYI5N44FSVQ4mALSzJp5FQ416wM3B0J1TKE=; b=cMQSho68dDKyZu6dehV4myKo+5XNh8Xx35hNuSvyE23RgfBjJj8WCLxA9s0F7Tm55U nO3lz7eIoYLjycvoF9XU/5v3FeWlekvNWr7Khf+/4GUSD36UuHwdYfVGb88tgcGZttMa IYbF4Xj6EQ7mlviVDJtLKTBqOKiumSi06K48IvE4NKcZkNYxDjMlFMfflU3BBrUCvLJx b86RisvrhKt1HO1YFLghtEWFVCfdfhFYh8syjQxVptbZa00oYr70GwDtjpdRkr87Vmzm SaV9iUT0A3lH54YlxJY4lbUfbyPiBMvDYlaJ+mu7C0Z579SHjPpXVmpqseqCLRE/9euW sbxA== 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=yDOYbG0YzYI5N44FSVQ4mALSzJp5FQ416wM3B0J1TKE=; b=Be+sL16aHE7UuKOSn7YQKw7+nlBn9H/ddpwwlQKpS8T4aBDwjPcLz24M9v4VOBHF8p rSm+gXT8K231Uucu2Mv/+ImB+l8/JZ2Eeei0qaV+N+WuQnfDu698o0QKJaST/WAgq3WW xKNVQ7RlkdOX3PCz9YOCwz24ayeNfIl20W3nXML5gEgtFS4DWJDLZ9b+mF3sgJh2ZRde 7nvezvVWBNzw8OLcyfZ0q4DYlGCxNOJ1agO2N4nhqAarLLNJwHpfJhx4TbgEgy7RSOOw kMOmahI4BNz0WcWvCeSXVGRG7UKCWfTD0SeWQSGe47acRVxpbva2jgNoqyPHRKK9Yy+4 BzRA== X-Gm-Message-State: AOAM531wbdgWtOELvXB1KnoqbRcOAzYdLVm8/uZkl7F6sFi3KVeyNZ18 FAiF2pcJipf+7lHRXna5iDhC8nvfbGNBYjAnRskpBA== X-Google-Smtp-Source: ABdhPJwP/Fq3iRWlV2TMNKaJvj21LNeyRqyC1u9FJT8V0E0s+gg5FBPzBd5IjRqglJANWPdBk8cRbRDg+Gc74UFaYtk= X-Received: by 2002:ae9:f311:: with SMTP id p17mr19305689qkg.206.1606674387435; Sun, 29 Nov 2020 10:26:27 -0800 (PST) MIME-Version: 1.0 References: <20201129164707.GA31739@freefall.freebsd.org> In-Reply-To: <20201129164707.GA31739@freefall.freebsd.org> From: Warner Losh Date: Sun, 29 Nov 2020 11:26:16 -0700 Message-ID: Subject: Re: converting rmport to git To: Rene Ladan Cc: Chris Rees , git@freebsd.org, Ports Management Team X-Rspamd-Queue-Id: 4CkcJN3BjQz3Gf9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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: Sun, 29 Nov 2020 18:26:29 -0000 On Sun, Nov 29, 2020 at 9:47 AM Rene Ladan wrote: > Hello, > > I started converting some scripts in the port tree to git, and hit a design > decision with Tools/scripts/rmport. > Thanks Rene! > In the current SVN world it checks out a sparse copy of the tree to work on > (just LEGAL, MOVED, category/Makefile and the port directory itself) and > commits from that copy. This has the advantage of not clobbering an > existing > work tree and indeed does not need a pre-existing checkout at all. > There's two approaches for this in the git world. First would be worktrees. These are checkouts of the repo on different branches. It's not sparse, but it's not terrible all things considered. It would most closely replicate what you're trying to do, though at the cost of disk space. There's ways to do partial checkouts, but I've not had good luck with them. The second is to assume everybody is using branches in their main tree and can move to a new temporary branch at any time (eg have the tool do nothing in a dirty tree). > I could try to replicate this with git, but it seems like partial checkouts > (not to be confused with shallow checkouts) are a bit of an afterthought > [1] > and need reasonably recent versions of the git binary and protocol. An > alternative would be to just create a temporary branch on an existing > checkout, say rmport-$USER-$EPOCH, do the removal work there, merge that > branch to main, remove the temporary branch and push the new main. This > feels > less cryptic to me. It might also allow for better handling of merge > conflicts > with MOVED in case that file gets updated by someone else and you are in > the > middle of a big removal (say Python 2.7). Currently such conflicts crash > the > script (no work is lost because the temporary checkout is left alone in > that > case). > That's not a bad idea. branches are cheap in git. they let you fully test that you've not broken things, if you want, and can be rebased if there's a mid-air collision while all this is in progress... > What do you think? It looks like we can use a similar solution to the > addport > and perhaps mfh scripts. > > [1] > https://unix.stackexchange.com/questions/233327/is-it-possible-to-clone-only-part-of-a-git-project I think we'll want to have MFC/MFH scripts. One of the open items is the exact form these will take so we can take an accurate census of commits that could be merged. There's issues all over the place here that become less troublesome if the MFC/MFH commit message is decorated in a standardized way (or if standardized notes are used). It's unclear what to do here and I suspect we'll have at least a short period of chaos on the MFC front when viewed in the rear view mirror of whatever grows up to take its place. git can do some of this today w/o help, but only if we cherry-pick w/o modification. And that's unreasonable: we have to tweak MFCs all the time, and there's a proud history in at least src of collapsing several MFCs. I'm afraid I've not looked at the ports world to know if these things are the same or not, but I suspect at least an occasional tweak is needed for MFHs. tl;dr: branch based solutions are likely the ticket here. Warner