Date: Mon, 22 Feb 2021 13:30:07 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: Rene Ladan <rene@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-git <freebsd-git@freebsd.org> Subject: Re: Ports Repocopy Message-ID: <202102222130.11MLU7tD032546@slippy.cwsent.com> In-Reply-To: <CANCZdfr7vVcQaNSSBQeUGDxtgKDew2wA%2BOQKgebLeCfyKrPpxg@mail.gmail.com> References: <202102221945.11MJjCiO063445@slippy.cwsent.com> <20210222203500.GA75838@freefall.freebsd.org> <CANCZdfr7vVcQaNSSBQeUGDxtgKDew2wA%2BOQKgebLeCfyKrPpxg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CANCZdfr7vVcQaNSSBQeUGDxtgKDew2wA+OQKgebLeCfyKrPpxg@mail.gmail.c om> , Warner Losh writes: > --000000000000feba3d05bbf2f652 > Content-Type: text/plain; charset="UTF-8" > > 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. 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 <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202102222130.11MLU7tD032546>