Subject: bug#77924: 31.0.50; [Feature branch] Change marker implementation

From: Eli Zaretskii <[email-masked]>
Date: Wed, 23 Apr 2025 16:15:16 +0300

> Cc: Stefan Kangas <[email-masked]>, [email-masked]
> From: Gerd Möllmann <[email-masked]>
> Date: Wed, 23 Apr 2025 06:47:21 +0200
> 
> Gerd Möllmann <[email-masked]> 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/[email-masked]/
> 
> 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

It hasn't changed.

Some people like to rebase, others dislike rebasing.  (Full
disclosure: I'm in the latter camp.)  Since we decided not to care
either way, we don't request contributors to do it one way or the
other: they can do it however they like, and we will accept that
regardless.