Ports Repocopy

[Cy Schubert]

In message <CANCZdfr7vVcQaNSSBQeUGDxtgKDew2wA+OQKgebLeCfyKrPpxg at 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 at 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 at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy at nwtime.org>    Web:  https://nwtime.org

	The need of the many outweighs the greed of the few.