* Re: master 50020d026c: Untabify rcirc.el [not found] ` <20220907091848.B4E13C04F04@vcs2.savannah.gnu.org> @ 2022-09-07 11:06 ` Lars Ingebrigtsen 2022-09-07 11:21 ` Philip Kaludercic 2022-09-07 11:23 ` Po Lu 1 sibling, 1 reply; 21+ messages in thread From: Lars Ingebrigtsen @ 2022-09-07 11:06 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel Philip Kaludercic <philipk@posteo.net> writes: > Untabify rcirc.el We don't do whitespace changes like this because it makes it more difficult to follow historical changes (and applying any pending patches). So please don't do things like this. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 11:06 ` master 50020d026c: Untabify rcirc.el Lars Ingebrigtsen @ 2022-09-07 11:21 ` Philip Kaludercic 2022-09-07 12:11 ` Philip Kaludercic 2022-09-07 12:54 ` Stefan Monnier 0 siblings, 2 replies; 21+ messages in thread From: Philip Kaludercic @ 2022-09-07 11:21 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel Lars Ingebrigtsen <larsi@gnus.org> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> Untabify rcirc.el > > We don't do whitespace changes like this because it makes it more > difficult to follow historical changes My apologies, I didn't know that there was a general rule like this. The last few times I had been working on rcirc I always ran into issues with whitespaces whenever indenting a function. Every patch had unrelated whitespace changes that had to be reverted to that the historical record isn't polluted. On a related note, I believe there has been a need to reorder rcirc to make it easier to follow along for a while. But it goes without saying that that would break the git history far more than this change. > (and applying any pending > patches). That shouldn't be an issue, because git am/apply can ignore whitespace. > So please don't do things like this. I will keep it in mind, but there is nothing left to do after this change. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 11:21 ` Philip Kaludercic @ 2022-09-07 12:11 ` Philip Kaludercic 2022-09-07 21:50 ` Stefan Kangas 2022-09-07 12:54 ` Stefan Monnier 1 sibling, 1 reply; 21+ messages in thread From: Philip Kaludercic @ 2022-09-07 12:11 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel Philip Kaludercic <philipk@posteo.net> writes: > Lars Ingebrigtsen <larsi@gnus.org> writes: > >> Philip Kaludercic <philipk@posteo.net> writes: >> >>> Untabify rcirc.el >> >> We don't do whitespace changes like this because it makes it more >> difficult to follow historical changes > > My apologies, I didn't know that there was a general rule like this. > The last few times I had been working on rcirc I always ran into issues > with whitespaces whenever indenting a function. Every patch had > unrelated whitespace changes that had to be reverted to that the > historical record isn't polluted. > > On a related note, I believe there has been a need to reorder rcirc to > make it easier to follow along for a while. But it goes without saying > that that would break the git history far more than this change. > >> (and applying any pending >> patches). > > That shouldn't be an issue, because git am/apply can ignore whitespace. I've also just found out that git blame supports this: Setting `vc-git-annotate-switches' to "-w" ignores all the whitespace changes when using vc-annotate. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 12:11 ` Philip Kaludercic @ 2022-09-07 21:50 ` Stefan Kangas 2022-09-07 22:07 ` Philip Kaludercic 2022-09-08 12:04 ` Lars Ingebrigtsen 0 siblings, 2 replies; 21+ messages in thread From: Stefan Kangas @ 2022-09-07 21:50 UTC (permalink / raw) To: Philip Kaludercic, Lars Ingebrigtsen; +Cc: emacs-devel Philip Kaludercic <philipk@posteo.net> writes: > I've also just found out that git blame supports this: Setting > `vc-git-annotate-switches' to "-w" ignores all the whitespace changes > when using vc-annotate. If that git flag has been around for a while, I think we should consider doing that by default. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 21:50 ` Stefan Kangas @ 2022-09-07 22:07 ` Philip Kaludercic 2022-09-08 9:07 ` Stefan Kangas 2022-09-08 12:04 ` Lars Ingebrigtsen 1 sibling, 1 reply; 21+ messages in thread From: Philip Kaludercic @ 2022-09-07 22:07 UTC (permalink / raw) To: Stefan Kangas; +Cc: Lars Ingebrigtsen, emacs-devel Stefan Kangas <stefankangas@gmail.com> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> I've also just found out that git blame supports this: Setting >> `vc-git-annotate-switches' to "-w" ignores all the whitespace changes >> when using vc-annotate. > > If that git flag has been around for a while, I think we should consider > doing that by default. It appears to have been added in 2007[0], so this might be viable. [0] https://git.kernel.org/pub/scm/git/git.git/commit/?id=b82871b3c32faa8a317007f343fdf2d0ddc9954e ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 22:07 ` Philip Kaludercic @ 2022-09-08 9:07 ` Stefan Kangas 2022-09-08 9:20 ` Robert Pluim ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Stefan Kangas @ 2022-09-08 9:07 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Lars Ingebrigtsen, emacs-devel Philip Kaludercic <philipk@posteo.net> writes: > It appears to have been added in 2007[0], so this might be viable. So I guess the below should be uncontroversial? diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el index 9dfdd9e7b1..3b15e976e5 100644 --- a/lisp/vc/vc-git.el +++ b/lisp/vc/vc-git.el @@ -119,14 +119,14 @@ vc-git-diff-switches (repeat :tag "Argument List" :value ("") string)) :version "23.1") -(defcustom vc-git-annotate-switches nil +(defcustom vc-git-annotate-switches "-w" "String or list of strings specifying switches for Git blame under VC. If nil, use the value of `vc-annotate-switches'. If t, use no switches." :type '(choice (const :tag "Unspecified" nil) (const :tag "None" t) (string :tag "Argument String") (repeat :tag "Argument List" :value ("") string)) - :version "25.1") + :version "29.1") (defcustom vc-git-log-switches nil "String or list of strings specifying switches for Git log under VC." ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 9:07 ` Stefan Kangas @ 2022-09-08 9:20 ` Robert Pluim 2022-09-08 9:39 ` Stefan Kangas 2022-09-08 9:36 ` Eli Zaretskii 2022-09-08 9:37 ` Philip Kaludercic 2 siblings, 1 reply; 21+ messages in thread From: Robert Pluim @ 2022-09-08 9:20 UTC (permalink / raw) To: Stefan Kangas; +Cc: Philip Kaludercic, Lars Ingebrigtsen, emacs-devel >>>>> On Thu, 8 Sep 2022 05:07:33 -0400, Stefan Kangas <stefankangas@gmail.com> said: Stefan> Philip Kaludercic <philipk@posteo.net> writes: >> It appears to have been added in 2007[0], so this might be viable. Stefan> So I guess the below should be uncontroversial? That depends. Are you going to call this out in NEWS, and is there any easy way to invoke `vc-annotate' with nil switches? [1] It might be better putting it in the emacs .dir-locals.el Robert Footnotes: [1] The docstring for `vc-annotate-switches' mentions `annotate-switches', but I canʼt find that variable -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 9:20 ` Robert Pluim @ 2022-09-08 9:39 ` Stefan Kangas 0 siblings, 0 replies; 21+ messages in thread From: Stefan Kangas @ 2022-09-08 9:39 UTC (permalink / raw) To: Robert Pluim; +Cc: Philip Kaludercic, Lars Ingebrigtsen, emacs-devel Robert Pluim <rpluim@gmail.com> writes: >>>>>> On Thu, 8 Sep 2022 05:07:33 -0400, Stefan Kangas <stefankangas@gmail.com> said: > > Stefan> Philip Kaludercic <philipk@posteo.net> writes: > >> It appears to have been added in 2007[0], so this might be viable. > > Stefan> So I guess the below should be uncontroversial? > > That depends. Are you going to call this out in NEWS, That would be the idea, yes. > and is there any > easy way to invoke `vc-annotate' with nil switches? [1] No idea, sorry. > It might be better putting it in the emacs .dir-locals.el That's another alternative. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 9:07 ` Stefan Kangas 2022-09-08 9:20 ` Robert Pluim @ 2022-09-08 9:36 ` Eli Zaretskii 2022-09-08 9:46 ` Stefan Kangas 2022-09-08 9:37 ` Philip Kaludercic 2 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2022-09-08 9:36 UTC (permalink / raw) To: Stefan Kangas; +Cc: philipk, larsi, emacs-devel > From: Stefan Kangas <stefankangas@gmail.com> > Date: Thu, 8 Sep 2022 05:07:33 -0400 > Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org > > Philip Kaludercic <philipk@posteo.net> writes: > > > It appears to have been added in 2007[0], so this might be viable. > > So I guess the below should be uncontroversial? No, I see no reason for us to impose our preferences on users. Program switches should not specify anything by default, unless not doing so makes no sense, or doesn't allow Emacs to communicate with the program or produce the effect we need. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 9:36 ` Eli Zaretskii @ 2022-09-08 9:46 ` Stefan Kangas 2022-09-08 10:25 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Stefan Kangas @ 2022-09-08 9:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: philipk, larsi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Program switches should not specify anything by default, unless not > doing so makes no sense, or doesn't allow Emacs to communicate with > the program or produce the effect we need. How about adding it to our .dir-locals.el instead? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 9:46 ` Stefan Kangas @ 2022-09-08 10:25 ` Eli Zaretskii 2022-09-08 12:02 ` Robert Pluim 2022-09-08 12:05 ` Philip Kaludercic 0 siblings, 2 replies; 21+ messages in thread From: Eli Zaretskii @ 2022-09-08 10:25 UTC (permalink / raw) To: Stefan Kangas; +Cc: philipk, larsi, emacs-devel > From: Stefan Kangas <stefankangas@gmail.com> > Date: Thu, 8 Sep 2022 05:46:04 -0400 > Cc: philipk@posteo.net, larsi@gnus.org, emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > > Program switches should not specify anything by default, unless not > > doing so makes no sense, or doesn't allow Emacs to communicate with > > the program or produce the effect we need. > > How about adding it to our .dir-locals.el instead? If that's what people here prefer, I won't mind. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 10:25 ` Eli Zaretskii @ 2022-09-08 12:02 ` Robert Pluim 2022-09-08 12:05 ` Philip Kaludercic 1 sibling, 0 replies; 21+ messages in thread From: Robert Pluim @ 2022-09-08 12:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Kangas, philipk, larsi, emacs-devel >>>>> On Thu, 08 Sep 2022 13:25:29 +0300, Eli Zaretskii <eliz@gnu.org> said: >> From: Stefan Kangas <stefankangas@gmail.com> >> Date: Thu, 8 Sep 2022 05:46:04 -0400 >> Cc: philipk@posteo.net, larsi@gnus.org, emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > Program switches should not specify anything by default, unless not >> > doing so makes no sense, or doesn't allow Emacs to communicate with >> > the program or produce the effect we need. >> >> How about adding it to our .dir-locals.el instead? Eli> If that's what people here prefer, I won't mind. I prefer it (although I tend to use magit, which already has '-w' in its default blame args). Robert -- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 10:25 ` Eli Zaretskii 2022-09-08 12:02 ` Robert Pluim @ 2022-09-08 12:05 ` Philip Kaludercic 2022-09-09 23:13 ` Stefan Kangas 1 sibling, 1 reply; 21+ messages in thread From: Philip Kaludercic @ 2022-09-08 12:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Kangas, larsi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Kangas <stefankangas@gmail.com> >> Date: Thu, 8 Sep 2022 05:46:04 -0400 >> Cc: philipk@posteo.net, larsi@gnus.org, emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > Program switches should not specify anything by default, unless not >> > doing so makes no sense, or doesn't allow Emacs to communicate with >> > the program or produce the effect we need. >> >> How about adding it to our .dir-locals.el instead? > > If that's what people here prefer, I won't mind. Just as with bug#55040, there will be an issue when checking the master branch using an older version of Emacs, since `vc-git-annotate-switches' won't be marked as a safe file local variable. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 12:05 ` Philip Kaludercic @ 2022-09-09 23:13 ` Stefan Kangas 0 siblings, 0 replies; 21+ messages in thread From: Stefan Kangas @ 2022-09-09 23:13 UTC (permalink / raw) To: Philip Kaludercic, Eli Zaretskii; +Cc: larsi, emacs-devel Philip Kaludercic <philipk@posteo.net> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> If that's what people here prefer, I won't mind. > > Just as with bug#55040, there will be an issue when checking the master > branch using an older version of Emacs, since `vc-git-annotate-switches' > won't be marked as a safe file local variable. So I've added it (commit 3ddf1a920d). If it's too annoying on old versions, we could always comment it out for a while and re-enable it later, but I'll leave that decision to people who would be affected. (I never edit new sources with an old Emacs.) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-08 9:07 ` Stefan Kangas 2022-09-08 9:20 ` Robert Pluim 2022-09-08 9:36 ` Eli Zaretskii @ 2022-09-08 9:37 ` Philip Kaludercic 2 siblings, 0 replies; 21+ messages in thread From: Philip Kaludercic @ 2022-09-08 9:37 UTC (permalink / raw) To: Stefan Kangas; +Cc: Lars Ingebrigtsen, emacs-devel Stefan Kangas <stefankangas@gmail.com> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> It appears to have been added in 2007[0], so this might be viable. > > So I guess the below should be uncontroversial? > > diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el > index 9dfdd9e7b1..3b15e976e5 100644 > --- a/lisp/vc/vc-git.el > +++ b/lisp/vc/vc-git.el > @@ -119,14 +119,14 @@ vc-git-diff-switches > (repeat :tag "Argument List" :value ("") string)) > :version "23.1") > > -(defcustom vc-git-annotate-switches nil > +(defcustom vc-git-annotate-switches "-w" It might be useful to add a comment indicating what the point of -w is. > "String or list of strings specifying switches for Git blame under VC. > If nil, use the value of `vc-annotate-switches'. If t, use no switches." > :type '(choice (const :tag "Unspecified" nil) > (const :tag "None" t) > (string :tag "Argument String") > (repeat :tag "Argument List" :value ("") string)) > - :version "25.1") > + :version "29.1") > > (defcustom vc-git-log-switches nil > "String or list of strings specifying switches for Git log under VC." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 21:50 ` Stefan Kangas 2022-09-07 22:07 ` Philip Kaludercic @ 2022-09-08 12:04 ` Lars Ingebrigtsen 1 sibling, 0 replies; 21+ messages in thread From: Lars Ingebrigtsen @ 2022-09-08 12:04 UTC (permalink / raw) To: Stefan Kangas; +Cc: Philip Kaludercic, emacs-devel Stefan Kangas <stefankangas@gmail.com> writes: >> I've also just found out that git blame supports this: Setting >> `vc-git-annotate-switches' to "-w" ignores all the whitespace changes >> when using vc-annotate. > > If that git flag has been around for a while, I think we should consider > doing that by default. There are languages where whitespace is significant, so we can't add "-w" to the default. But as was also suggested, we could add that to the Emacs .dir-locals.el. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 11:21 ` Philip Kaludercic 2022-09-07 12:11 ` Philip Kaludercic @ 2022-09-07 12:54 ` Stefan Monnier 2022-09-07 13:22 ` Philip Kaludercic 1 sibling, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2022-09-07 12:54 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Lars Ingebrigtsen, emacs-devel > My apologies, I didn't know that there was a general rule like this. > The last few times I had been working on rcirc I always ran into issues > with whitespaces whenever indenting a function. Every patch had > unrelated whitespace changes that had to be reverted to that the > historical record isn't polluted. Whitespace changes are "by definition" gratuitous. We don't disallow them, but they should be limited to the lines that are changed for other reasons as well. [ Note also that there are degrees: e.g. reindentation is not 100% gratuitous, contrary to tabify/untabify. ] > On a related note, I believe there has been a need to reorder rcirc to > make it easier to follow along for a while. But it goes without saying > that that would break the git history far more than this change. This is yet elsewhere on the scale of "gratuitous", so we also prefer to refrain from doing so, but sometimes it's justified (usually together with a string of other, more substantial, changes). Stefan "guilty of many non-whitespace but still gratuitous changes" ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 12:54 ` Stefan Monnier @ 2022-09-07 13:22 ` Philip Kaludercic 0 siblings, 0 replies; 21+ messages in thread From: Philip Kaludercic @ 2022-09-07 13:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> My apologies, I didn't know that there was a general rule like this. >> The last few times I had been working on rcirc I always ran into issues >> with whitespaces whenever indenting a function. Every patch had >> unrelated whitespace changes that had to be reverted to that the >> historical record isn't polluted. > > Whitespace changes are "by definition" gratuitous. We don't disallow > them, but they should be limited to the lines that are changed for other > reasons as well. > [ Note also that there are degrees: e.g. reindentation is not 100% > gratuitous, contrary to tabify/untabify. ] Thank you for the explanation. >> On a related note, I believe there has been a need to reorder rcirc to >> make it easier to follow along for a while. But it goes without saying >> that that would break the git history far more than this change. > > This is yet elsewhere on the scale of "gratuitous", so we also prefer to > refrain from doing so, but sometimes it's justified (usually together > with a string of other, more substantial, changes). I suspected that being the case, so I'll try to reorder things gradually as bugs are addressed or new features are added. > > Stefan "guilty of many non-whitespace but still gratuitous changes" ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el [not found] ` <20220907091848.B4E13C04F04@vcs2.savannah.gnu.org> 2022-09-07 11:06 ` master 50020d026c: Untabify rcirc.el Lars Ingebrigtsen @ 2022-09-07 11:23 ` Po Lu 2022-09-07 16:42 ` Jim Porter 1 sibling, 1 reply; 21+ messages in thread From: Po Lu @ 2022-09-07 11:23 UTC (permalink / raw) To: emacs-devel; +Cc: Philip Kaludercic Philip Kaludercic <philipk@posteo.net> writes: > branch: master > commit 50020d026cda1fdd70d8a08e08185dbb7183646a > Author: Philip Kaludercic <philipk@posteo.net> > Commit: Philip Kaludercic <philipk@posteo.net> > > Untabify rcirc.el (There's nothing wrong with tabs, not in Lisp code, not elsewhere. But that's besides the point.) Please don't make whitespace changes like this. It makes vc-annotate nonfunctional and is very much unnecessary. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 11:23 ` Po Lu @ 2022-09-07 16:42 ` Jim Porter 2022-09-07 18:21 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Jim Porter @ 2022-09-07 16:42 UTC (permalink / raw) To: Po Lu, emacs-devel; +Cc: Philip Kaludercic On 9/7/2022 4:23 AM, Po Lu wrote: > Philip Kaludercic <philipk@posteo.net> writes: > >> branch: master >> commit 50020d026cda1fdd70d8a08e08185dbb7183646a >> Author: Philip Kaludercic <philipk@posteo.net> >> Commit: Philip Kaludercic <philipk@posteo.net> >> >> Untabify rcirc.el > > (There's nothing wrong with tabs, not in Lisp code, not elsewhere. But > that's besides the point.) > > Please don't make whitespace changes like this. It makes vc-annotate > nonfunctional and is very much unnecessary. Perhaps we should set 'blame.ignoreRevsFile'[1] in the Emacs repo's Git config (and then add this commit SHA to that file)? That should make vc-annotate - and anything else that uses "git blame" - ignore this commit, along with any other mechanical commits that shouldn't count for the purposes of blame. I believe this was introduced in Git 2.23 (from Aug 2019), so most people with relatively-recent Git installs should be able to use this. I'm not sure how robust this feature is (i.e. can it properly ignore complex changes?), but for changing tabs to spaces, that should be pretty trivial for Git to figure out. [1] https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: master 50020d026c: Untabify rcirc.el 2022-09-07 16:42 ` Jim Porter @ 2022-09-07 18:21 ` Eli Zaretskii 0 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2022-09-07 18:21 UTC (permalink / raw) To: Jim Porter; +Cc: luangruo, emacs-devel, philipk > Cc: Philip Kaludercic <philipk@posteo.net> > From: Jim Porter <jporterbugs@gmail.com> > Date: Wed, 7 Sep 2022 09:42:54 -0700 > > Perhaps we should set 'blame.ignoreRevsFile'[1] in the Emacs repo's Git > config (and then add this commit SHA to that file)? That should make > vc-annotate - and anything else that uses "git blame" - ignore this > commit, along with any other mechanical commits that shouldn't count for > the purposes of blame. It doesn't seem a problem serious enough to justify hiding some commits. Especially since the feature is relatively new: two of the machines on which I work on Emacs use Git older than 2.23. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2022-09-09 23:13 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <166254232836.24759.17163698181249816742@vcs2.savannah.gnu.org> [not found] ` <20220907091848.B4E13C04F04@vcs2.savannah.gnu.org> 2022-09-07 11:06 ` master 50020d026c: Untabify rcirc.el Lars Ingebrigtsen 2022-09-07 11:21 ` Philip Kaludercic 2022-09-07 12:11 ` Philip Kaludercic 2022-09-07 21:50 ` Stefan Kangas 2022-09-07 22:07 ` Philip Kaludercic 2022-09-08 9:07 ` Stefan Kangas 2022-09-08 9:20 ` Robert Pluim 2022-09-08 9:39 ` Stefan Kangas 2022-09-08 9:36 ` Eli Zaretskii 2022-09-08 9:46 ` Stefan Kangas 2022-09-08 10:25 ` Eli Zaretskii 2022-09-08 12:02 ` Robert Pluim 2022-09-08 12:05 ` Philip Kaludercic 2022-09-09 23:13 ` Stefan Kangas 2022-09-08 9:37 ` Philip Kaludercic 2022-09-08 12:04 ` Lars Ingebrigtsen 2022-09-07 12:54 ` Stefan Monnier 2022-09-07 13:22 ` Philip Kaludercic 2022-09-07 11:23 ` Po Lu 2022-09-07 16:42 ` Jim Porter 2022-09-07 18:21 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).