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

Re: [PATCH] clean: improve -n and -f implementation and documentation

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 1, 2024, 18:07 UTC
Message-ID
<xmqqmsrh6d2f.fsf@gitster.g>
In-Reply-To
<51a196c0-ea57-4ec5-99ea-c3f09cd90962@gmail.com>
Jean-Noël Avila <avila.jn@gmail.com> writes:
>> +	/* Dry run won't remove anything, so requiring force makes no sense */
>> +	if(dry_run)
>> +		require_force = 0;
Style.  "if (dry_run)".

Getting rid of "config_set", which was an extra variable that kept track of where "force" came from, does make the logic cleaner, I guess. What we want to happen is that one of -i/-n/-f is required when clean.requireForce is *not* unset (i.e. 0 <= require_force).

>> +	if (!force && !interactive) {

The require-force takes effect only when neither force or interactive is given, so the new code structure puts the above obvious conditional around "do we complain due to requireForce?" logic. Sensible.

>> +		if (require_force > 0)
>> +			die(_("clean.requireForce set to true and neither -f, nor -i given; "
>> +				  "refusing to clean"));
If it is explicitly set, we get this message.  And ...
>> +		else if (require_force < 0)
>> +			die(_("clean.requireForce defaults to true and neither -f, nor -i given; "
>>  				  "refusing to clean"));

... if it is set due to default (in other words, if it is not unset), we get this message.

As you said, I do not think it matters too much either way to the end-users where the truth setting of clean.requireForce came from, either due to the default or the user explicitly configuring. So unifying to a single message may be helpful to both readers and translators.

	clean.requireForce is true; unless interactive, -f is required
might be a bit shorter and more to the point.
> The last two cases can be coalesced into a single case (the last one),
> because the difference in the messages does not bring more information
> to the user.
Yeah.
Thanks.
Previous: Sergey OrganovNext: Junio C Hamano
Message 33 of 38 in “what should "git clean -n -f [-d] [-x] <pattern>" do?”
  1. Junio C HamanoJan 9, 2024
  2. Sergey OrganovJan 9, 2024
  3. Elijah NewrenJan 19, 2024
  4. Sergey OrganovJan 23, 2024
  5. Junio C HamanoJan 23, 2024
  6. Sergey OrganovJan 24, 2024
  7. Junio C HamanoJan 24, 2024
  8. Sergey OrganovJan 25, 2024
  9. Junio C HamanoJan 25, 2024
  10. Sergey OrganovJan 25, 2024
  11. Sergey OrganovJan 25, 2024
  12. Junio C HamanoJan 26, 2024
  13. Sergey OrganovJan 26, 2024
  14. Junio C HamanoJan 27, 2024
  15. Sergey OrganovJan 27, 2024
  16. Kristoffer HaugsbakkJan 29, 2024
  17. Sergey OrganovJan 31, 2024
  18. Sergey OrganovJan 29, 2024
  19. Jeff KingJan 29, 2024
  20. Sergey OrganovJan 29, 2024
  21. Jeff KingJan 30, 2024
  22. Junio C HamanoJan 30, 2024
  23. clean: improve -n and -f implementation and documentationSergey Organov, Feb 29, 2024
  24. Jean-Noël AvilaMar 1, 2024
  25. Sergey OrganovMar 1, 2024
  26. Kristoffer HaugsbakkMar 1, 2024
  27. Junio C HamanoMar 1, 2024
  28. Jean-Noël AVILAMar 2, 2024
  29. Sergey OrganovMar 2, 2024
  30. Junio C HamanoMar 2, 2024
  31. Sergey OrganovMar 2, 2024
  32. Sergey OrganovMar 3, 2024
  33. Junio C HamanoMar 1, 2024
  34. Junio C HamanoMar 1, 2024
  35. Sergey OrganovMar 1, 2024
  36. Junio C HamanoMar 2, 2024
  37. Sergey OrganovMar 2, 2024
  38. clean: improve -n and -f implementation and documentationSergey Organov, Mar 3, 2024

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.