From owner-freebsd-git@freebsd.org Tue Dec 1 16:37:00 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 E8A804ADDBB for ; Tue, 1 Dec 2020 16:37:00 +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 4Clnn84zGXz4Vsq for ; Tue, 1 Dec 2020 16:37:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id AAA9B4ADF09; Tue, 1 Dec 2020 16:37:00 +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 AA6B64ADAE0 for ; Tue, 1 Dec 2020 16:37:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 4Clnn84F9nz4WF1 for ; Tue, 1 Dec 2020 16:37:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id r6so1133803qtm.3 for ; Tue, 01 Dec 2020 08:37:00 -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=sR3Wn9B3Q4KzrnCHaaHFtkv/zTGW6nMKNNy5AK4nJug=; b=aZUtZbyAqE3DLD6NkPzfkZQqoHLLU4x8ZJUbGsi52mGtcNqnUEosINojUYw5oKuQAG ac0IfYFhLEytF3ZfgB3WviYbHpuCingyyYfDLqSkTG6OxcGVtykW7Fxe9T24Py76TThn EfdgUe2MWbGE1FQBS8X4Fpfri00woesQnsJP/Zro2ku35+gKgKP5Q5cblsqYaExx1jXA iadVvwP4xKLNdnFHl8C4+QYQm2NTcF1PL2+xCjQoiJTZo8SrX2jiOFfVDKKBxaX8F3Qm wl7d9cHTocCrYPUUu5rxdPty7fS5VM/hBly06Kqb2xtnocZu3d1QnHm552bx08XZESUQ kxIA== 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=sR3Wn9B3Q4KzrnCHaaHFtkv/zTGW6nMKNNy5AK4nJug=; b=o7WJWXc9wR7hO3MhcNn8mFFKdE+bubGnTTfug2fmlD0FOGkI5aKLAn31kGRC+tp2Mm VWhrKPxJhuYLZDnzzEYz1gIvf0LtjoG2QPxXtn7yZWLhw08fkbLFVbbQW6Gu55DLlkum 9YkBfiNcXyRSGV9LsA104cT2Y+vdFOGXsjrbldVoFndSw2vSolB2BgbKIU8TA+aMvtZa i/w+YvbWcm2M7KgP5dFA1reyRMgpp2Y/szNmaricrzrGqEf6RraEVHswEoai4X6oWBIi MsBIefb5g6UBj1fd0vWLOwxau6w51+fOPvQajR1SOuqx3p4SL9BFhuufWGx3XWDweb32 ro7g== X-Gm-Message-State: AOAM530Y10oYffvOTKr+NHhG3sVwyNi/WgizLoRbkxQkFaV7tPWUeh+/ 3MQ5yecFCz6fsjzzNFRE3CaRLBIZ8q3uuNCfJhhx1A== X-Google-Smtp-Source: ABdhPJycUlVtpfmHoG/0nY6bm7Q+uRW8tQvAYJETDOQvwzGaKvO6iINYT/Hr3Adlk/6YJ2qWLWbR9AMnLGEk3DW+lZw= X-Received: by 2002:ac8:67da:: with SMTP id r26mr3614016qtp.101.1606840619192; Tue, 01 Dec 2020 08:36:59 -0800 (PST) MIME-Version: 1.0 References: <20201129164707.GA31739@freefall.freebsd.org> <14871125-A032-4980-8DB1-0210E34D5A11@FreeBSD.org> <20201130105337.GA42359@freefall.freebsd.org> <7246FB00-655B-4BD4-BC99-B87E4595969C@FreeBSD.org> <20201201095906.GA50345@freefall.freebsd.org> In-Reply-To: <20201201095906.GA50345@freefall.freebsd.org> From: Warner Losh Date: Tue, 1 Dec 2020 09:36:48 -0700 Message-ID: Subject: Re: converting rmport to git To: Rene Ladan Cc: Chris Rees , Adam Weinberger , git@freebsd.org, "portmgr@FreeBSD.org" X-Rspamd-Queue-Id: 4Clnn84F9nz4WF1 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" Content-Transfer-Encoding: quoted-printable 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: Tue, 01 Dec 2020 16:37:01 -0000 On Tue, Dec 1, 2020 at 2:59 AM Rene Ladan wrote: > On Mon, Nov 30, 2020 at 08:19:40PM +0000, Chris Rees wrote: > > > > > > On 30 November 2020 10:53:37 GMT, Rene Ladan wrote: > > >On Sun, Nov 29, 2020 at 11:26:41PM +0000, Chris Rees wrote: > > >> Hey, > > >> > > >> On 29 November 2020 17:12:21 GMT, Adam Weinberger > > >wrote: > > >> >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 hi= t > > >a > > >> >design > > >> >> decision with Tools/scripts/rmport. > > >> >> > > >> >> 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= . > > >> > > > >> >Git uses topic branches for not-clobbering-the-tree purposes, so > > >your > > >> >proposal below seems like the git analogue of an svn sparse 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 > > >> > > > >> >If our users will have to install git from ports or pkg, is there > > >much > > >> >concern that people won't be on a reasonably recent version of git? > > >> > > >> Nah, we can just check the version and complain easily. > > >> > > >> >> 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 > > >> > > > >> >That definitely seems more consistent with the git workflow. Create > > >a > > >> >topic branch, do the thing, merge the branch, push the change. > > >> > > >> > > >> Looks like a great idea. I'm starting to get used to git, but I'm > > >happy if you (Ren=C3=A9) want to push ahead with this, as I'm sure my > > >approach would be dreadful.... > > >> > > >OK, I'll rewrite the script to use the branch workflow. This does > > >assume > > >having an existing clone of the git repository present, but I guess > > >that > > >is a safe assumption if you are a ports committer :) > > > > > >The addport and mfh scripts could use a similar workflow. Speaking of > > >addport, it uses your website to check if a port pre-existed, that > > >website > > >should learn about git too? > > > > Well... I don't think git actually does git cp properly does it? As in= , > doesn't it cleverly work it out for itself? > Git only knows about mv, not cp :( > I also think that git mv is just a convenience for git rm and git add.... > > > > The only reason I wrote the removed ports thing is because we were > losing the link between old and new version when a port was removed and > readded. Is git likely to DTRT without it? > I don't know, perhaps we can search the git history itself. > The typical way I've seen this done is to add the metadata to either the 'bring it back' commit (so like our MFC After: lines), or using the 'notes' feature in some way. The upside to either of these techniques is that you preserve the data. the downside is that neither is known by git log. I've also seen weird merge commits attempted for this since git log knows about them... The only problem is they are sufficiently weird that git log does odd things for everybody across them... I don't anticipate that git will do the right thing w/o help because the ports tree has so many nearly identical files. For simple ports, the Makefile could have been copied from anywhere, likewise some of the pkg* files. Though for simple ones, lost history doesn't lose much that's useful. For complex ones, it likely would do close to the right thing since complex ports, kinda by definition, are different. Though I'd test this notion (because as I'm typing this I find myself making too many mental reservations)... To be honest, though, I think this is an area where some experimentation to understand the alternatives is needed because this use case is relatively rare in the larger open source community. Warner