GNU bug report logs - #77924
31.0.50; [Feature branch] Change marker implementation

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 77924 <at> debbugs.gnu.org
Subject: bug#77924: 31.0.50; [Feature branch] Change marker implementation
Date: Wed, 23 Apr 2025 06:47:21 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

>>>> PS. BTW, a small procedural thing.  Instead of merging master into a
>>>>     scratch/ branch, I recommend deleting the branch, rebasing it on
>>>>     master, and then pushing it again.  This way, when we later merge it
>>>>     into master, we avoid the merge commits, and the history is kept
>>>>     clean and more easily reviewable.  Not the end of the world either
>>>>     way, but something to consider.
>>>
>>> Sorry, too much work :-).
>>>
>>> (For reviewing a branch with merges from master I recommend to find the
>>> latest merge commit, take the parent commit on the master side, and
>>> range diff with that. (If you have the merge in the reflog, that
>>> speeds up finding the latest merge, but that's only the case if you did
>>> the merge in that repo.))
>>
>>     git diff origin/master...origin/scratch/text-index
>>
>> should take care of it.
>>
>> If there's interest, I could take care of rebasing (and improving the
>> commit messages on the rebased commits) before merging into `master`.
>
> Please consider the branch yours, if you like, as far as I am concerned
> :-). Because...
>
>>> I consider this feature done when that is in, and play with arm64 NEON a
>>> bit instead. In C++ ;-).
>
> ...of that-

It just appeared to me that I better ask instead of making assumptions:
When I landed tty child frames in master, there was a certain procedure
how to do that.  See

  https://yhetil.org/emacs-devel/m2ldwdrnds.fsf <at> gmail.com/

where I asked about this, and see Eli's reply. In essence: No rebasing,
squashing, and so on. Following that procedure, is why I posted the
change-log-style commit message for such a merge here.

My assumption up to a few minutes ago was that that procedure has
changed? Which I wouldn't know because I'm not following the lists for
some time. But, as I said, now I'm not really sure...

Previous Next

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