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

Re: what should "git clean -n -f [-d] [-x] <pattern>" do?

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 24, 2024, 17:21 UTC
Message-ID
<xmqqa5ouhckj.fsf@gitster.g>
In-Reply-To
<87plxr3zsr.fsf@osv.gnss.ru>
Sergey Organov <sorganov@gmail.com> writes:
> Whereas obsoleting second -f in favor of new --nested-repo might be a
> good idea indeed, I believe it's still a mistake for "dry run" to
> somehow interfere with -f, sorry.
No need to be sorry ;-)

I actually think the true culprit of making this an odd-man-out is that the use of "-f" in "git clean", especially with its use of the configuration variable clean.requireForce that defaults to true, is utterly non-standard.

The usual pattern of defining what "-f" does is that the "git foo" command without any options does its common thing but refuses to perform undesirable operations (e.g. "git add ." adds everything but refrains from adding ignored paths). And "git foo -f" is a way to also perform what it commonly skips.

In contrast, with clean.requireForce that defaults to true, "git clean" does not do anything useful by default. Without such a safety, "git clean" would be a way to clean expendable paths, and "git clean -f" might be to also clean precious paths. But it does not work that way. It always requires "-f" to do anything. Worse yet, it is not even "by default it acts as if -n is given and -f is a way to countermand that implicit -n". It is "you must give me either -f (i.e. please do work) or -n (i.e. please show what you would do) before I do anything".

  $ git clean
  fatal: clean.requireForce defaults to true and neither -i, -n, nor -f given; refusing to clean

Given that, it is hard to argue that it would be a natural end-user expectation that the command does something useful (i.e. show what would be done) when it is given "-f" and "-n" at the same time. What makes this a rather nonsense UI is the fact that "-f" does not work the way we would expect for this command.

Previous: Sergey OrganovNext: Sergey Organov
Message 7 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.