From owner-freebsd-git@freebsd.org Mon Feb 22 21:10:32 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 D6A8E54E730 for ; Mon, 22 Feb 2021 21:10:32 +0000 (UTC) (envelope-from rene@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DkvwS5nllz4m74; Mon, 22 Feb 2021 21:10:32 +0000 (UTC) (envelope-from rene@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1614028232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wpyqRXh4ozFSx9/ayHAqOlQ72dZonOHgFOfVPdwcI+k=; b=ox/+IqS1zCp/Np7uAXhN25xW09S9sOVqc0Ni0Fn4M6zDNz1GmR7vbeenLhy7+W6F7kMLbx QFZm1dsuZsEEEtbFdeehX4nx6DPlYvVfau4sXH0u+Y8eLuDjmofgFD7p0LupO30aYGpC99 QLHbyMV3axEkwVH5VY4qGF5E8q585HG5S+V7oVkzkpnjPF99aUp6367IJNuJJcZk7nfRw4 7AWuywuuWli6Uk/IwV23iXXcULmGNm6ZhiBgkKlHSdTEaavTRJwvFz5kakdWcsMJrovjJt vjx7WK3XT6mPRviOwMcAH6gNTI6u9/kTvo0dKeEQUl3F3xoMab6BoQwWlvIWAg== Received: by freefall.freebsd.org (Postfix, from userid 1185) id BCFF61AB4F; Mon, 22 Feb 2021 21:10:32 +0000 (UTC) Date: Mon, 22 Feb 2021 21:10:32 +0000 From: Rene Ladan To: Brandon Bergren Cc: John Mehr via freebsd-git Subject: Re: Ports Repocopy Message-ID: <20210222211032.GA21063@freefall.freebsd.org> References: <202102221945.11MJjCiO063445@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1614028232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wpyqRXh4ozFSx9/ayHAqOlQ72dZonOHgFOfVPdwcI+k=; b=A4teTJv4//RpLeqcfIyG4RMO+oHmi6b8I7z9R9vS1ZuF8UzuXMTf/b88Vnx6f4mZ24diBa 3GhGNi6FglT5t3m5P+Z/r3eBG+uIl0zjaDAd7/H6THalVEglbAOKvU6H2imbLPG5gExtkb bSDB624OhJ0j5OX713chRvI/bNqven7KKt1/g3mT9NGxQkraszAD0P2J098nvnx5e2PW4F oBaiD5jcsMLz4rfgNSkat8YfY+JKQitfEXQitLyqQyW90W+ZV+kk0eAb329toYmCvKfdAs 2Hah34BfTvpN1437Ah0JzwqSbzVLcBV/DwUozcy3QW/psDU11ClHe3BwRPHLIA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1614028232; a=rsa-sha256; cv=none; b=wDAiHTyTnq2DDfvOLLt20OYgFMDGLUDtYDug8+C0M1Ai5Nt79p1fXGx+uROqE3bCFhPwDK 2PrfYY4aM+J+vgapGhMTw6hgHWYyCv988okQ8eePmMsLSbwjSzGC3DJmflHM00stutVfrL cTS86iNNnvKDg/6eRTepuo/GC9V63BcF2y9tutR7ZGJtvXXkgcbCHp1zLhGknFo6KuaFsc EXacLiLdBGxGFnr9xcFEvkLBGf05OugivPowNUzu+gZ0cvrcUkx5wCyyyePKnpRV8GNKf1 NrRpMgtdNOPMuur7yiNO/eYTg84Td5FfT03hj/RdfR1n/pVEM1+SrSrOTRTDQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 21:10:32 -0000 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 ` 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. René