From owner-freebsd-git@freebsd.org Mon Feb 22 20:47:01 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9C27354DE62 for ; Mon, 22 Feb 2021 20:47:01 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DkvPK3qQlz4kyv for ; Mon, 22 Feb 2021 20:47:01 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bdragon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7520A27054 for ; Mon, 22 Feb 2021 20:47:01 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 1624F27C0054 for ; Mon, 22 Feb 2021 15:47:00 -0500 (EST) Received: from imap38 ([10.202.2.88]) by compute3.internal (MEProxy); Mon, 22 Feb 2021 15:47:01 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeefgddugedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdluddtmdenucfjughrpefofgggkfgjfhffhffvufgtsehttdertder redtnecuhfhrohhmpedfuehrrghnughonhcuuegvrhhgrhgvnhdfuceosggurhgrghhonh eshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnhepteetleffuddvtddtuedv hfefheejvddvgfdvkedvfeethfegkedvkeelveeuvddunecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsggurhgrghhonhdomhgvshhmthhprghu thhhphgvrhhsohhnrghlihhthidquddtgedvfeehkeeigedqudekuddtkeehuddqsggurh grghhonheppefhrhgvvgeuufffrdhorhhgsehimhgrphdrtggt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7FAD6CA005D; Mon, 22 Feb 2021 15:47:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: <202102221945.11MJjCiO063445@slippy.cwsent.com> References: <202102221945.11MJjCiO063445@slippy.cwsent.com> Date: Mon, 22 Feb 2021 14:46:40 -0600 From: "Brandon Bergren" To: "John Mehr via freebsd-git" Subject: Re: Ports Repocopy Content-Type: text/plain X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 20:47:01 -0000 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 ` 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... -- Brandon Bergren bdragon@FreeBSD.org