GNU bug report logs -
#43117
[PATCH] Add .git-blame-ignore-revs file
Previous Next
Reported by: Brian Leung <leungbk <at> mailfence.com>
Date: Sun, 30 Aug 2020 17:47:01 UTC
Severity: normal
Tags: patch, wontfix
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43117 in the body.
You can then email your comments to 43117 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 30 Aug 2020 17:47:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Brian Leung <leungbk <at> mailfence.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 30 Aug 2020 17:47:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I made some style changes to em-hist.el and registered that commit in the new .git-blame-ignore-revs file to preserve blame data of other commits. The single-clause if statements frequently throw me off, so I think it's worth removing them now that there's a way to do so without ruining git blame sessions.
I signed an FSF copyright assignment about a year ago when I submitted something to the Emacs package Ivy. Attached are the files they sent me confirming successful registration. If I need to send something else instead, please let me know.
Thanks,
Brian
--
Sent with https://mailfence.com
Secure and private email
[0001-eshell-em-hist-Style-and-indentation-cleanup.patch (text/x-diff, attachment)]
[0002-Add-.git-blame-ignore-revs.patch (text/x-diff, attachment)]
[Hsieh.pdf.asc (text/plain, attachment)]
[Leung.pdf (application/pdf, attachment)]
[Leung.pdf.asc (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 31 Aug 2020 10:17:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 43117 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 30 Aug 2020 19:46:31 +0200 (CEST), Brian Leung via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:
Brian> I made some style changes to em-hist.el and registered that commit in
Brian> the new .git-blame-ignore-revs file to preserve blame data of other
Brian> commits. The single-clause if statements frequently throw me off, so I
Brian> think it's worth removing them now that there's a way to do so without
Brian> ruining git blame sessions.
Brian> I signed an FSF copyright assignment about a year ago when I submitted
Brian> something to the Emacs package Ivy. Attached are the files they sent
Brian> me confirming successful registration. If I need to send something
Brian> else instead, please let me know.
You've configured emacs to replace TAB with SPC. Please donʼt do that,
it makes it very hard to figure out what you've actually changed.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 31 Aug 2020 20:12:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 43117 <at> debbugs.gnu.org (full text, mbox):
On 31.08.2020 13:16, Robert Pluim wrote:
> You've configured emacs to replace TAB with SPC.
That's what our .dir-locals.el does, doesn't it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 31 Aug 2020 20:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43117 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 31 Aug 2020 23:11:37 +0300, Dmitry Gutov <dgutov <at> yandex.ru> said:
Dmitry> On 31.08.2020 13:16, Robert Pluim wrote:
>> You've configured emacs to replace TAB with SPC.
Dmitry> That's what our .dir-locals.el does, doesn't it?
Only for lines that you change. The patch has wholesale TAB->SPC
replacement for lines which haven't otherwise been modified.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 31 Aug 2020 20:47:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 43117 <at> debbugs.gnu.org (full text, mbox):
On 31.08.2020 23:34, Robert Pluim wrote:
> Dmitry> On 31.08.2020 13:16, Robert Pluim wrote:
> >> You've configured emacs to replace TAB with SPC.
>
> Dmitry> That's what our .dir-locals.el does, doesn't it?
>
> Only for lines that you change. The patch has wholesale TAB->SPC
> replacement for lines which haven't otherwise been modified.
Right.
In that case, we should probably clarify that we don't usually
whitespace-only changes far from the code that's being changes.
Do we accept reindentation patches, though? Ones where the effective
indentation does change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 31 Aug 2020 20:58:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 43117 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 31 Aug 2020 23:45:55 +0300, Dmitry Gutov <dgutov <at> yandex.ru> said:
Dmitry> On 31.08.2020 23:34, Robert Pluim wrote:
Dmitry> On 31.08.2020 13:16, Robert Pluim wrote:
>> >> You've configured emacs to replace TAB with SPC.
Dmitry> That's what our .dir-locals.el does, doesn't it?
>> Only for lines that you change. The patch has wholesale TAB->SPC
>> replacement for lines which haven't otherwise been modified.
Dmitry> Right.
Dmitry> In that case, we should probably clarify that we don't usually
Dmitry> whitespace-only changes far from the code that's being changes.
Dmitry> Do we accept reindentation patches, though? Ones where the effective
Dmitry> indentation does change.
Didnʼt we just have this thread? :-)
Pure re-indentation patches I thought were not acceptable unless
accompanied by an actual code change near the re-indented lines.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 31 Aug 2020 21:04:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 43117 <at> debbugs.gnu.org (full text, mbox):
On 31.08.2020 23:57, Robert Pluim wrote:
> Dmitry> Do we accept reindentation patches, though? Ones where the effective
> Dmitry> indentation does change.
>
> Didnʼt we just have this thread? :-)
I might have missed it. :-(
> Pure re-indentation patches I thought were not acceptable unless
> accompanied by an actual code change near the re-indented lines.
Okay.
Brian, could you re-submit patches without extra re-indentation?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 13 Sep 2020 00:43:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 43117 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, please see attached. Right now there are no extraneous whitespace changes, and the only changes I've made change if -> when in the eshell files.
> Pure re-indentation patches I thought were not acceptable unless
> accompanied by an actual code change near the re-indented lines.
With a .git-blame-ignore file of some sort, shouldn't this not be a hindrance?
> ----------------------------------------
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Sent: Mon Aug 31 23:03:23 CEST 2020
> To: Robert Pluim <rpluim <at> gmail.com>
> Cc: Brian Leung <leungbk <at> mailfence.com>, <43117 <at> debbugs.gnu.org>
> Subject: Re: bug#43117: [PATCH] Add .git-blame-ignore-revs file
>
>
> On 31.08.2020 23:57, Robert Pluim wrote:
>
> > Dmitry> Do we accept reindentation patches, though? Ones where the effective
> > Dmitry> indentation does change.
> >
> > Didnʼt we just have this thread? :-)
>
> I might have missed it. :-(
>
> > Pure re-indentation patches I thought were not acceptable unless
> > accompanied by an actual code change near the re-indented lines.
>
> Okay.
>
> Brian, could you re-submit patches without extra re-indentation?
--
Sent with https://mailfence.com
Secure and private email
[0001-eshell-Replace-single-clause-if-statements-with-when.patch (text/x-diff, attachment)]
[0002-Add-.git-blame-ignore-revs.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 13 Sep 2020 14:08:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> Cc: 43117 <at> debbugs.gnu.org
> Date: Sun, 13 Sep 2020 02:42:23 +0200 (CEST)
> From: Brian Leung via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> OK, please see attached. Right now there are no extraneous whitespace changes, and the only changes I've made change if -> when in the eshell files.
> [...]
> Subject: [PATCH 1/2] eshell: Replace single-clause if statements with whens
I'm not sure I understand the rationale: why would we want to replace
all 'if's with 'when's? Was that discussed, here or elsewhere? if so,
could someone point me to that discussion?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 13 Sep 2020 17:07:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure I understand the rationale: why would we want to replace
> all 'if's with 'when's?
I expected that people would find it easier to read 'when'/'unless' than single-clause 'if' statements. The 'when'/'unless', along with the indentation of the corresponding 'then' clause, immediately signal that there is only one possible non-nil form returned. With single-clause 'if' statements, you would have to continue reading past the 'then' clause to spot what the 'when'/'unless' and its differing indentation immediately tell you.
> ----------------------------------------
> From: Eli Zaretskii <eliz <at> gnu.org>
> Sent: Sun Sep 13 16:07:02 CEST 2020
> To: Brian Leung <leungbk <at> mailfence.com>, Brian Leung <leungbk <at> mailfence.com>
> Cc: <dgutov <at> yandex.ru>, <rpluim <at> gmail.com>, <43117 <at> debbugs.gnu.org>
> Subject: Re: bug#43117: [PATCH] Add .git-blame-ignore-revs file
>
>
> > Cc: 43117 <at> debbugs.gnu.org
> > Date: Sun, 13 Sep 2020 02:42:23 +0200 (CEST)
> > From: Brian Leung via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > OK, please see attached. Right now there are no extraneous whitespace changes, and the only changes I've made change if -> when in the eshell files.
> > [...]
> > Subject: [PATCH 1/2] eshell: Replace single-clause if statements with whens
>
> I'm not sure I understand the rationale: why would we want to replace
> all 'if's with 'when's? Was that discussed, here or elsewhere? if so,
> could someone point me to that discussion?
>
> Thanks.
--
Sent with https://mailfence.com
Secure and private email
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 13 Sep 2020 17:35:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Sep 2020 19:06:39 +0200 (CEST)
> From: Brian Leung <leungbk <at> mailfence.com>
> Cc: dgutov <at> yandex.ru, rpluim <at> gmail.com, 43117 <at> debbugs.gnu.org
>
> > I'm not sure I understand the rationale: why would we want to replace
> > all 'if's with 'when's?
>
> I expected that people would find it easier to read 'when'/'unless' than single-clause 'if' statements. The 'when'/'unless', along with the indentation of the corresponding 'then' clause, immediately signal that there is only one possible non-nil form returned. With single-clause 'if' statements, you would have to continue reading past the 'then' clause to spot what the 'when'/'unless' and its differing indentation immediately tell you.
To go over two dozen of files and summarily replace 'if' with 'when'
for this reason sounds way too radical to me. I have no difficulties
understanding the original code, FWIW.
Is it just me? do others think such changes are a good idea?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 13 Sep 2020 17:58:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Is it just me? do others think such changes are a good idea?
I hate one-form-`if' more than anybody, but I don't think these purely
stylistic rewrites are a good idea, as it means that "git blame" and
vc-region-history gets less useful, and applying older patches fails
more often.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 13 Sep 2020 18:50:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 43117 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I don't think these purely
> stylistic rewrites are a good idea, as it means that "git blame" and
> vc-region-history gets less useful, and applying older patches fails
> more often.
OK, I won't submit that commit then. The other commit I had introduced a .git-blame-ignore-revs file, which allows certain commits to be ignored during git-blame sessions. I've modified that commit accordingly and attached. Would that be of use?
My FSF papers are attached.
> ----------------------------------------
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Sent: Sun Sep 13 19:57:25 CEST 2020
> To: Eli Zaretskii <eliz <at> gnu.org>
> Cc: Brian Leung <leungbk <at> mailfence.com>, <rpluim <at> gmail.com>, <dgutov <at> yandex.ru>, <43117 <at> debbugs.gnu.org>
> Subject: Re: bug#43117: [PATCH] Add .git-blame-ignore-revs file
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Is it just me? do others think such changes are a good idea?
>
> I hate one-form-`if' more than anybody, but I don't think these purely
> stylistic rewrites are a good idea, as it means that "git blame" and
> vc-region-history gets less useful, and applying older patches fails
> more often.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Sent with https://mailfence.com
Secure and private email
[0001-Add-.git-blame-ignore-revs-file.patch (text/x-diff, attachment)]
[leung.tar.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 18 Oct 2020 17:04:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Brian Leung <leungbk <at> mailfence.com> writes:
>> I don't think these purely
>> stylistic rewrites are a good idea, as it means that "git blame" and
>> vc-region-history gets less useful, and applying older patches fails
>> more often.
>
> OK, I won't submit that commit then. The other commit I had introduced a
> .git-blame-ignore-revs file, which allows certain commits to be ignored during
> git-blame sessions. I've modified that commit accordingly and attached. Would
> that be of use?
I think this sounds very useful. And it works well in practice from my
limited testing.
Does anyone object to adding this file?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 18 Oct 2020 17:19:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 18 Oct 2020 10:03:04 -0700
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com,
> 43117 <at> debbugs.gnu.org, dgutov <at> yandex.ru
>
> > OK, I won't submit that commit then. The other commit I had introduced a
> > .git-blame-ignore-revs file, which allows certain commits to be ignored during
> > git-blame sessions. I've modified that commit accordingly and attached. Would
> > that be of use?
>
> I think this sounds very useful. And it works well in practice from my
> limited testing.
>
> Does anyone object to adding this file?
I don't think I understand what does this file mean from the
maintenance POV. Who will maintain it, and what are the procedures?
And what should be done about it while merging from the release branch
to master?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 18 Oct 2020 17:55:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I don't think I understand what does this file mean from the
> maintenance POV. Who will maintain it, and what are the procedures?
I would propose that we treat it as an optional feature rather than
striving for it to include a complete list of all "uninteresting"
commits at all times.
Even if it were to include only a proportion of some of the latest
"uninteresting" cleanups, that could already be of help. When someone
stumbles into a commit that gets in the way of their git blaming they
could also consider adding it.
> And what should be done about it while merging from the release branch
> to master?
I don't think anything in particular needs doing, since the sha-1 will
stay the same after a merge. Or am I missing something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 18 Oct 2020 18:00:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 18 Oct 2020 10:54:02 -0700
> Cc: leungbk <at> mailfence.com, larsi <at> gnus.org, rpluim <at> gmail.com,
> 43117 <at> debbugs.gnu.org, dgutov <at> yandex.ru
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I don't think I understand what does this file mean from the
> > maintenance POV. Who will maintain it, and what are the procedures?
>
> I would propose that we treat it as an optional feature rather than
> striving for it to include a complete list of all "uninteresting"
> commits at all times.
>
> Even if it were to include only a proportion of some of the latest
> "uninteresting" cleanups, that could already be of help. When someone
> stumbles into a commit that gets in the way of their git blaming they
> could also consider adding it.
We already mark such commits with a leading semi-colon. Will this
file simply repeat those commits?
> > And what should be done about it while merging from the release branch
> > to master?
>
> I don't think anything in particular needs doing, since the sha-1 will
> stay the same after a merge. Or am I missing something?
Not all of the commits get merged. Some are skipped.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 18 Oct 2020 18:26:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> We already mark such commits with a leading semi-colon. Will this
> file simply repeat those commits?
Yes, if we want the commits ignored by "git blame". But of course it
could include only some of them, as well as commits not marked with a
leading semi-colon.
>> > And what should be done about it while merging from the release branch
>> > to master?
>>
>> I don't think anything in particular needs doing, since the sha-1 will
>> stay the same after a merge. Or am I missing something?
>
> Not all of the commits get merged. Some are skipped.
Wouldn't having non-existent commit ids in there mostly be an aesthetic
problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Sun, 18 Oct 2020 18:42:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 18 Oct 2020 11:25:31 -0700
> Cc: leungbk <at> mailfence.com, larsi <at> gnus.org, rpluim <at> gmail.com,
> 43117 <at> debbugs.gnu.org, dgutov <at> yandex.ru
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > We already mark such commits with a leading semi-colon. Will this
> > file simply repeat those commits?
>
> Yes, if we want the commits ignored by "git blame". But of course it
> could include only some of them, as well as commits not marked with a
> leading semi-colon.
Why would someone want to skip commits in "git blame"? We need to
have agreed-upon criteria or policy for that, otherwise each one of
use will step on the others' toes. "git blame" is an important
forensics command, so hiding commits from it might surprise someone,
if it's unexpected.
> >> > And what should be done about it while merging from the release branch
> >> > to master?
> >>
> >> I don't think anything in particular needs doing, since the sha-1 will
> >> stay the same after a merge. Or am I missing something?
> >
> > Not all of the commits get merged. Some are skipped.
>
> Wouldn't having non-existent commit ids in there mostly be an aesthetic
> problem?
I don't know. Will it? I have no experience with this feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 19 Oct 2020 16:07:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Why would someone want to skip commits in "git blame"? We need to
> have agreed-upon criteria or policy for that, otherwise each one of
> use will step on the others' toes. "git blame" is an important
> forensics command, so hiding commits from it might surprise someone,
> if it's unexpected.
For example, if a commit fixed a typo in a doc string, I'd much rather
see the commit that added that text than the one that fixed the typo.
>> Wouldn't having non-existent commit ids in there mostly be an aesthetic
>> problem?
>
> I don't know. Will it? I have no experience with this feature.
AFAIU, git will just skip over non-existent commits in this case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Mon, 19 Oct 2020 16:41:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 43117 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Mon, 19 Oct 2020 16:06:45 +0000
> Cc: leungbk <at> mailfence.com, larsi <at> gnus.org, rpluim <at> gmail.com,
> 43117 <at> debbugs.gnu.org, dgutov <at> yandex.ru
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Why would someone want to skip commits in "git blame"? We need to
> > have agreed-upon criteria or policy for that, otherwise each one of
> > use will step on the others' toes. "git blame" is an important
> > forensics command, so hiding commits from it might surprise someone,
> > if it's unexpected.
>
> For example, if a commit fixed a typo in a doc string, I'd much rather
> see the commit that added that text than the one that fixed the typo.
But that's your personal preference, isn't it? Do we know for sure no
one will ever want to see changes that fixed typos? For example, what
about some "typo" that is controversial (like the "parseable" thing we
discussed lately), and we want to know who and why "fixed" it?
In short, the more I think about this feature, the less it makes sense
to me to use it in our project. It's probably fine for a
single-developer projects, where the preferences are never in
conflict. But ours is a very different project.
> >> Wouldn't having non-existent commit ids in there mostly be an aesthetic
> >> problem?
> >
> > I don't know. Will it? I have no experience with this feature.
>
> AFAIU, git will just skip over non-existent commits in this case.
It requires a setting in .git/config, doesn't it? Would older
versions of Git warn about the setting they don't know about? Or do
we expect users to turn this on in their ~/.gitconfig instead?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Tue, 20 Oct 2020 10:39:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> For example, if a commit fixed a typo in a doc string, I'd much rather
>> see the commit that added that text than the one that fixed the typo.
I think I'd want commits like that included in git blame...
> In short, the more I think about this feature, the less it makes sense
> to me to use it in our project. It's probably fine for a
> single-developer projects, where the preferences are never in
> conflict. But ours is a very different project.
If Emacs was a project that did extensive "janitorial" fixups, then it
might make more sense. For instance, if we were to fix all whitespace
to be consistent, then having a way to ignore that would be nice. But
we don't, so I'm not sure adding a .git-blame-ignore-revs file helps us
much.
The only thing I'd want to use such a file for would be for things that
really are 100% non-functional: Whitespace changes and spelling fixes
for comments.
So I don't think such a file would help the Emacs project.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Tue, 20 Oct 2020 12:06:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 43117 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> For example, if a commit fixed a typo in a doc string, I'd much rather
>>> see the commit that added that text than the one that fixed the typo.
>
> I think I'd want commits like that included in git blame...
>
>> In short, the more I think about this feature, the less it makes sense
>> to me to use it in our project. It's probably fine for a
>> single-developer projects, where the preferences are never in
>> conflict. But ours is a very different project.
>
> If Emacs was a project that did extensive "janitorial" fixups, then it
> might make more sense. For instance, if we were to fix all whitespace
> to be consistent, then having a way to ignore that would be nice. But
> we don't, so I'm not sure adding a .git-blame-ignore-revs file helps us
> much.
>
> The only thing I'd want to use such a file for would be for things that
> really are 100% non-functional: Whitespace changes and spelling fixes
> for comments.
>
> So I don't think such a file would help the Emacs project.
You both make good points.
I guess the logical conclusion here is to close this bug as wontfix.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43117; Package
emacs.
(Fri, 12 Mar 2021 01:08:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 43117 <at> debbugs.gnu.org (full text, mbox):
tags 43117 + wontfix
close 43117
thanks
Stefan Kangas <stefan <at> marxist.se> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> For example, if a commit fixed a typo in a doc string, I'd much rather
>>>> see the commit that added that text than the one that fixed the typo.
>>
>> I think I'd want commits like that included in git blame...
>>
>>> In short, the more I think about this feature, the less it makes sense
>>> to me to use it in our project. It's probably fine for a
>>> single-developer projects, where the preferences are never in
>>> conflict. But ours is a very different project.
>>
>> If Emacs was a project that did extensive "janitorial" fixups, then it
>> might make more sense. For instance, if we were to fix all whitespace
>> to be consistent, then having a way to ignore that would be nice. But
>> we don't, so I'm not sure adding a .git-blame-ignore-revs file helps us
>> much.
>>
>> The only thing I'd want to use such a file for would be for things that
>> really are 100% non-functional: Whitespace changes and spelling fixes
>> for comments.
>>
>> So I don't think such a file would help the Emacs project.
>
> You both make good points.
>
> I guess the logical conclusion here is to close this bug as wontfix.
No further comments within 20 weeks, so I'm closing this as wontfix.
Added tag(s) wontfix.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Fri, 12 Mar 2021 01:08:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
43117 <at> debbugs.gnu.org and Brian Leung <leungbk <at> mailfence.com>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Fri, 12 Mar 2021 01:08:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 09 Apr 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.