This was originally part of my 'push --rebase' proposal, but I think it
makes sense to consider this change independently. If it is rejected, I'll
have to think of some other way to suppress interactivity for a remote darcs
invocation, probably an additional option "--really-no-interactive" ;-)

1 patch for repository http://darcs.net/screened:

patch 14a3edbd832547ba66faca87e15df6e5253c826b
Author: Ben Franksen <ben.franksen@online.de>
Date:   Thu Sep 27 10:31:26 CEST 2018
  * rebase suspend: don't ask the user if --all is in effect
  
  This is a change in behavior. If the user passes -a, this will now
  automatically answer all questions with yes. This includes the confirmation
  we normally require when hijacking patches.

Attachments

• patch-preview.txt
• rebase-suspend_-don_t-ask-the-user-if-__all-is-in-effect.dpatch
• unnamed

Whatever we do here should be consistent with darcs
amend-record, which also always warns about hijacking
when --all is passed.

Would a --allow-hijack option be ok instead of
--really-no-interactive? It'd mean you'd need a new option
each time a new kind of "are you really sure" prompt
appeared, but that feels a bit safer to me.

Hm. That means if --all is in effect, but not --allow-hijack, and 
the selected patches include one which has a different author, then 
the command just fails with an error message? I can live with that.

Another alternative would be to lift the restriction that we can't 
interact with the remote darcs. The reason for that is that stdin is 
used to send the bundle. One way around that could be to use scp or 
rsync to transfer the bundle to a temporary remote location e.g. 
<remoterepo>/_darcs/tmp and then invoke the remote darcs with the 
file name as argument. However that means we no longer stream the 
bundle, which is a shame.

In principle, programs can open streams like stdin, and receive 
input from that (in a thread) while keeping stdin open as well. 
However, it is unclear to me how another program can send data to 
this other stream from the outside.

On 06/10/2018 17:35, Ben Franksen wrote:

> Hm. That means if --all is in effect, but not --allow-hijack, and 
> the selected patches include one which has a different author, then 
> the command just fails with an error message? I can live with that.

I hadn't thought about it like that, but given that --all and
--no-interactive are aliases, it seems reasonable. There may be
parallels in how darcs push handles conflicting patches at the remote
end (I can't remember the details off the top of my head).

> Another alternative would be to lift the restriction that we can't 
> interact with the remote darcs. The reason for that is that stdin is 
> used to send the bundle. One way around that could be to use scp or 
> rsync to transfer the bundle to a temporary remote location e.g. 
> <remoterepo>/_darcs/tmp and then invoke the remote darcs with the 
> file name as argument. However that means we no longer stream the 
> bundle, which is a shame.
> 
> In principle, programs can open streams like stdin, and receive 
> input from that (in a thread) while keeping stdin open as well. 
> However, it is unclear to me how another program can send data to 
> this other stream from the outside.

I don't have a strong view on this, though I agree streaming is a nice
property to have.

Ganesh

Will instead add --allow-hijack option as discussed.