What did you do before the bug happened? (Steps to reproduce your issue)

What did you do before the bug happened? (Steps to reproduce your issue)

[Vojtěch Knyttl]

What did you do before the bug happened? (Steps to reproduce your issue)

1. Create a commit with hash-issueId, eg. '#87 Fix wrong indent'
2. Create a second commit with any commit message.
3. Use interactive rebase and 'f'ixup the second commit to the first one.

What did you expect to happen? (Expected behavior)

I expect a single commit with message: '#87 Fix wrong indent'

What happened instead? (Actual behavior)

There is a commit with empty commit message. This happens without any
warning and one notices even too late.

What's different between what you expected and what actually happened?

The commit message disappeared as it was probably treated as a comment.

Anything else you want to add:

[System Info]
git version:
git version 2.28.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11
PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64
compiler info: clang: 11.0.3 (clang-1103.0.32.62)
libc info: no libc information available
$SHELL (typically, interactive shell): /usr/local/bin/bash

[Enabled Hooks]
pre-commit

Re: What did you do before the bug happened? (Steps to reproduce your issue)

[SZEDER Gábor]

Thanks for your report!

On Mon, Nov 30, 2020 at 11:11:20PM +0100, Vojtěch Knyttl wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
> 1. Create a commit with hash-issueId, eg. '#87 Fix wrong indent'

Note that to end up with an empty commit message after the fixup it's
important to have a single-line commit message starting with a '#'
character.

> 2. Create a second commit with any commit message.
> 3. Use interactive rebase and 'f'ixup the second commit to the first one.
> 
> What did you expect to happen? (Expected behavior)
> 
> I expect a single commit with message: '#87 Fix wrong indent'

I agree that this is indeed the desired behavior, because 'git rebase'
should not cleanup unmodified commit messages.

It used to work before 18633e1a22 (rebase -i: use the rebase--helper
builtin, 2017-02-09) (released in v2.13.0), but after that it errored
out with "Aborting commit due to empty commit message" [1].

The scripted interactive rebase created fixup commits with 'git commit
--amend --no-verify -F <file>', which uses the 'whitespace' cleanup
mode, and thus didn't remove comments.  The builtin interactive
rebase/sequencer, however, invoked 'git commit -n --amend -F <file>
--cleanup=strip', i.e. it explicitly specified that comments must be
removed.


[1] The current behavior (i.e. empty commit message instead of that
    error) is the result of b00bf1c9a8 (git-rebase: make
    --allow-empty-message the default, 2018-06-27) (released in
    v2.19.0).



> What happened instead? (Actual behavior)
> 
> There is a commit with empty commit message. This happens without any
> warning and one notices even too late.
> 
> What's different between what you expected and what actually happened?
> 
> The commit message disappeared as it was probably treated as a comment.
> 
> Anything else you want to add:
> 
> [System Info]
> git version:
> git version 2.28.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Darwin 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11
> PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64
> compiler info: clang: 11.0.3 (clang-1103.0.32.62)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /usr/local/bin/bash
> 
> [Enabled Hooks]
> pre-commit