Ports Repocopy

[Brooks Davis]

On Mon, Feb 22, 2021 at 09:10:32PM +0000, Rene Ladan wrote:
> On Mon, Feb 22, 2021 at 02:46:40PM -0600, Brandon Bergren wrote:
> > On Mon, Feb 22, 2021, at 1:45 PM, 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?
> > > 
> > 
> > Renames and copies in git are inferred, not tracked.
> > 
> > About all you can do to make following stuff easier across a copy is to cp -a and immediately commit, before making any changes, so that it shows up in the index with identical file hashes as what it was copied from.
> > 
> > Following a file's history across a copy is dependent on the settings the person looking at the history is using.
> > 
> > It is not enabled by default because it is an extremely expensive operation -- it is O(n^2) where n is the number of files in the tree, plus even then it only works if the original file was modified in the same commit. Otherwise you have to use --find-copies-harder which is an even more expensive option.
> > 
> > If the commit was done by committing an unmodified version first, you can theoretically use `git log --follow -C100% --find-copies-harder <filename>` which should probably be able to do its work without having to compute similarities on all of the objects. But if you have many files with the same contents, I don't really know what the log will look like past that point. I *think* it will just randomly mix history. I haven't tested it though.
> > 
> > I suppose writing a tool that adds metadata about the copy to a git note or something would be the best way to track this stuff...
> 
> Hm, or just write something at the bottom of the commit message, like
> cherry-pick -x does? I remmber that emaste suggested something like this
> in the last git working group meeting.

For simple cases like copying one port or resurrecting one port, I think
the easiest thing to do is to cause the new copy to exist in one commit
(but don't hook it up) and then update it.  E.g., 

resurrection:
git revert --no-commit <hash of commit removing port>
<remove the change to any Makefiles>
git revert --continue (or whatever the equivalent is)
<update the port and hook it to the build>
git add + git commit

copying:
git cp cat/port cat/portng
git commit cat/portng
<update the port and hook it to the build>
git add + git commit

This gives git the best chance to infer the right history by ensuring
identical files are copied.  I think the copying case will work better
than resurrection from a tooling perspective.  Resurrection will likely go
best if ports are deleted in independent commits rather than in one big
one during expiration.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20210301/df3e5762/attachment.sig>