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".
next prev parent 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).