You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Olaf van der Spek <ml...@vdspek.org> on 2016/12/03 17:42:11 UTC
Re: Adopting unversioned directory on svn up
On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <st...@elego.de> wrote:
>> >> For directories it seems like a no-brainer to avoid the conflict.
>> >
>> > Indeed, adding a resolver option for this should not be very difficult.
>>
>> I'd opt for not having a conflict in the first place.
>
> There is a reason the non-conflict behaviour requires the --force option.
> It is perfectly fine for Subversion to be conservative if the alternative
> is to litter all over other people's data.
>
> And this conflict is not very difficult to solve:
>
> When a directory DIR has an "local dir unversioned, incoming dir add upon
> update" conflict, and you want to keep DIR as it was and do not want SVN
> to touch it after all, all you need to do is move DIR out of the working
> copy (with standard operating system tools) to somewhere else and it will
> have been preserved as it was before SVN got involved.
> Then run 'svn revert -R DIR' to put the versioned content in place.
> Note that this solution is not trivial to achieve after update --force
> which might modify unversioned files, requiring the user to edit files
> in DIR back into their original state. This is why --force is not the default.
Are you sure?
In my experience --force does NOT overwrite existing files.
Not overwriting files is safe and exactly what I want.
> As far as I can see, the only nice way to have versioned files merged with
> unversioned files is to use checkout/update with the --force option which
> avoids the tree conflict in the first place. (Running 'svn add DIR' after
> 'svn revert -R DIR' will also merge the files, but schedules an undesirable
> replacement as well.) So this is something the conflict resolver could handle
> in a better way than existing svn commands can.
> However, I'm not very sure how well merging of arbitrary versioned and
> unversioned content generally works out in practice. Is this really more
> useful than one of the other two solutions?
>
> In summary, these are the options the conflict resolver could offer:
> 1) move DIR to another place and restore its versioned content
> 2) discard all unversioned content and put versioned content in place
> 3) merge versioned and unversioned content where paths overlap (like --force)
> Nothing new here, expect the ability to get the same behaviour as with
> update --force after the conflict has been flagged because the user really
> wants to merge the files (why?)
Suppose only directories 'conflict', then there's no danger of
overwriting data and the conflict seems to complicate stuff without
real benefit.
Suppose a file 'conflicts'.. it seems trivial to preserve the existing
file and not mark anything as conflicted. The file will / might show
as modified but that's no problem. No data gets lost.
How do such 'conflicts' happen?
Sometimes a file gets copied / uploaded via SFTP.
Or in the case of me versioning some files in /etc, the system / pkg
installer already created some directories and I'm merely adding some
not yet existing files into them.
> and forgot to use --force.
I wasn't aware of --force before asking this question. --force is
usually used for dangerous stuff as well.
> The biggest advantage of offering such options is that users would not
> have to figure out the resolution steps by themselves.
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Dec 4, 2016 at 10:17 PM, Daniel Shahaf <da...@apache.org> wrote:
> Johan Corveleyn wrote on Sun, Dec 04, 2016 at 18:27:48 +0100:
>> It's impossible to say now which files were there before, and which
>> were added by the checkout (OK, the unversioned items were certainly
>> "local files", but the versioned ones ... who knows?
>
> Couldn't you look for files and empty dirs whose ctime/birthtime is
> newer than that of the .svn dir?
Okay, didn't think of that, good suggestion. But it'll still be some
non-trivial work (if it's a large amount of files) to exploit this to
restore the directory to "before the checkout happened".
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Daniel Shahaf <da...@apache.org>.
Johan Corveleyn wrote on Sun, Dec 04, 2016 at 18:27:48 +0100:
> It's impossible to say now which files were there before, and which
> were added by the checkout (OK, the unversioned items were certainly
> "local files", but the versioned ones ... who knows?
Couldn't you look for files and empty dirs whose ctime/birthtime is
newer than that of the .svn dir?
> Except if you kept the notification output of the checkout, so you can
> select all files with a 'E' notification as "those files should be
> kept when I remove the checkout).
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Dec 04, 2016 at 11:32:47AM +0100, Olaf van der Spek wrote:
> On Sun, Dec 4, 2016 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> > I think the most annoying consequence of accidentally checking out
> > over an existing directory, without any conflict detection (if the
> > --force behaviour would be the default), would be that you cannot
> > easily undo the operation. You haven't lost any unversioned data, but
> > you can not easily remove the checkout again and "rollback" to the
> > state before the checkout.
>
> Happened yesterday, I checked out into / instead of /etc.. svn behaves
> slightly different then rsync I guess.
Yeah that can be annoying to clean up after :-/
> > Suppose you have files a and b locally. And the checkout
> > "incorporates" a and b (say they become unmodified because they are
> > the same as the repository version) and adds c, d, e, f, g, ... Oops,
> > the checkout was accidental. Now how do I remove it again? I don't
> > know which files were there before and which were added by the
> > checkout. Now imagine this happening with a complex tree structure
> > with 10,000 directories and 100,000 files.
>
> Does svn have a command to delete all versioned items?
> If not you still have to 'manually' figure out which directories /
> files came from the checkout and which ones existed before.
SVN can show which files and dirs are unversioned with 'svn status'
and list all versioned files and dirs with 'svn list'. That's good
enough to get a list of things, at least.
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Dec 03, 2016 at 10:11:49PM +0100, Olaf van der Spek wrote:
> On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <st...@elego.de> wrote:
> > On Sat, Dec 03, 2016 at 06:42:11PM +0100, Olaf van der Spek wrote:
> >> On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <st...@elego.de> wrote:
> >> >> >> For directories it seems like a no-brainer to avoid the conflict.
> >> >> >
> >> >> > Indeed, adding a resolver option for this should not be very difficult.
> >> >>
> >> >> I'd opt for not having a conflict in the first place.
> >> >
> >> > There is a reason the non-conflict behaviour requires the --force option.
> >> > It is perfectly fine for Subversion to be conservative if the alternative
> >> > is to litter all over other people's data.
> >> >
> >> > And this conflict is not very difficult to solve:
> >> >
> >> > When a directory DIR has an "local dir unversioned, incoming dir add upon
> >> > update" conflict, and you want to keep DIR as it was and do not want SVN
> >> > to touch it after all, all you need to do is move DIR out of the working
> >> > copy (with standard operating system tools) to somewhere else and it will
> >> > have been preserved as it was before SVN got involved.
> >> > Then run 'svn revert -R DIR' to put the versioned content in place.
> >> > Note that this solution is not trivial to achieve after update --force
> >> > which might modify unversioned files, requiring the user to edit files
> >> > in DIR back into their original state. This is why --force is not the default.
> >>
> >> Are you sure?
> >> In my experience --force does NOT overwrite existing files.
> >> Not overwriting files is safe and exactly what I want.
> >
> > I am quite sure:
> >
> > $ cd trunk-wc
> > $ ls
> > alpha beta epsilon/ gamma/
> > $ cat epsilon/zeta
> > zeta
> > $ cd ..
> > $ rm -rf trunk-wc
> > $ mkdir -p trunk-wc/epsilon
> > $ echo zzz > trunk-wc/epsilon/zeta
> > $ svn co --force file:///tmp/svn-sandbox/repos/trunk trunk-wc
> > A trunk-wc/alpha
> > A trunk-wc/beta
> > E trunk-wc/epsilon
> > E trunk-wc/epsilon/zeta
> > A trunk-wc/gamma
> > A trunk-wc/gamma/delta
> > Checked out revision 2.
> > $ svn diff trunk-wc
> > Index: trunk-wc/epsilon/zeta
> > ===================================================================
> > --- trunk-wc/epsilon/zeta (revision 2)
> > +++ trunk-wc/epsilon/zeta (working copy)
> > @@ -1 +1 @@
> > -zeta
> > +zzz
>
> So what unversioned file was overwritten by --force?
> zeta wasn't modified by the checkout was it?
Yes, you are right. Sorry! It seems I got confused about whether we
were talking about versioned or unversioned content being changed.
And at some point I was sure it would create text conflicts but in
fact it seems to leave unversioned files as-is.
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Mon, Dec 5, 2016 at 12:51 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> I don't understand what you're trying to say here. There are always
> files involved, no? I don't care about the directories themselves in
No, see my initial example:
# svn up /etc
Updating '/etc':
C /etc/php5
A /etc/php5/cli
A /etc/php5/cli/conf.d
A /etc/php5/cgi
A .
Updated to revision 55.
Tree conflict on '/etc/php5'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
The only conflict here is the directory /etc/php5.
I'm not sure what it did though.. the sub-dirs show A instead of C here.
> this case. I'm talking about the --force behaviour of "incorporating"
> existing files to make them part of a checkout that's being checked
> out over an existing tree.
>
>> How often does such an accidental checkout happen anyway?
>
> I have no idea. I suppose it happens from time to time. But in any
> case this discussion is a bit pointless ... we won't change the
> default "non-forcing" behaviour of 'svn checkout', simply because it's
> breaking backwards compatibility.
I'm not sure what that means in this case.. surely Subversion has
changed behavior before?
>> What about checking whether the destination directory exists before
>> the checkout and confirming the checkout is desired if it does exist
>> already?
>
> Yep, that's a good suggestion. As a matter of fact, Patrick Steinhardt
> is currently working on something like this. See this dev@ mail [1]
> with his latest patch. You might want to take a look (the commit
> message in the mail contains a good description of the behaviour).
>
> [1] https://lists.apache.org/thread.html/9ef6d2351c01865ba2e96537fb7b4aa3ff1752b1ace7dd4a95a4e151@%3Cdev.subversion.apache.org%3E
Looks good, thx.
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Dec 4, 2016 at 7:07 PM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Sun, Dec 4, 2016 at 6:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Sun, Dec 4, 2016 at 11:32 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
>> So do you agree that the --force behaviour (just blindly incorporating
>> local files, without any warning) should *not* be the default?
>
> I'm not sure..
> Why can't it be the default for directories?
I don't understand what you're trying to say here. There are always
files involved, no? I don't care about the directories themselves in
this case. I'm talking about the --force behaviour of "incorporating"
existing files to make them part of a checkout that's being checked
out over an existing tree.
> How often does such an accidental checkout happen anyway?
I have no idea. I suppose it happens from time to time. But in any
case this discussion is a bit pointless ... we won't change the
default "non-forcing" behaviour of 'svn checkout', simply because it's
breaking backwards compatibility. If we want to improve the experience
for users, we should work on improved tree conflict resolving (as is
currently being worked on for 1.10 --- help is most welcome :-).
> What about checking whether the destination directory exists before
> the checkout and confirming the checkout is desired if it does exist
> already?
Yep, that's a good suggestion. As a matter of fact, Patrick Steinhardt
is currently working on something like this. See this dev@ mail [1]
with his latest patch. You might want to take a look (the commit
message in the mail contains a good description of the behaviour).
[1] https://lists.apache.org/thread.html/9ef6d2351c01865ba2e96537fb7b4aa3ff1752b1ace7dd4a95a4e151@%3Cdev.subversion.apache.org%3E
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sun, Dec 4, 2016 at 6:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Sun, Dec 4, 2016 at 11:32 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
> So do you agree that the --force behaviour (just blindly incorporating
> local files, without any warning) should *not* be the default?
I'm not sure..
Why can't it be the default for directories?
How often does such an accidental checkout happen anyway?
What about checking whether the destination directory exists before
the checkout and confirming the checkout is desired if it does exist
already?
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Dec 4, 2016 at 11:32 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Sun, Dec 4, 2016 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> I think the most annoying consequence of accidentally checking out
>> over an existing directory, without any conflict detection (if the
>> --force behaviour would be the default), would be that you cannot
>> easily undo the operation. You haven't lost any unversioned data, but
>> you can not easily remove the checkout again and "rollback" to the
>> state before the checkout.
>
> Happened yesterday, I checked out into / instead of /etc.. svn behaves
> slightly different then rsync I guess.
>
>> Suppose you have files a and b locally. And the checkout
>> "incorporates" a and b (say they become unmodified because they are
>> the same as the repository version) and adds c, d, e, f, g, ... Oops,
>> the checkout was accidental. Now how do I remove it again? I don't
>> know which files were there before and which were added by the
>> checkout. Now imagine this happening with a complex tree structure
>> with 10,000 directories and 100,000 files.
>
> Does svn have a command to delete all versioned items?
> If not you still have to 'manually' figure out which directories /
> files came from the checkout and which ones existed before.
I guess you can easily use some output of svn status to find all
versioned items (ignoring the '?' lines, i.e. the unversioned items).
But I don't see how that helps for undoing an accidental "forced"
checkout. The files that were there before your forced checkout might
now be versioned items (i.e. they got a 'E' notification). It's
impossible to say now which files were there before, and which were
added by the checkout (OK, the unversioned items were certainly "local
files", but the versioned ones ... who knows? Except if you kept the
notification output of the checkout, so you can select all files with
a 'E' notification as "those files should be kept when I remove the
checkout).
So do you agree that the --force behaviour (just blindly incorporating
local files, without any warning) should *not* be the default?
FWIW, I agree it would be nice for the conflict resolver to be able to
do this. But as Stefan said, it can't at the moment. If it would have
that functionality, I guess your main request would be fulfilled,
right? Whether --force should be the default for checkout looks like a
secondary question to me (and as I said, I don't think that's a good
idea).
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sun, Dec 4, 2016 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> I think the most annoying consequence of accidentally checking out
> over an existing directory, without any conflict detection (if the
> --force behaviour would be the default), would be that you cannot
> easily undo the operation. You haven't lost any unversioned data, but
> you can not easily remove the checkout again and "rollback" to the
> state before the checkout.
Happened yesterday, I checked out into / instead of /etc.. svn behaves
slightly different then rsync I guess.
> Suppose you have files a and b locally. And the checkout
> "incorporates" a and b (say they become unmodified because they are
> the same as the repository version) and adds c, d, e, f, g, ... Oops,
> the checkout was accidental. Now how do I remove it again? I don't
> know which files were there before and which were added by the
> checkout. Now imagine this happening with a complex tree structure
> with 10,000 directories and 100,000 files.
Does svn have a command to delete all versioned items?
If not you still have to 'manually' figure out which directories /
files came from the checkout and which ones existed before.
And this only applies to files.. it doesn't applies to directories
going into a conflict state right?
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Dec 3, 2016 at 10:11 PM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <st...@elego.de> wrote:
>> On Sat, Dec 03, 2016 at 06:42:11PM +0100, Olaf van der Spek wrote:
>>> On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <st...@elego.de> wrote:
>>> >> >> For directories it seems like a no-brainer to avoid the conflict.
>>> >> >
>>> >> > Indeed, adding a resolver option for this should not be very difficult.
>>> >>
>>> >> I'd opt for not having a conflict in the first place.
>>> >
>>> > There is a reason the non-conflict behaviour requires the --force option.
>>> > It is perfectly fine for Subversion to be conservative if the alternative
>>> > is to litter all over other people's data.
>>> >
>>> > And this conflict is not very difficult to solve:
>>> >
>>> > When a directory DIR has an "local dir unversioned, incoming dir add upon
>>> > update" conflict, and you want to keep DIR as it was and do not want SVN
>>> > to touch it after all, all you need to do is move DIR out of the working
>>> > copy (with standard operating system tools) to somewhere else and it will
>>> > have been preserved as it was before SVN got involved.
>>> > Then run 'svn revert -R DIR' to put the versioned content in place.
>>> > Note that this solution is not trivial to achieve after update --force
>>> > which might modify unversioned files, requiring the user to edit files
>>> > in DIR back into their original state. This is why --force is not the default.
>>>
>>> Are you sure?
>>> In my experience --force does NOT overwrite existing files.
>>> Not overwriting files is safe and exactly what I want.
>>
>> I am quite sure:
>>
>> $ cd trunk-wc
>> $ ls
>> alpha beta epsilon/ gamma/
>> $ cat epsilon/zeta
>> zeta
>> $ cd ..
>> $ rm -rf trunk-wc
>> $ mkdir -p trunk-wc/epsilon
>> $ echo zzz > trunk-wc/epsilon/zeta
>> $ svn co --force file:///tmp/svn-sandbox/repos/trunk trunk-wc
>> A trunk-wc/alpha
>> A trunk-wc/beta
>> E trunk-wc/epsilon
>> E trunk-wc/epsilon/zeta
>> A trunk-wc/gamma
>> A trunk-wc/gamma/delta
>> Checked out revision 2.
>> $ svn diff trunk-wc
>> Index: trunk-wc/epsilon/zeta
>> ===================================================================
>> --- trunk-wc/epsilon/zeta (revision 2)
>> +++ trunk-wc/epsilon/zeta (working copy)
>> @@ -1 +1 @@
>> -zeta
>> +zzz
>
> So what unversioned file was overwritten by --force?
> zeta wasn't modified by the checkout was it?
I think the most annoying consequence of accidentally checking out
over an existing directory, without any conflict detection (if the
--force behaviour would be the default), would be that you cannot
easily undo the operation. You haven't lost any unversioned data, but
you can not easily remove the checkout again and "rollback" to the
state before the checkout.
Suppose you have files a and b locally. And the checkout
"incorporates" a and b (say they become unmodified because they are
the same as the repository version) and adds c, d, e, f, g, ... Oops,
the checkout was accidental. Now how do I remove it again? I don't
know which files were there before and which were added by the
checkout. Now imagine this happening with a complex tree structure
with 10,000 directories and 100,000 files.
So I think it's best not to do this by default.
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <st...@elego.de> wrote:
> On Sat, Dec 03, 2016 at 06:42:11PM +0100, Olaf van der Spek wrote:
>> On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <st...@elego.de> wrote:
>> >> >> For directories it seems like a no-brainer to avoid the conflict.
>> >> >
>> >> > Indeed, adding a resolver option for this should not be very difficult.
>> >>
>> >> I'd opt for not having a conflict in the first place.
>> >
>> > There is a reason the non-conflict behaviour requires the --force option.
>> > It is perfectly fine for Subversion to be conservative if the alternative
>> > is to litter all over other people's data.
>> >
>> > And this conflict is not very difficult to solve:
>> >
>> > When a directory DIR has an "local dir unversioned, incoming dir add upon
>> > update" conflict, and you want to keep DIR as it was and do not want SVN
>> > to touch it after all, all you need to do is move DIR out of the working
>> > copy (with standard operating system tools) to somewhere else and it will
>> > have been preserved as it was before SVN got involved.
>> > Then run 'svn revert -R DIR' to put the versioned content in place.
>> > Note that this solution is not trivial to achieve after update --force
>> > which might modify unversioned files, requiring the user to edit files
>> > in DIR back into their original state. This is why --force is not the default.
>>
>> Are you sure?
>> In my experience --force does NOT overwrite existing files.
>> Not overwriting files is safe and exactly what I want.
>
> I am quite sure:
>
> $ cd trunk-wc
> $ ls
> alpha beta epsilon/ gamma/
> $ cat epsilon/zeta
> zeta
> $ cd ..
> $ rm -rf trunk-wc
> $ mkdir -p trunk-wc/epsilon
> $ echo zzz > trunk-wc/epsilon/zeta
> $ svn co --force file:///tmp/svn-sandbox/repos/trunk trunk-wc
> A trunk-wc/alpha
> A trunk-wc/beta
> E trunk-wc/epsilon
> E trunk-wc/epsilon/zeta
> A trunk-wc/gamma
> A trunk-wc/gamma/delta
> Checked out revision 2.
> $ svn diff trunk-wc
> Index: trunk-wc/epsilon/zeta
> ===================================================================
> --- trunk-wc/epsilon/zeta (revision 2)
> +++ trunk-wc/epsilon/zeta (working copy)
> @@ -1 +1 @@
> -zeta
> +zzz
So what unversioned file was overwritten by --force?
zeta wasn't modified by the checkout was it?
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Dec 03, 2016 at 06:42:11PM +0100, Olaf van der Spek wrote:
> On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <st...@elego.de> wrote:
> >> >> For directories it seems like a no-brainer to avoid the conflict.
> >> >
> >> > Indeed, adding a resolver option for this should not be very difficult.
> >>
> >> I'd opt for not having a conflict in the first place.
> >
> > There is a reason the non-conflict behaviour requires the --force option.
> > It is perfectly fine for Subversion to be conservative if the alternative
> > is to litter all over other people's data.
> >
> > And this conflict is not very difficult to solve:
> >
> > When a directory DIR has an "local dir unversioned, incoming dir add upon
> > update" conflict, and you want to keep DIR as it was and do not want SVN
> > to touch it after all, all you need to do is move DIR out of the working
> > copy (with standard operating system tools) to somewhere else and it will
> > have been preserved as it was before SVN got involved.
> > Then run 'svn revert -R DIR' to put the versioned content in place.
> > Note that this solution is not trivial to achieve after update --force
> > which might modify unversioned files, requiring the user to edit files
> > in DIR back into their original state. This is why --force is not the default.
>
> Are you sure?
> In my experience --force does NOT overwrite existing files.
> Not overwriting files is safe and exactly what I want.
I am quite sure:
$ cd trunk-wc
$ ls
alpha beta epsilon/ gamma/
$ cat epsilon/zeta
zeta
$ cd ..
$ rm -rf trunk-wc
$ mkdir -p trunk-wc/epsilon
$ echo zzz > trunk-wc/epsilon/zeta
$ svn co --force file:///tmp/svn-sandbox/repos/trunk trunk-wc
A trunk-wc/alpha
A trunk-wc/beta
E trunk-wc/epsilon
E trunk-wc/epsilon/zeta
A trunk-wc/gamma
A trunk-wc/gamma/delta
Checked out revision 2.
$ svn diff trunk-wc
Index: trunk-wc/epsilon/zeta
===================================================================
--- trunk-wc/epsilon/zeta (revision 2)
+++ trunk-wc/epsilon/zeta (working copy)
@@ -1 +1 @@
-zeta
+zzz
> > and forgot to use --force.
>
> I wasn't aware of --force before asking this question.
It's not asking any questions.
> --force is usually used for dangerous stuff as well.
--force is a historcal name everyone is rather unhappy with.
No option named --force should exist (what is being forced?). But it does,
so now we cannot remove it without breaking backwards compatibility.