From owner-freebsd-git@freebsd.org Wed Dec 2 14:34:04 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 6758C47C375 for ; Wed, 2 Dec 2020 14:34:04 +0000 (UTC) (envelope-from uqs@freebsd.org) 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 4CmM0r1hKKz4rVd for ; Wed, 2 Dec 2020 14:34:04 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3745D47C73C; Wed, 2 Dec 2020 14:34:04 +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 357A847C5E4 for ; Wed, 2 Dec 2020 14:34:04 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (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 (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmM0q47F2z4rFl; Wed, 2 Dec 2020 14:34:03 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 0B2EXlt2003684 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 2 Dec 2020 15:33:47 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Wed, 2 Dec 2020 15:33:47 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Warner Losh Cc: Rene Ladan , Chris Rees , Adam Weinberger , git@freebsd.org, "portmgr@FreeBSD.org" Subject: Re: converting rmport to git Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.1 (2020-11-14) X-Rspamd-Queue-Id: 4CmM0q47F2z4rFl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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: Wed, 02 Dec 2020 14:34:04 -0000 On Tue, 2020-12-01 at 09:36:48 -0700, Warner Losh wrote: >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: >> > 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. Isn't the ports copy or move fixable by doing it in 2 steps? That is, one commit is copying or moving the file without any modification inside the file whatsoever (sic!). This is obviously a bogus state for the ports tree, so a 2nd commit then changes the content of that new file to adjust its name or category or whatever. The good thing about a DVCS is that these 2 commits will obviously be pushed together, atomically, so no one will ever see the broken intermediate state. Unless of course you want to `git bisect` stuff, so it's not a panacea and also brittle as it depends on a human doing the right thing. Cheers Uli