Date: Mon, 1 Mar 2021 23:56:18 +0000 From: Brooks Davis <brooks@freebsd.org> To: Rene Ladan <rene@freebsd.org> Cc: Brandon Bergren <bdragon@freebsd.org>, John Mehr via freebsd-git <freebsd-git@freebsd.org> Subject: Re: Ports Repocopy Message-ID: <20210301235618.GD50170@spindle.one-eyed-alien.net> In-Reply-To: <20210222211032.GA21063@freefall.freebsd.org> References: <202102221945.11MJjCiO063445@slippy.cwsent.com> <e3d39a6b-eaf8-4f13-bd7d-28363ae5a7dd@www.fastmail.com> <20210222211032.GA21063@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJgPX8iAAoJEKzQXbSebgfAGFoH/0S/nvbjHjOL9bv3NWl5v/vI Yafx3E+5+AhCR9UK7+vIqa696+ZAqac4GW919kNaLjmPU6gTWrtwnHanY9meomc4 IC8Z+C0pDE4Un1OKu4SEJGUJgzDBYdM+sGZW8x1TL4u6pzXRvw3R7xFXTgmCn3e3 8182nfPacb8kekag7mKShTx0NQPUUyc6Z5QN/G1iZj+qmbgIuTuwvdYjdF8ma370 BmvJVtP17s2GsQVA6E55WAGd+GUdUL/JyzqeQKkafQAqkrIUxJDsg+0xzJB/kGkZ Gt0OvF5pZqWLvh4NnoP4E8X3j9IRUM+LI8bWzb3zkg1Q/hwpW91O0a9dPpEUYkM= =8UQj -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210301235618.GD50170>