From owner-freebsd-git@freebsd.org Mon Feb 22 21:30:14 2021 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 D446754FC60 for ; Mon, 22 Feb 2021 21:30:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DkwM95YwDz4p7f; Mon, 22 Feb 2021 21:30:13 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id EImPlvV4NeHr9EImRlzumQ; Mon, 22 Feb 2021 14:30:11 -0700 X-Authority-Analysis: v=2.4 cv=Yq/K+6UX c=1 sm=1 tr=0 ts=60342264 a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=qa6Q16uM49sA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=R-PVL-mpIl3oI1DEKSMA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 57A2C618; Mon, 22 Feb 2021 13:30:08 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 11MLU7tD032546; Mon, 22 Feb 2021 13:30:07 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202102222130.11MLU7tD032546@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Rene Ladan , Cy Schubert , freebsd-git Subject: Re: Ports Repocopy In-reply-to: References: <202102221945.11MJjCiO063445@slippy.cwsent.com> <20210222203500.GA75838@freefall.freebsd.org> Comments: In-reply-to Warner Losh message dated "Mon, 22 Feb 2021 13:51:13 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Feb 2021 13:30:07 -0800 X-CMAE-Envelope: MS4xfD2epQeRC6Ay5gKaee6KD5U25GJ6OdKKZSdcze7hKU0dYFrS7OxjIhZH2qz1dvgi/X16NIK49Ocyt+Su1EkMK02SpPO3mGTcGUJPcJkc7q2oEHQWsxGH LbSIoUq7EzJgcy0RvScBROyi3enH9BRunZVbElD0+i3dEHIsMnKJy3MEu4JovNjfSbR0szHW4A3QwWt6IXBASC2WY9I8dUqGMyi5oifOXuOTd3QZ5foSJVLQ QY7AX5L0GbsOxXf2r9cyhw== X-Rspamd-Queue-Id: 4DkwM95YwDz4p7f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.70 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.59.134.12:from]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[64.59.134.12:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[64.59.134.12:from:127.0.2.255]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.134.12:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-git] 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: Mon, 22 Feb 2021 21:30:15 -0000 In message , Warner Losh writes: > --000000000000feba3d05bbf2f652 > Content-Type: text/plain; charset="UTF-8" > > On Mon, Feb 22, 2021 at 1:35 PM Rene Ladan wrote: > > > On Mon, Feb 22, 2021 at 11:45:12AM -0800, Cy Schubert wrote: > > > When ports switches to GIT, given that there is no GIT equivalent to svn > > > copy will repocopy become a thing of the past? Will we live with this or > > > will there be some kind of procedure ports committers must follow to > > > approximate a repocopy? > > > > > There is indeed no "git cp", only "git mv", so unless I'm mistaken > > repocopies > > will be a past thing. It might be possible to (credits to portmgr): > > - create a branch, > > - copy/move the files and commit the copy/moves without any changes, > > - change the stuff, > > - commit, > > - merge into the main branch. > > > > Similar for resurrecting a port: > > - create a branch from before the port was removed, > > - change stuff, > > - commit, > > - merge into the main branch (using something like "git merge -s their" so > > that the resurrection branch overwrites the removal) > > > > But this would warrant a new script if it turns out to be feasible. I have > > not > > tried this yet. > > > > There's two additional lines of attack on this that have been discussed. > > The radical one is to create a vendor branch per port (or maybe related set > of ports). This would be updated and then merged to main as the port > evolves. It then becomes easy to delete a port and bring it back since > you'd just re-merge from the vendor branch. This would take a lot of time > and effort to get right today, though, but might be useful for 'big' or > 'important' sets of ports. But you can still cd category && git diff $HASH2 $HASH1 . | git apply to resurrect the port. This assumes the category had no intervening commits between $HASH1 and $HASH1 or one would need to put the diff into a file, edit, and apply. The history is gone but you have what once was. Answering the question how important the history is will guide us to the answer. > > The second idea is to be explicit in the commit message about where things > were copied from, or what hash was used to resurrect a port so the history > could be followed if need be without introducing a lot of loops into the > ports tree which will only cause problems in time. This is like the branch > idea above, but would optimize for 'ease of use' while still preserving > enough data to reconstruct things in the event that git's guessing code > goes awry. In this scenario, you'd want scripts to add these 'markers' in a > consistent way. This makes the most sense. Though I feel history is important, a vendor branch adds complexity and complexity which leads to brokenness and dysfunction. Simpler is better. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.