Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Robert Pluim]

>>>>> On Tue, 11 May 2021 23:09:49 -0400 (EDT), rms@gnu.org (Richard M. Stallman) said:

    Richard> branch: master
    Richard> commit 47070ed39eda524d334e5f82dc7f4a50b8d3252c
    Richard> Merge: 67722ab 5784b42
    Richard> Author: Richard Stallman <rms@gnu.org>
    Richard> Commit: Richard Stallman <rms@gnu.org>

    Richard>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
    
    Richard>     What choice do I have?

Before pushing you can use 'git pull --rebase' to automatically update
to the HEAD of the branch youʼre on and then re-apply any commits
you've made. If you want to always do that, add 'rebase = true' to the
definition of your branch in .git/config. eg I have:

[branch "master"]
	remote = origin
	merge = refs/heads/master
	rebase = true

As far as I know emacs has no stated preference for merge vs rebase,
so all this is optional.

Robert
-- 

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 12 May 2021 10:16:33 +0200
> Cc: Richard Stallman <rms@gnu.org>
> 
>     Richard> Author: Richard Stallman <rms@gnu.org>
>     Richard> Commit: Richard Stallman <rms@gnu.org>
> 
>     Richard>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
>     
>     Richard>     What choice do I have?

Richard, can you tell what caused you to ask that question?

> Before pushing you can use 'git pull --rebase' to automatically update
> to the HEAD of the branch youʼre on and then re-apply any commits
> you've made.

My suggestion is just "git pull", without rebasing.  Rebasing can
cause trouble in some rare situation, so we decided long ago not to
encourage that workflow (but if you know well enough what you are
doing, feel free to rebase).

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >     Richard> Author: Richard Stallman <rms@gnu.org>
  > >     Richard> Commit: Richard Stallman <rms@gnu.org>
  > > 
  > >     Richard>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
  > >     
  > >     Richard>     What choice do I have?

  > Richard, can you tell what caused you to ask that question?

I did  git pull  and it said there were conflicts.  I resolved the conflicts
and committed them.  Then I did  git pull  again and it asked me why
I was doing the merge.  I could not think of any reason except that
git demanded it.

I have never tried rebasing.  I have been taught that you can easily die
of an overdose that way.  Oh, sorry, that was "freebasing".


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> Date: Thu, 13 May 2021 00:53:40 -0400
> 
>   > >     Richard>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
>   > >     
>   > >     Richard>     What choice do I have?
> 
>   > Richard, can you tell what caused you to ask that question?
> 
> I did  git pull  and it said there were conflicts.  I resolved the conflicts
> and committed them.  Then I did  git pull  again and it asked me why
> I was doing the merge.  I could not think of any reason except that
> git demanded it.

I see nothing wrong with what you did, it's one way of dealing with
local changes when you update from upstream.

> I have never tried rebasing.

I see no reason to start now.

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I see nothing wrong with what you did, it's one way of dealing with
  > local changes when you update from upstream.

That is a relief.

But still -- what sort of answer was Git looking for
when it asked me the reason for that merge?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> Date: Fri, 14 May 2021 01:23:12 -0400
> 
>   > I see nothing wrong with what you did, it's one way of dealing with
>   > local changes when you update from upstream.
> 
> That is a relief.
> 
> But still -- what sort of answer was Git looking for
> when it asked me the reason for that merge?

Do you remember the question it asked?  Was it something like the
below?

  # Please enter a commit message to explain why this merge is necessary,
  # especially if it merges an updated upstream into a topic branch.
  #
  # Lines starting with '#' will be ignored and an empty message aborts
  # the commit.

If so, this is not really a question you need to answer.  The line
above it is the merge-commit log message Git prepares for you (it
probably said something like "Merge branch 'master' of
git.sv.gnu.org:/srv/git/emacs"), so basically all you need to do is
"C-c C-c" to let Git use that standard message and proceed with the
merge.

What Git wants is to encourage you to edit the log message saying why
you did the merge, but in cases like yours there's no good reason
worthy of describing, so most people simply ignore that and use the
standard log message instead without any changes.

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Stefan Monnier]

> If so, this is not really a question you need to answer.  The line
> above it is the merge-commit log message Git prepares for you (it
> probably said something like "Merge branch 'master' of
> git.sv.gnu.org:/srv/git/emacs"), so basically all you need to do is
> "C-c C-c" to let Git use that standard message and proceed with the
> merge.

Indeed: when the merge doesn't encounter any conflict, it will create the
commit with the default message without asking you.


        Stefan

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Andreas Schwab]

