[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?
- Re: "Final" version of tty child frames, (continued)
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/12/12
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/12
- Re: "Final" version of tty child frames, Jared Finder, 2024/12/18
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/18
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/12/18
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/18
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/12/18
- Re: "Final" version of tty child frames,
Gerd Möllmann <=
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/12/18
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/18
- Re: "Final" version of tty child frames, Jared Finder, 2024/12/19
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/19
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/19
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/12/19
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/19
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/19
- Re: "Final" version of tty child frames, Robert Pluim, 2024/12/19
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/12/19