From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "Final" version of tty child frames Date: Wed, 18 Dec 2024 18:29:42 +0200 Message-ID: <868qsdlzt5.fsf@gnu.org> References: <86wmi0g0x6.fsf@gnu.org> <11a86987cce9fe0a257c3fa58703dc33@finder.org> <86wmgl6jzv.fsf@gnu.org> <092cb755eee3a9b5e06d15c0b07e90b1@finder.org> <276414b03c24964aaeb9e43e8dba5e77@finder.org> <5fedec86bce470555814acbdf999f99d@finder.org> <86h6791khk.fsf@gnu.org> <09b0904da92efad899865b2ece5f3116@finder.org> <86ikrhm6zk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22531"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jared@finder.org, stefankangas@gmail.com, acorallo@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 18 17:30:50 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tNwwk-0005d3-6t for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Dec 2024 17:30:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNwwX-0007fN-Lz; Wed, 18 Dec 2024 11:30:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNwwK-0007Qe-6K for emacs-devel@gnu.org; Wed, 18 Dec 2024 11:30:25 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNwwJ-0002Ca-7h; Wed, 18 Dec 2024 11:30:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=7dNCfhkblOuBMQsAyJjIYP53ekKgbRAXDjjawMSLrnE=; b=gLPH4xuPEm745WTKGViI 2+oHrau8mEDpN5OzMfh8xfMJJTXg+XESvO1VkN0rGXvntVMZDTkrprM3dEQVyrv8pI/FjidZrwql2 2GnmeBzBSI+8IATCKNNsu82XbQYjPV3Rb43VMe1MUCQ6YqbbeU+peRyWweX15O33QqQeArjx6W3zq /HPeTk498uPfdZQzBDNg0K2w/2FtbTo2EQN9bcJIg9yrXludg9Ctt33+/SY4OMkqAeg4zhtInOkbk H6DdS8pWhaHoW0rhNzhkuoVYSA1rqTn95+LNnKq1iB3IuMhqWPzjSB5nGKXJ3gWAo3czD1HXOT1ch COBdq+sg4OoE8g==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 18 Dec 2024 17:01:35 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326664 Archived-At: > From: Gerd Möllmann > Cc: Jared Finder , Stefan Kangas > , Andrea Corallo , > emacs-devel@gnu.org, rudalics@gmx.at > Date: Wed, 18 Dec 2024 17:01:35 +0100 > > Eli Zaretskii 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.