From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames) Date: Mon, 12 Dec 2022 01:02:45 +0200 Message-ID: References: <78f97339-2aca-0dbd-4cb4-3532af78a895@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22491"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 To: =?UTF-8?Q?Nicol=C3=A1s?= Ojeda =?UTF-8?Q?B=C3=A4r?= , 55871@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 12 00:03:22 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p4VLt-0005fI-QL for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 00:03:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4VLe-0003c0-Ki; Sun, 11 Dec 2022 18:03:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4VLb-0003bd-0e for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 18:03:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p4VLa-0005cn-L1 for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 18:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4VLa-0004N8-Fv for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 18:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2022 23:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55871 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 55871-submit@debbugs.gnu.org id=B55871.167079977516800 (code B ref 55871); Sun, 11 Dec 2022 23:03:02 +0000 Original-Received: (at 55871) by debbugs.gnu.org; 11 Dec 2022 23:02:55 +0000 Original-Received: from localhost ([127.0.0.1]:48726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4VLT-0004Mu-6I for submit@debbugs.gnu.org; Sun, 11 Dec 2022 18:02:55 -0500 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:34451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4VLR-0004Mk-Fv for 55871@debbugs.gnu.org; Sun, 11 Dec 2022 18:02:54 -0500 Original-Received: by mail-wr1-f54.google.com with SMTP id o5so10405254wrm.1 for <55871@debbugs.gnu.org>; Sun, 11 Dec 2022 15:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=AxeFgi7KOb7Ib4fI0ouKi6iAAdqb2Lf9XXKhCHNdyV4=; b=JmxImLGIyVDKhtNW7dCoV9RU9rcYJJoTzlr1hRsOXZ++6iWQoFio6yjf5JnUOkAFwv G3flJ7utuh044aaFd1bcoYZMJAjv0jSqzvk6/n+6ZNFRia2cUDc4b7ggVI/M3NB24Wmi tx0jlranRqpkS48CVuC6YDunT7f4TOTiSHFHPg0HIXZLE8IvjeYlIeGrHOTo4nbOv+gU ctBCORknDLwer6oAAbd1DJYm+bsVQUBXSO0aBk9qBVrL3MuujQ78t6gO9C+b6fOmKQ0z AnPjjB3/TZz3ufLdVuWEYeC0G7xMJw2i0IddFJBZuqPsn2aebB9YhMJRlEJoDFmYZJx2 GjTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AxeFgi7KOb7Ib4fI0ouKi6iAAdqb2Lf9XXKhCHNdyV4=; b=vvwMMQrHZ/96tFq5eCN0L9PkC/JRhd+UnXoXlygs2CtnAPLW8TBRRXsJu+aJ4P08Dl fEPFfU8zFHZT18RMnzkIH8rf+hUHqQ48afcca3TDZdGddI/8Hg/88FbRYyIp3WFOqVVg RTTCJQ5DWONu2Vo4cHpJjGBfQfKGCjFbgHkz3zy4i5qDUew+phQj1WqGEzX1iCCAc1zX 40H/wYTSlY4fvg5m8GF/A7Zj2eqJ2gMv5lPMcpZmrToJKS8VguiFtWFh6ZcbJYThVhW5 NJJeLPlpVah57JChuNFc3klp6oYkwiZoAZ29auF9mCyZQBTnmR90X0WlsKb4CVTNG65v 5jqg== X-Gm-Message-State: ANoB5pnw9vtYINtPPUba/aTrpYbQZzPTM8cEbANHY5PnjHRMTkRccYcK qw/qGhtrMT8fikePSOOqing= X-Google-Smtp-Source: AA0mqf7ppBsw+I0PwH59x++6D9YfRF08oJ6ag5qAr8eN/u6VB5fHXFhupUGgOxmrLKuK2V2CsWgaXg== X-Received: by 2002:a05:6000:1c8:b0:242:701d:3f76 with SMTP id t8-20020a05600001c800b00242701d3f76mr8502448wrx.66.1670799767469; Sun, 11 Dec 2022 15:02:47 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id o5-20020a5d58c5000000b00241da0e018dsm7183188wrf.29.2022.12.11.15.02.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Dec 2022 15:02:46 -0800 (PST) Content-Language: en-US In-Reply-To: <78f97339-2aca-0dbd-4cb4-3532af78a895@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250661 Archived-At: On 18/08/2022 05:10, Dmitry Gutov wrote: > I experimented with --follow myself in the past, and it is annoying in > that it skips commits, some of which are visible in the log when you > don't use --follow, details here: > https://stackoverflow.com/questions/46487476/git-log-follow-graph-skips-commits > > So I figured the approach in (3) has something to do with it. But it > seems not to be the case. I've tried another idea: to pre-process the file's history and pass all historical file names to 'git log' inside vc-git-print-log. Unfortunately, that delays the appearance of the log significantly. In the Emacs repo that comes down to several seconds, which seems unacceptable. But that would fix both the problems with a/f/d and the bug described in the SO question above. Looking around for how other software deals with it, it seems GitHub has found a satisfactory solution which adds a new UI element with basically zero performance cost. At first it was implemented in a Chrome extension for it (https://github.com/jeffstieler/github-follow-extension), but then added to the core functionality this summer (https://github.blog/changelog/2022-06-06-view-commit-history-across-file-renames-and-moves/). This gif shows the workflow: https://i0.wp.com/user-images.githubusercontent.com/4021812/171795153-4f327a04-eb27-4d46-acb1-73d2e82ce4c5.gif?ssl=1 We should be able to do something similar. Step 1: Drop the '--follow' argument in all cases. Step 2: After the log is finished printing, we detect somehow that the last commit was a rename one. Perhaps using an additional process call, or perhaps by adding some output to the process which we'll hide through font-lock or process filter. When it is a rename, we print a message at the end, saying the file has been renamed. And a button saying e.g. "Print Previous Log", which would print the history for the previous name. That history should also include the missing commits from the SO question. Not sure how to deal with duplicating file names best (like etc/NEWS has been the name of many files in the Emacs repo): either limiting the first revision to start from -- but that keep bring back the missing commit problem, oh well -- or some other way. Can't exactly check what GitHub is doing, because they don't actually provide this for NEWS.24, guess because it was not a straight rename: https://github.com/emacs-mirror/emacs/commits/master/etc/NEWS.24 But git log -M50% -C --stat 5f8947c7007d1d8 -n 1 at least detects it as a copy if not a rename. Guess they didn't adopt the whole follow-renames logic, and we can do better. I don't have any code to show, but it shouldn't require too many changes.