git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Cherry-picking commits with empty messages

From
Angus Hammond <angusgh@gmail.com>
Date
Aug 1, 2012, 18:15 UTC
Message-ID
<CAOBOgRZ9Ouan2htT9m3qBrUvae3nT1az3A61kiRMSJNyFv1MdQ@mail.gmail.com>
In-Reply-To
<7vd33afqjh.fsf@alter.siamese.dyndns.org>
Show 10 quoted lines
>    But from the bigger UI consistency point of view, it would be
>    chaotic to change the default of some options for a single
>    command depending on the nature of the operand, so I would
>    recommend against going this route, and pick one view between
>    "give the user a chance to fix" or "the user must have done so on
>    purpose" and apply it consistently.
>
> My recommendation, backed by the above line of thought, is to add
> support for the "--allow-empty-message" option to both "rebase [-i]"
> and "cherry-pick", defaulting to false.

Though I completely agree regarding having a consistent UI that doesn't change it's behaviour based on the operand, I'd argue that --allow-empty-message should default to true on cherry-pick for a couple or reasons. Firstly, in the case that git perpetuates an empty commit message that the user does not want, it is only damaging a repository in a way that it is already damaged, clearly this still isn't ideal, but it's certainly not as bad as damaging a repository that's pristine. Arguably it's the user's responsibility to ensure they don't TELL git to perpetuate their own bad commit.

Secondly, I'd don't like the idea of a command that 99.9% of the time will run completely independently, but then every so often will become interactive. This is probably a rare enough scenario that script writers would reasonably assume that cherry-pick (without the --allow-empty-message flag) is not an interactive command and write their scripts accordingly. A user who made use of empty commit messages would find any such scripts crashing on them or producing strange results. Even if this is the fringe case, it seems to be a substantially worse fringe case than that where we make a commit that has no message at the user's instruction.

Thanks Angus

Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 11 in “Cherry-picking commits with empty messages”
  1. Chris WebbAug 1, 2012
  2. Junio C HamanoAug 1, 2012
  3. Angus HammondAug 1, 2012
  4. Junio C HamanoAug 1, 2012
  5. Angus HammondAug 2, 2012
  6. Chris WebbAug 2, 2012
  7. cherry-pick: add --allow-empty-message optionChris Webb, Aug 2, 2012
  8. Neil HormanAug 6, 2012
  9. Chris WebbAug 6, 2012
  10. Neil HormanAug 6, 2012
  11. Neil HormanAug 3, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.