On Mai 14 2021, Stefan Monnier wrote:

> Indeed: when the merge doesn't encounter any conflict, it will create the
> commit with the default message without asking you.

You must be using a very old version of git.  Nowadays git merge always
asks you to edit the commit message.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: master 47070ed 6/6: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Do you remember the question it asked?  Was it something like the
  > below?

  >   # Please enter a commit message to explain why this merge is necessary,
  >   # especially if it merges an updated upstream into a topic branch.
  >   #
  >   # Lines starting with '#' will be ignored and an empty message aborts
  >   # the commit.

I think so.

  > If so, this is not really a question you need to answer.  The line
  > above it is the merge-commit log message Git prepares for you (it
  > probably said something like "Merge branch 'master' of
  > git.sv.gnu.org:/srv/git/emacs"),

It was not obvious to me that the text above constitutes a possible answer.
I thought it was simply information being shown to me.


                                     so basically all you need to do is
  > "C-c C-c" to let Git use that standard message and proceed with the
  > merge.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Lars Ingebrigtsen]

rms@gnu.org (Richard M. Stallman) writes:

> +    ;; Debbugs sometimes adds `[External] :'; if that happened,
> +    ;; delete everything up thru there.  Empirically, that deletion makes
> +    ;; the Subject match the other messages in the thread.

This is not accurate -- it's just Drew that insists on adding that
string to his subjects.  I find it pretty odd to add general code to
Emacs to handle a single person's Subject mangling.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 12 May 2021 14:17:45 +0200
> Cc: Richard Stallman <rms@gnu.org>
> 
> rms@gnu.org (Richard M. Stallman) writes:
> 
> > +    ;; Debbugs sometimes adds `[External] :'; if that happened,
> > +    ;; delete everything up thru there.  Empirically, that deletion makes
> > +    ;; the Subject match the other messages in the thread.
> 
> This is not accurate -- it's just Drew that insists on adding that
> string to his subjects.  I find it pretty odd to add general code to
> Emacs to handle a single person's Subject mangling.

Drew might be a single person, but he tends to flood the Emacs mailing
lists with a lot of messages carrying this addition.  Rmail's
threading is based on comparing their Subject lines, and Rmail already
has quite a few heuristics whose purpose is to clean up the Subject
line to that end.  I see nothing wrong with adding one more
heuristics; the problem hits me as well.

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I see nothing wrong with adding one more heuristics; the problem hits
> me as well.

Or we could just ask Drew to stop doing this.

Drew?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Eli Zaretskii]

> Date: Wed, 12 May 2021 16:12:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Drew might be a single person, but he tends to flood the Emacs mailing
> lists with a lot of messages carrying this addition.

And of course once such a message is sent, most of replies to it also
carry that addition.  So in reality many other people generate such
messages.

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Stefan Monnier]

Eli Zaretskii [2021-05-12 16:12:46] wrote:
> Drew might be a single person, but he tends to flood the Emacs mailing
> lists with a lot of messages carrying this addition.  Rmail's
> threading is based on comparing their Subject lines, and Rmail already
> has quite a few heuristics whose purpose is to clean up the Subject
> line to that end.  I see nothing wrong with adding one more
> heuristics; the problem hits me as well.

But this shouldn't be embedded directly into the code.
We should have instead a variable specifying those cases (so it can be
extended/adjusted depending on the cases the users face).

Gregory Heytings [2021-05-12 14:17:59] wrote:
> See https://its.uiowa.edu/support/article/114496 for a possible explanation.
> This is typically something big corporations or government agencies do; for
> another example on this mailing list, see the posts from Stephan Mueller
> (microsoft.com), which use [EXTERNAL].

I suspect that similar things happen in non-anglophone contexts where
the word used is likely different.


        Stefan

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 12 May 2021 11:14:47 -0400
> 
> Eli Zaretskii [2021-05-12 16:12:46] wrote:
> > Drew might be a single person, but he tends to flood the Emacs mailing
> > lists with a lot of messages carrying this addition.  Rmail's
> > threading is based on comparing their Subject lines, and Rmail already
> > has quite a few heuristics whose purpose is to clean up the Subject
> > line to that end.  I see nothing wrong with adding one more
> > heuristics; the problem hits me as well.
> 
> But this shouldn't be embedded directly into the code.
> We should have instead a variable specifying those cases (so it can be
> extended/adjusted depending on the cases the users face).

It's an internal implementation detail that no user will ever want to
change, so I see no reason to have a separate variable.  We already
have several strings there hard coded into the function, and I see
nothing wrong with having one more.

