From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 071111F54E for ; Fri, 22 Jul 2022 20:11:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236544AbiGVUJU (ORCPT ); Fri, 22 Jul 2022 16:09:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233720AbiGVUJB (ORCPT ); Fri, 22 Jul 2022 16:09:01 -0400 Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20799A8777 for ; Fri, 22 Jul 2022 13:08:58 -0700 (PDT) Received: from host-78-147-187-217.as13285.net ([78.147.187.217] helo=[192.168.1.57]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1oEyxE-0009Te-5z; Fri, 22 Jul 2022 21:08:57 +0100 Message-ID: <6426b5c3-0a09-f641-9876-3534b0abd96d@iee.email> Date: Fri, 22 Jul 2022 21:08:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Feature request: provide a persistent IDs on a commit Content-Language: en-GB To: Hilco Wijbenga , Phillip Susi Cc: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , Stephen Finucane , Git Users References: <220718.86ilnuw8jo.gmgdl@evledraar.gmail.com> <87a692e8vj.fsf@vps.thesusis.net> From: Philip Oakley In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 21/07/2022 19:58, Hilco Wijbenga wrote: > On Thu, Jul 21, 2022 at 9:39 AM Phillip Susi wrote: >> Ævar Arnfjörð Bjarmason writes: >> >>> This has come up a bunch of times. I think that the thing git itself >>> should be doing is to lean into the same notion that we use for tracking >>> renames. I.e. we don't, we analyze history after-the-fact and spot the >>> renames for you. >> I've never been a big fan of that quality of git because it is >> inherently unreliable. > Indeed, which would be fine ... if there were a way to tell Git, "no > this is not a rename" or "hey, you missed this rename" but there > isn't. > > Reading previous messages, it seems like the > after-the-fact-rename-heuristic makes the Git code simpler. That is a > perfectly valid argument for not supporting "explicit" renames but I > have seen several messages from which I inferred that rename handling > was deemed a "solved problem". And _that_, at least in my experience, > is definitely not the case. Part of the rename problem is that there can be many different routes to the same result, and often the route used isn't the one 'specified' by those who wish a complicated rename process to have happened 'their way', plus people forget to record what they actually did. Attempting to capture what happened still results major gaps in the record. It's nice to believe that in software we could perfectly capture the copy/edit/rename processes between revisions, but with humans in the loop it just doesn't work as planned. Hence the value of Git is that it does record faithfully the end points, and allows a moderately standardised way of viewing the perceived rename process. It also removes the external attempts at 'control' of the revision record that bedevil other approaches. Philip