From: Théo Maillart Date: Tue, 02 Aug 2022 22:22:56 GMT Subject: Re: [PATCH] rebase: introduce allow-inline-reword option Message-ID: <2a7040a4-20ce-495d-4182-089c6c08fbd6@gmail.com> In-Reply-To: On 8/2/22 17:23, Junio C Hamano wrote: > "Théo MAILLART via GitGitGadget" writes: > >> This new option (false by default) for interactive rebase allows users >> to modify the subject of a commit directly in the todo list, when they >> select the "reword" action. >> If the option is enabled, "reword" is selected and the subject has not >> changed, then the default behaviour is used. >> It also introduces a test for this specific option, and a related >> function (set_inline_reword_editor) in the lib-rebase.sh to use a >> simpler custom fake editor to be able to modify the message part of the >> lines in a todo list (in the most simple cases). >> >> Signed-off-by: Théo Maillart >> --- >> [RFC] rebase: reword: new feature change the subject in the todo list > It is not clear if you meant this as a final submission or an RFC > but I'll take it as an RFC for now. > > A handful of things come to my mind. > > * Would this want to be a new variant of "reword" that you would > write into the todo list file, instead of a command line option > that says "every 'reword' I write in the todo list file means > something different now"? > > * Is there a plausible UI that allows inline editing of a commit > log message that is more than one line long? Should there be? > > * Under "inline" mode, when a "reword" is requested for a commit > that has more than one line of log message, what should happen? > Should the updated title become the ONLY content of the log of > the updated commit? Should it be an error, because it is clearly > an information-losing operation? Would it make sense to turn the > "inline" reword into normal reword automatically for a commit > with more than one line of log message? > > * If we choose to special case a commit with more than one line of > message in order to prevent the 'inline' mode from losing > valuable information in the original commits, what role should > trailer lines play when we decide if a commit has only one line > of message? For example, if a lazy "title only" commit has no > body message but a sign-off and other trailers like helped-by, > would it make sense to keep the trailers intact and only replace > the title, still in inline mode? I agree, taking care of more than the commit subject only does not look like an easy task, and I'm probably not the right person to do this in a reasonable amount of time. > > Here is an alternative design that may be conceptually cleaner. > > * We do not introduce a new option at all. "reword" means "open > the editor and you can edit the whole thing" as always. > > * We introduce "retitle" that can be used instead of "reword". > > The line for a commit originally shows "pick" followed by an > abbreviated commit object name followed by its title, and the > body of the message and the trailer is hidden. If you change > "pick" to "retitle" and edit the shown title, then the original > log message from the commit is read as a whole, its title line is > replaced with what "retitle" line has, and the result is used as > the updated log message. > > That way, those who write more than one line of commit log message > can still use the feature without having to worry about losing > information when the only thing they want to fix is a typo in the > title, and those who write only one line of commit log message do > not have to pass the new "--inline" option at all. They can use > 'retitle' instead of 'reword'. > > Hmm? > So, if I understand your suggestion correctly, we can say that, most of the logic is implemented in this patch, but I should move the "inline" logic from the "reword" to a new action "retitle". If it is ok with you, I will look into that, and get back with a new patch. The only thing that seems unfortunate to me is that we will have a hard time finding a meaningful short name for this new action in the todo list, as "r" is for "rename".