Git Feature Request (Commit Message editing directly from interactive rebase control file)

Git Feature Request (Commit Message editing directly from interactive rebase control file)

[Mike McLean]

I initially raised this as a FR with my git UI of choice, and was told
that it was actually something that git itself would need to do ...
and that the standard way to raise Feature Requests was to email this
list.

Apologies if that's not actually what I should be doing - please let
me know if this is not an intended use.

=-=-=-=-=-=-=-=-=-=
When you do an interactive rebase, you are presented with a file
listing all the commit hashes, their current message, and the
command/operation to perform.

To edit the commit message you set operation `r` and then are later
given the opportunity to set the message. But that control file is
only using the commit hashes to determine which commit is being
referenced - the message text in that file isn't being used to
identify the message.

So can we allow the user to (optionally) set the new message directly
in that file?

It would make the flow a lot quicker (don't have to open a new editor
instance each time.), and would make it a lot easier to make similar
changes to a bunch of commits (e.g. prefixing them all with Ticket
number, or fixing a consistent typo in a bunch of commits.)

Indicator that the commit-rename should use the text in the control
file (rather than the later editor prompt) could either be A) a new
command (rename-inline, or similar) or B) existing rename command +
"the text on this line is different from the text on the original
commit".

Obviously this wouldn't support multiline commit messages - those
would still use the existing workflow, but adding this new feature
wouldn't impinge upon them, so they've not lost anything.

Am happy to suggest names and/or shorthand keys for it, if the idea is
acceptable.

Yours,
Brondahl

Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)

[Junio C Hamano]

Mike McLean <stixmclean@googlemail.com> writes:

> I initially raised this as a FR with my git UI of choice, and was told
> that it was actually something that git itself would need to do ...
> and that the standard way to raise Feature Requests was to email this
> list.
>
> Apologies if that's not actually what I should be doing - please let
> me know if this is not an intended use.
>
> =-=-=-=-=-=-=-=-=-=
> When you do an interactive rebase, you are presented with a file
> listing all the commit hashes, their current message, and the
> command/operation to perform.

Each commit is shown only with their title, but does not show the
full message, exactly because the text is merely there to help the
user identify which commits are being shown and manipulated.

> ...
> So can we allow the user to (optionally) set the new message directly
> in that file?

I suspect that such a "feature" would encourage people to use a
single liner commit log message, that is only the title, so that
they do not have to worry about the real log message in the body.
And it does not particularly feel a good behaviour that we'd want to
encourage.  So, I dunno.

Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On 2020-12-23 at 23:07:43, Mike McLean wrote:
> Indicator that the commit-rename should use the text in the control
> file (rather than the later editor prompt) could either be A) a new
> command (rename-inline, or similar) or B) existing rename command +
> "the text on this line is different from the text on the original
> commit".
> 
> Obviously this wouldn't support multiline commit messages - those
> would still use the existing workflow, but adding this new feature
> wouldn't impinge upon them, so they've not lost anything.

I know people tend to do this quite frequently, but it's extremely
uncommon for me to write such a message.  I normally write a reasonably
verbose commit message, and in the vast majority of the cases where the
change is so trivial that I write a single-line commit message, I'm on a
project with sign-offs, so this wouldn't work there.

That doesn't mean that this couldn't be useful in some cases, but I
think we're likely to encourage single-line commit messages, which I
don't think we want to do in the general case, or cause user confusion
when their commit message inline is either (a) truncated unexpectedly or
(b) not honored because the message is already multiline.  So I feel
like such a feature is a foot-gun waiting to happen.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)

[Mike McLean]

These seem fair concerns.

Detailed multi-line commits are something that I know exist, but I've
never seen much need or use for, personally, and no project teams I've
ever worked on have used them.
But if that's the declared preferred-approach then I agree that this
feature would be actively detrimental to that and thus is not
appropriate.

Thanks for the responses!

On Thu, Dec 24, 2020 at 12:06 AM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2020-12-23 at 23:07:43, Mike McLean wrote:
> > Indicator that the commit-rename should use the text in the control
> > file (rather than the later editor prompt) could either be A) a new
> > command (rename-inline, or similar) or B) existing rename command +
> > "the text on this line is different from the text on the original
> > commit".
> >
> > Obviously this wouldn't support multiline commit messages - those
> > would still use the existing workflow, but adding this new feature
> > wouldn't impinge upon them, so they've not lost anything.
>
> I know people tend to do this quite frequently, but it's extremely
> uncommon for me to write such a message.  I normally write a reasonably
> verbose commit message, and in the vast majority of the cases where the
> change is so trivial that I write a single-line commit message, I'm on a
> project with sign-offs, so this wouldn't work there.
>
> That doesn't mean that this couldn't be useful in some cases, but I
> think we're likely to encourage single-line commit messages, which I
> don't think we want to do in the general case, or cause user confusion
> when their commit message inline is either (a) truncated unexpectedly or
> (b) not honored because the message is already multiline.  So I feel
> like such a feature is a foot-gun waiting to happen.
> --
> brian m. carlson (he/him or they/them)
> Houston, Texas, US

Re: Git Feature Request (Commit Message editing directly from interactive rebase control file)

[Theodore Y. Ts'o]

On Thu, Dec 24, 2020 at 12:17:26AM +0000, Mike McLean wrote:
> These seem fair concerns.
> 
> Detailed multi-line commits are something that I know exist, but I've
> never seen much need or use for, personally, and no project teams I've
> ever worked on have used them.
> But if that's the declared preferred-approach then I agree that this
> feature would be actively detrimental to that and thus is not
> appropriate.

The preferred approach is a single line summary of the commit,
followed by a body of text explaining the "why" of a commit.  In some
cases, the "why" may be several paragraphs explaining a one line
change.  For example, in this commit, see how much explanation was
given for a single _character_ change:

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=5a3b590d4b2db187faa6f06adc9a53d6199fb1f9

Having detailed messages is critically important; since even the
commit author is not likely to remember all of the details of a
particular change a even few months later --- and when examining
changes that was made by others, sometimes years latter, context can
be critical to understanding what was going on.

Certainly, if I were reviewing some public git repository belonging to
someone who was interviewing for a position at $WORK, and they had one
line commit descriptions, I personally would consider that to be a
signal that their software engineering skills might be lacking.
Having good commit descriptions is right up there with having good
regression tests and having a second engineer do code reviews (which
include reviewing the commit description for sufficiency) as part of
basic software development practice.

Cheers,

					- Ted