git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Théo Maillart" <tmaillart@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>,
	"Théo MAILLART via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] rebase: introduce allow-inline-reword option
Date: Wed, 3 Aug 2022 00:22:56 +0200	[thread overview]
Message-ID: <2a7040a4-20ce-495d-4182-089c6c08fbd6@gmail.com> (raw)
In-Reply-To: <xmqqles6is9s.fsf@gitster.g>


On 8/2/22 17:23, Junio C Hamano wrote:
> "Théo MAILLART via GitGitGadget"<gitgitgadget@gmail.com>  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@gmail.com>
>> ---
>>      [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".


  reply	other threads:[~2022-08-02 22:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  6:39 [PATCH] rebase: introduce allow-inline-reword option Théo MAILLART via GitGitGadget
2022-08-02 15:23 ` Junio C Hamano
2022-08-02 22:22   ` Théo Maillart [this message]
2022-08-02 22:36     ` Junio C Hamano
2022-08-02 22:59       ` Eric Sunshine
2022-08-03 14:16 ` Phillip Wood
2022-08-04  7:57 ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a7040a4-20ce-495d-4182-089c6c08fbd6@gmail.com \
    --to=tmaillart@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).