Re: "Final" version of tty child frames

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Jared Finder <jared@finder.org>,  Stefan Kangas
>  <stefankangas@gmail.com>,  Andrea Corallo <acorallo@gnu.org>,
>   emacs-devel@gnu.org,  rudalics@gmx.at
> Date: Wed, 18 Dec 2024 17:01:35 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we don't see immediate ways of fixing some of these issues, I think
> > it should be okay to land this on master, if Stefan and Andrea agree.
> 
> In preparation, can I ask a few questions wrt landing?
> 
> What I seem to remember is that it entails a normal merge from
> scratch/tty-child-frames to master. No squashing, no interactive
> rebasing to fix commit messages first, or anything else complicated.

Yes, that's the preference.

> The merge commit message should have a certain form, IIRC. It should
> probably contain some introductory text like "This adds tty child
> frames...", and then ChangeLog-style entries.
> 
> For a new file it's basically sufficient to say "New file".
> 
> The rest gets a bit complicated, and I'm unsure how much detail is
> required. Say I've changed function parameters of an existing function
> plus I'm calling other functions whose API has changed plus added new
> code. Does that all have to appear in ChangeLog-style? That could take
> some time to produce.

Preferably yes.  However, for changing the function's signature you
can say something like

  * foo.c (bar): Accept additional argument FOOBAR.  All callers
    changed.

(This is not different from the rules for any commit, not only
merge-commit.)

> Another question: I can produce a list of commit IDs for changes that
> happened on the branch. Do we perhaps have some tool that produces these
> change log entries automatically? Something akin to
> magit-add-change-log-entry maybe?

How would a tool know what to say in the description of the change?
Changes on feature branches usually don't have informative log
messages, they are usually minimal ("Fix crash in foobar" or
somesuch).

What I usually do is produce diffs for the merge, then use "C-x 4 a"
to generate the file/function names, and add a description.