threads / bug / 54733

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

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

## tl;dr

2 messages between Nov 30, 2020 and Dec 1, 2020.

replies: 1people: 2as markdown or json

Vojtěch Knyttl· Nov 30, 2020, 22:11 UTC · lore
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

SZEDER Gábor· Dec 1, 2020, 00:19 UTC · re: Vojtěch Knyttl · lore

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

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.

Show 6 quoted lines
> 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).
Show 27 quoted lines
> 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

← back to recent threads