If it turns out this addition comes in several variants that are not
expressible as a simple regexp, we will probably make a variable, as
we do with other similar additions.

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But this shouldn't be embedded directly into the code.
> We should have instead a variable specifying those cases (so it can be
> extended/adjusted depending on the cases the users face).

Yup.  There's a gazillion ways subject headers can be mangled, and it's
pretty odd of an Emacs mail user agent to do one particular obscure
fix-up just because it's one mangling that Emacs maintainers have to
deal with.

What if there's users out there that really want to see that [EXTERNAL]
thing, because their incoming MTA adds it, and it's corporate policy to
have those markings on mail that arrives from outside?  Suddenly they
get a stern talking-to from HR.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 12 May 2021 17:47:35 +0200
> 
> What if there's users out there that really want to see that [EXTERNAL]
> thing, because their incoming MTA adds it, and it's corporate policy to
> have those markings on mail that arrives from outside?  Suddenly they
> get a stern talking-to from HR.

This is a misunderstanding: the code Richard added doesn't remove
[EXTERNAL] from the Subject line shown to the user, it removes it when
"simplifying" the Subject for the purposes of comparing it to other
Subjects.  IOW, it's an internal removal, not visible to the user.
All the user sees is that Subjects "Foo" and "[EXTERNAL] Foo" compare
equal, just like "Re: Foo" and "Antwort: Foo".  Rmail has a command
rmail-next-same-subject, which uses that.

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Robert Pluim]

>>>>> On Wed, 12 May 2021 11:14:47 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> Eli Zaretskii [2021-05-12 16:12:46] wrote:
    >> Drew might be a single person, but he tends to flood the Emacs mailing
    >> lists with a lot of messages carrying this addition.  Rmail's
    >> threading is based on comparing their Subject lines, and Rmail already
    >> has quite a few heuristics whose purpose is to clean up the Subject
    >> line to that end.  I see nothing wrong with adding one more
    >> heuristics; the problem hits me as well.

    Stefan> But this shouldn't be embedded directly into the code.
    Stefan> We should have instead a variable specifying those cases (so it can be
    Stefan> extended/adjusted depending on the cases the users face).

See the variables {gnus,message}-simplify-subject-functions (and the
multitude of configuration variables therein).

Robert
-- 

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Gregory Heytings]

>> +    ;; Debbugs sometimes adds `[External] :'; if that happened,
>> +    ;; delete everything up thru there.  Empirically, that deletion makes
>> +    ;; the Subject match the other messages in the thread.
>
> This is not accurate -- it's just Drew that insists on adding that 
> string to his subjects.  I find it pretty odd to add general code to 
> Emacs to handle a single person's Subject mangling.
>

I don't think Drew does this himself.  It's probably something that the 
MTA (mail transport argent) from Oracle adds.  I've seen similar behavior 
from other people on other mailing lists, most often with [External] or 
[EXTERNAL], so I would make the comparison case-insensitive.

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Gregory Heytings]

>>> +    ;; Debbugs sometimes adds `[External] :'; if that happened,
>>> +    ;; delete everything up thru there.  Empirically, that deletion makes
>>> +    ;; the Subject match the other messages in the thread.
>> 
>> This is not accurate -- it's just Drew that insists on adding that 
>> string to his subjects.  I find it pretty odd to add general code to 
>> Emacs to handle a single person's Subject mangling.
>
> I don't think Drew does this himself.  It's probably something that the 
> MTA (mail transport argent) from Oracle adds.  I've seen similar 
> behavior from other people on other mailing lists, most often with 
> [External] or [EXTERNAL], so I would make the comparison 
> case-insensitive.
>

See https://its.uiowa.edu/support/article/114496 for a possible 
explanation.  This is typically something big corporations or government 
agencies do; for another example on this mailing list, see the posts from 
Stephan Mueller (microsoft.com), which use [EXTERNAL].

Re: master 42596bd 2/6: Little improvements in rmail.el. Recognize encryped override headers.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   Rmail's
  > > threading is based on comparing their Subject lines, and Rmail already
  > > has quite a few heuristics whose purpose is to clean up the Subject
  > > line to that end.  I see nothing wrong with adding one more
  > > heuristics; the problem hits me as well.

  > But this shouldn't be embedded directly into the code.
  > We should have instead a variable specifying those cases (so it can be
  > extended/adjusted depending on the cases the users face).

We could have a list of (REGEXP REPLACEMENT) items.
and feed each item to string-replace.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)