public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Jean-Noël AVILA" <avila.jn@gmail.com>,
	"Kristoffer Haugsbakk" <code@khaugsbakk.name>
Subject: Re: [PATCH v2] clean: improve -n and -f implementation and documentation
Date: Mon, 04 Mar 2024 23:19:12 +0300	[thread overview]
Message-ID: <87sf157nsv.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqo7btom4u.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 04 Mar 2024 11:03:13 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>>> The reason for the behaviour can be explained this way:
>>>
>>>  * "git clean" (with neither -i nor -n.  The user wants the default
>>>    mode that has no built-in protection will be stopped without -f.
>>>
>>>  * "git clean -n".  The user wants the dry-run mode that has its own
>>>    protection, i.e. being always no-op to the files, so there is no
>>>    need to fail here for the lack of "-f".
>>>
>>>  * "git clean --interactive".  The user wants the interactive mode
>>>    that has its own protection, i.e. giving the end-user a chance to
>>>    say "oh, I didn't mean to remove these files, 'q'uit from this
>>>    mistake", so there is no need to fail here for the lack of "-f".
>>
>> Well, if we remove -i from error message as well, then yes, this makes
>> sense.
>> ...
>> I then suggest to consider to remove mention of -i from
>> clean.requireForce description as well.
>
> The follow-up patch you just reviewed in the other thread does
> exactly that.

Yeah, the follow-up patch somehow didn't thread correctly with original
discussion, so I've noticed it only after I wrote the above, and the
patch is fine indeed.

>
> This is a tangent, but before finalizing the version that complains
> "clean.requireForce is in effect and you did not give me -f" without
> mentioning "-i" or "-n", I asked gemini.google.com to proofread the
> patch and and one of its suggestion was to use this:
>
>     "clean.requireForce is true.  Use -f to override, or consider
>     using -n (dry-run) or -i (interactive) for a safer workflow."
>
> as a possibly cleaner message.  It is the opposite of what both of
> us concluded to be good in this exchange, but in some sense, it does
> sound more helpful to end users, which I somehow found amusing.

The added advice looks fine to me, as it explicitly separates -f from
the other ways of using "git clean". However, starting phrase with
"clean.requireForce is true" sounds strange. I'd rather say:

   "Refusing to remove files: use -f to force removal. Alternatively,
   consider using -n (dry-run) or -i (interactive) for a safer workflow.
   Set clean.requireForce to false to get rid of this message"

Here we first state what has happened, and then mention solutions in
most-probable-first order.

However, if I were gemini, I'd probably start from noticing that no
error message is required at all unless there is something to delete in
the first place. I.e., the error should probably occur not here, but
rather at every attempt to delete, and then explanation should be given
later, e.g.:

  Refusing to remove FILE1
  Refusing to remove FILE2

  No files were removed: use -f to force removal. Alternatively,
  consider using -n (dry-run) or -i (interactive) for a safer workflow.

  Set clean.requireForce to false to disable this protection.

With this, user effectively gets functionality similar to "git clean -n"
by default.

Just saying.

Thanks,
-- Sergey Organov

  reply	other threads:[~2024-03-04 20:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7le6ziqzb.fsf_-_@osv.gnss.ru>
2024-03-03 22:05 ` [PATCH v2] clean: improve -n and -f implementation and documentation Junio C Hamano
2024-03-03 22:06   ` [PATCH 1/1] clean: further clean-up of implementation around "--force" Junio C Hamano
2024-03-03 22:18     ` Junio C Hamano
2024-03-04 18:46     ` Sergey Organov
2024-03-04 18:39   ` [PATCH v2] clean: improve -n and -f implementation and documentation Sergey Organov
2024-03-04 18:41     ` Junio C Hamano
2024-03-04 18:48       ` Sergey Organov
2024-03-04 19:03     ` Junio C Hamano
2024-03-04 20:19       ` Sergey Organov [this message]
2024-01-09 20:20 what should "git clean -n -f [-d] [-x] <pattern>" do? Junio C Hamano
2024-02-29 19:07 ` [PATCH] clean: improve -n and -f implementation and documentation Sergey Organov
2024-03-03  9:50   ` [PATCH v2] " Sergey Organov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sf157nsv.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=avila.jn@gmail.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox