emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Final" version of tty child frames


From: Gerd Möllmann
Subject: Re: "Final" version of tty child frames
Date: Wed, 18 Dec 2024 17:39:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.)

Ok, thanks.

>
>> 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).

That's right, magit-add-change-log-entry also only generates the
skeleton. Didn't think of that :-).

> 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.

The diff I have, so I guess I'll give it a try, when the others agree.
Will take a bit, probably. Should I post the result when I have it?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]