Re: [PATCH] rebase: introduce allow-inline-reword option

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

 



"Théo MAILLART via GitGitGadget"  <gitgitgadget@xxxxxxxxx> 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 <tmaillart@xxxxxxxxx>
> ---
>     [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?

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?




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux