Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Jiang Xin
2013/4/27 Junio C Hamano :
> Junio C Hamano  writes:
>
>> Matthieu Moy  writes:
>>
>>> The nice thing with the confirmation dialog is that it shows the list
>>> before asking (and unlike 'rm -i', it asks only once).
>>
>> I wouldn't object to having "clean -i", which automatically defeats
>> the requireforce option.
>>
>> As to a huge single list you have to approve or reject as a whole, I
>> am on the fence.  When running "rm -i", I often wished to see
>> something like that, but I am fairly sure that I'll call it unusable
>> the first time I see a list with a few items I want to keep while
>> removing all others.
>
> Elaborating on this a bit more, hoping it would help people who want
> to design the "--confirm-before-doing" option...
>
> The primary reason I think the user will find "We are going to
> remove these.  OK?" irritating is that most of the time, there are
> only a few items that the user would want to keep.
>
> $ rm --confirm-before-doing -r path
> ... list of three dozens of items, among which
> ... there may be two items that should be kept
> Remove all? [Y/n]
>
> After seeing this prompt and saying 'n', the user would _not_ thank
> the command for reminding about these precious two items, because
> the only next step available to the user is to remove the remaining
> 34 items manually.
>
> "Confirm in bulk before doing" feature can become useful if it had a
> "line item veto" option in the confirmation time.  The interaction
> then could go like this:
>
> $ rm --confirm-before-doing -r path
> path/foopath/frotz/nitfolpath/sotto
> path/barpath/frotz/xyzzy path/trail
> ......   ...
> Remove (list items you want to keep)? path/frotz
>
> and the user could instruct it to remove everything other than those
> inside path/fortz.  If the user do not want to remove anything,
> there is an option to ^C out of the command.

Agree. I will send a reroll latter.

-- 
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Junio C Hamano
Junio C Hamano  writes:

> Matthieu Moy  writes:
>
>> The nice thing with the confirmation dialog is that it shows the list
>> before asking (and unlike 'rm -i', it asks only once).
>
> I wouldn't object to having "clean -i", which automatically defeats
> the requireforce option.
>
> As to a huge single list you have to approve or reject as a whole, I
> am on the fence.  When running "rm -i", I often wished to see
> something like that, but I am fairly sure that I'll call it unusable
> the first time I see a list with a few items I want to keep while
> removing all others.

Elaborating on this a bit more, hoping it would help people who want
to design the "--confirm-before-doing" option...

The primary reason I think the user will find "We are going to
remove these.  OK?" irritating is that most of the time, there are
only a few items that the user would want to keep.

$ rm --confirm-before-doing -r path
... list of three dozens of items, among which
... there may be two items that should be kept
Remove all? [Y/n]

After seeing this prompt and saying 'n', the user would _not_ thank
the command for reminding about these precious two items, because
the only next step available to the user is to remove the remaining
34 items manually.

"Confirm in bulk before doing" feature can become useful if it had a
"line item veto" option in the confirmation time.  The interaction
then could go like this:

$ rm --confirm-before-doing -r path
path/foopath/frotz/nitfolpath/sotto
path/barpath/frotz/xyzzy path/trail
......   ... 
Remove (list items you want to keep)? path/frotz

and the user could instruct it to remove everything other than those
inside path/fortz.  If the user do not want to remove anything,
there is an option to ^C out of the command.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Junio C Hamano
Matthieu Moy  writes:

> The nice thing with the confirmation dialog is that it shows the list
> before asking (and unlike 'rm -i', it asks only once).

I wouldn't object to having "clean -i", which automatically defeats
the requireforce option.

As to a huge single list you have to approve or reject as a whole, I
am on the fence.  When running "rm -i", I often wished to see
something like that, but I am fairly sure that I'll call it unusable
the first time I see a list with a few items I want to keep while
removing all others.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Matthieu Moy
Junio C Hamano  writes:

> "git clean" without -n/f errors out, hinting the availablilty of -n
> while mentioning -f; that is the safety, isn't it?  Once the user
> decides to give -f, the user _wants_ to remove cruft, and it is a
> hinderance to require any further confirmation.

This is only half true: because "git clean" does nothing without -f,
people's fingers get trained to type "git clean -f" without really
thinking about it. Just like people alias rm='rm -i' and then type
"rm -fr *" mechanically.

The nice thing with the confirmation dialog is that it shows the list
before asking (and unlike 'rm -i', it asks only once).

But as I said in another thread, I fully agree that adding the
confirmation by default even with -f is nonsense.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Junio C Hamano
Jiang Xin  writes:

> I don't know how many programmers had been bitten by runing `git clean -fdx`,
> but I bet there were some. I think safety should be put to the 1st place.

"git clean" without -n/f errors out, hinting the availablilty of -n
while mentioning -f; that is the safety, isn't it?  Once the user
decides to give -f, the user _wants_ to remove cruft, and it is a
hinderance to require any further confirmation.

Your problem description sounds like that you want to drive without
wearing seatbelts but in case you get in a collision, you suggest to
make the seat automatically stick to the back of anybody who sits on
it with superglue to make it safer.

That approach might give it an alternative safety, but it would make
it extremely annoying if you apply it also to people who do wear
belts, no?

This extra confirmation should never be the default.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Jiang Xin
2013/4/26 Matthieu Moy :
> Jiang Xin  writes:
>
>> Maybe we can do like this:
>>
>> 1. Set the default value of 'clean.requireForce' to false.
>> 2. Show a error message and do nothing, if there is not 'clean.requireForce'
>> setting, but the user called with a '--force' flag.
>> ( like a transition for the change of push.default in git 2.0)
>
> Perhaps introducing a new value for 'clean.requireForce':
>
> $ git config --global clean.requireForce ask
> $ git clean
> .will remove ...
> are you sure [y/N]?
>
> The error message when clean.requireForce is unset and --force is not
> given could point the user to clean.requireForce=ask.

Add new value for clean.requireForce would break old git clent.

   $ git clean
   fatal: bad config value for 'clean.requireforce' in .git/config

>
> Then, maybe, later, this could become the default. But I tend to like
> the non-interactive nature of most Git commands, so I'm a bit reluctant
> here. My way of doing the confirmation dialog is
>
> $ git clean -n
> would remove ...
> $ git clean -f
>

I try to put all cases in one table, but still looks weird.

| clean.requireForce  | git clean | git clean --force |
+-+---|---|
| TRUE| error | delete... |
+-+---|---|
| FALSE   | delete... | delete... |
+-+---|---|
| unset   | confirm   | warn + confirm|
+-+---|---|

Does anyone really set and use "clean.requireForce" setting?
And if there is a confirm dialog, do we need 'clean.requireForce' any more?
Or we can add a `--no-ask` option, in order to override the confirm dialog.


> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/



--
蒋鑫

北京群英汇信息技术有限公司
邮件: worldhello@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 18601196889
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Thomas Rast
Jiang Xin  writes:

> I don't know how many programmers had been bitten by runing `git clean -fdx`,
> but I bet there were some. I think safety should be put to the 1st place.
> It is because "clean.requireForce" defaults to true, all people trend to run
> 'git clean' with the '--force/-f' option.

But if that's the real problem, wouldn't it be better to introduce
something like clean.requireForce=interactive (or 'ask', or whatever you
make up) which will be like clean.requireForce=true except that when on
a TTY, we ask the user?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Matthieu Moy
Jiang Xin  writes:

> Maybe we can do like this:
>
> 1. Set the default value of 'clean.requireForce' to false.
> 2. Show a error message and do nothing, if there is not 'clean.requireForce'
> setting, but the user called with a '--force' flag.
> ( like a transition for the change of push.default in git 2.0)

Perhaps introducing a new value for 'clean.requireForce':

$ git config --global clean.requireForce ask
$ git clean
will remove ...
are you sure [y/N]?

The error message when clean.requireForce is unset and --force is not
given could point the user to clean.requireForce=ask.

Then, maybe, later, this could become the default. But I tend to like
the non-interactive nature of most Git commands, so I'm a bit reluctant
here. My way of doing the confirmation dialog is

$ git clean -n
would remove ...
$ git clean -f

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Jiang Xin
2013/4/26 Matthieu Moy 
>
> Jiang Xin  writes:
>
> >  * run `git clean` in interactive sessions,
> >  * not a dry run,
> >  * and not quiet.
>
> Err, does this mean I'll have:
>
> $ git clean
> fatal: clean.requireForce defaults to true and neither -n nor -f given; 
> refusing to clean
> $ git clean --force

( you omit something, because nothing to clean won't trigger this
confirm dialog)

> Are you sure [y/n]?
>
> An optional confirmation dialog seems interesting, but activating it by
> default even with --force seems really weird.

I don't know how many programmers had been bitten by runing `git clean -fdx`,
but I bet there were some. I think safety should be put to the 1st place.
It is because "clean.requireForce" defaults to true, all people trend to run
'git clean' with the '--force/-f' option.

Maybe we can do like this:

1. Set the default value of 'clean.requireForce' to false.
2. Show a error message and do nothing, if there is not 'clean.requireForce'
setting, but the user called with a '--force' flag.
( like a transition for the change of push.default in git 2.0)

any opinions?

>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/




--
蒋鑫

北京群英汇信息技术有限公司
邮件: worldhello@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 18601196889
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] clean: confirm before cleaning files and directories

2013-04-26 Thread Matthieu Moy
Jiang Xin  writes:

>  * run `git clean` in interactive sessions,
>  * not a dry run,
>  * and not quiet.

Err, does this mean I'll have:

$ git clean
fatal: clean.requireForce defaults to true and neither -n nor -f given; 
refusing to clean
$ git clean --force
Are you sure [y/n]?

An optional confirmation dialog seems interesting, but activating it by
default even with --force seems really weird.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html