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

Re: [PATCH v2] sequencer: replace error() with BUG() in update_squash_messages()

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Jun 2, 2025, 13:59 UTC
Message-ID
<eba62aad-a396-46d9-9a37-3521e4e7a23e@gmail.com>
In-Reply-To
<xmqq1ps6iuw0.fsf@gitster.g>
On 30/05/2025 05:29, Junio C Hamano wrote:
Show 30 quoted lines
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>>> OK.  Or
>>> 	if (!is_fixup(command))
>>> 		BUG("not a FIXUP or SQUASH %d", command);
>>> at the very beginning of the function?
>>
>> Asserting the precondition at the start of the function sounds like a
>> good idea
> 
> I am of two minds.
> 
> I do not know if this is better for longer-term maintainability or
> not.  Such a message at the beginning of the function declares that
> the current implementation does not want to receive a command that
> is not either of these two.  Such a message tells the next developer
> who adds another caller to the function to make sure not to pass
> other commands, which is good.
> 
> But I do not know what it tells to the next developer who wants to
> add support for another command.  After opening that initial gate a
> bit wider, perhaps to
> 
> 	if (!is_filxup(command) && !is_my_new_command(command))
> 		BUT("not a FIXUP or SQUASH or MYCOMMAND %d", command);
> 
> would they make sure to handle their new command correctly in the
> if/elseif cascade, from which we are removing the "error()" with
> such a change, and would our reviewers notice if they forget to do
> so?  I dunno.

I guess it cuts both ways. As you say it is a small function and I think someone adding support for a new command would need to do more that just change the precondition to get their code to work unless they're calling this when they don't need to.

> In any case, such a future change will have to be done with a good
> understanding of the entirety of this small function anyway, so I
> guess either way is OK.
Agreed
Phillip
Previous: Junio C HamanoNext: Lidong Yan via GitGitGadget
Message 9 of 18 in “sequencer: fix memory leak if `update_squash_messages()` failed”
  1. sequencer: fix memory leak if `update_squash_messages()` failedLidong Yan via GitGitGadget, May 14, 2025
  2. Phillip WoodMay 15, 2025
  3. Junio C HamanoMay 15, 2025
  4. lidongyanMay 15, 2025
  5. sequencer: replace error() with BUG() in update_squash_messages()Lidong Yan via GitGitGadget, May 25, 2025
  6. Junio C HamanoMay 28, 2025
  7. Phillip WoodMay 29, 2025
  8. Junio C HamanoMay 30, 2025
  9. Phillip WoodJun 2, 2025
  10. 0/2 sequencer: replace error() with BUG() in update_squash_messages()Lidong Yan via GitGitGadget, May 30, 2025
  11. 1/2 sequencer: replace error() with BUG() in update_squash_messages()Lidong Yan via GitGitGadget, May 30, 2025
  12. Junio C HamanoMay 30, 2025
  13. 2/2 BUG(): remove leading underscore of the format stringLidong Yan via GitGitGadget, May 30, 2025
  14. Junio C HamanoMay 30, 2025
  15. 0/2 sequencer: replace error() with BUG() in update_squash_messages()Lidong Yan via GitGitGadget, Jun 3, 2025
  16. 1/2 sequencer: replace error() with BUG() in update_squash_messages()Lidong Yan via GitGitGadget, Jun 3, 2025
  17. 2/2 BUG(): remove leading underscore of the format stringLidong Yan via GitGitGadget, Jun 3, 2025
  18. Junio C HamanoJun 3, 2025

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.