On Mon, May 10, 2021 at 11:21:43AM +0200, Tijl Coosemans wrote: > On Mon, 10 May 2021 09:30:56 +0200 Mathieu Arnold <m...@freebsd.org> > wrote: > > On Fri, May 07, 2021 at 11:32:48PM +0600, Muhammad Moinur Rahman wrote: > >> What is the preferred way of doing ports repocopy in git? In the hard > >> way I can see moving it into two locations and merging them. But is > >> there any easier way of doing it? > > > > Well, here is what I did when I added lang/perl5.34: > > > > cp -R lang/perl5-devel lang/perl5.34 > > # change stuff > > git add lang/perl5.34 > > git commit > > > > I don't really see any other way to do this, Git has absolutely no clue > > about copies or moves. > > It might still be useful to do the copy and changes as two separate > commits. Even if git doesn't do anything with that, our next vcs might > and reconstructing copy history is faster and less error prone with > unmodified copies.
Well, the next VCS will probably be in more than ten years, and we have no idea what it would be. When that time comes, and unless we migrate to it from subversion up to the point where we switched to git, and migrate to it from git from there, all the previous copies/moves information is already lost. So, I don't think there is a point in making it harder on people. Making a note in the commit message, like, "I copied the files from xxx/yyy" is enough, maybe adding the commit hash if it is a resurrection. But Having two commits to "record" something that git cannot possibly know about is just not interesting, all it will do is add useless commits and blobs to the repository. -- Mathieu Arnold
signature.asc
Description: PGP signature
