Date: Mon, 22 Feb 2021 13:51:13 -0700 From: Warner Losh <imp@bsdimp.com> To: Rene Ladan <rene@freebsd.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-git <freebsd-git@freebsd.org> Subject: Re: Ports Repocopy Message-ID: <CANCZdfr7vVcQaNSSBQeUGDxtgKDew2wA%2BOQKgebLeCfyKrPpxg@mail.gmail.com> In-Reply-To: <20210222203500.GA75838@freefall.freebsd.org> References: <202102221945.11MJjCiO063445@slippy.cwsent.com> <20210222203500.GA75838@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 22, 2021 at 1:35 PM Rene Ladan <rene@freebsd.org> 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. 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. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr7vVcQaNSSBQeUGDxtgKDew2wA%2BOQKgebLeCfyKrPpxg>