GNU bug report logs - #40725
27.0.91; Tutorial reports false positive key rebindings

Previous Next

Full log

View this message in rfc822 format

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: contovob <at> tcd.ie, Mattias Engdegård <mattiase <at> acm.org>, 40725 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#40725: 27.0.91; Tutorial reports false positive key rebindings
Date: Fri, 24 Apr 2020 21:48:02 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Git handles renames gracefully.
>
> "Gracefully" is in the eyes of the beholder.  It's true the support
> for renames improved in the recent years, but there are still commands
> that either fails or need special invocation methods to work across
> renames.  So it's still a source of inconvenience and occasional
> failure or mistaken conclusions, and I'd like to avoid that if
> possible.

Out of curiosity, would it help if VC turned on these "special
invocation methods"[1] by default?

I ask because there are obvious advantages to renaming: Mattias gave
"multiple good reasons" that are specific to this thread; more
generally, better naming helps discoverability and onboarding, which
Emacs could always use more of.

Of course, if the costs of renaming (in terms of inconvenience for
maintainers) cannot be made low enough, it's not worth lingering on the
benefits.  I'm just wondering if there will come a day where The
Technology™ gets good enough that we can afford renames[2], or if it
will forever remain the "bane" of maintainers.



[1] I am thinking of git-log's --follow option and git-diff's
    --find-rename option; I might be missing other knobs.

[2] Dmitry pointed out bug#39044; I don't know how many other such
    issues are lying around, or if there are some "war stories" people
    can readily recount to show shortcomings in the current handling of
    renames.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.