In msg5443, Petr reported that doing a darcs put resulted in Darcs refusing to
apply patches that would result in a conflict.

Petr: is this something you can reproduce?

As far as I understand, darcs put just creates a bundle against an empty repo
and calls darcs apply. It's worth checking that darcs init and darcs push leads
to the same result.

Also perhaps a test case we could try is to create a situation with an
unresolved conflict.

13:43:46 | morn@twi:/tmp -> mkdir a
13:43:48 | morn@twi:/tmp -> mkdir b
13:43:49 | morn@twi:/tmp -> cd a
13:43:50 | morn@twi:/tmp/a -> darcs init
13:43:59 | morn@twi:/tmp/a -> echo a > a
13:44:02 | morn@twi:/tmp/a -> darcs rec
No changes!
13:44:03 | morn@twi:/tmp/a -> darcs rec -lam a
Finished recording patch 'a'
13:44:07 | morn@twi:/tmp/a -> cd ../b
13:44:11 | morn@twi:/tmp/b -> darcs init
13:44:12 | morn@twi:/tmp/b -> echo b > a
13:44:14 | morn@twi:/tmp/b -> darcs rec -lam b
Finished recording patch 'b'
13:44:19 | morn@twi:/tmp/b -> darcs pull ../a
Mon Sep  7 13:44:07 CEST 2009  Petr Rockai <me@mornfall.net>
  * a
Shall I pull this patch? (1/1)  [ynWsfvplxdaqjk], or ? for help: y
Backing up ./a(-darcs-backup0)
We have conflicts in the following files:
./a
Finished pulling and applying.
13:44:22 | morn@twi:/tmp/b -> darcs put ../x
There are conflicts in the following files:
./a

darcs failed:  Refusing to apply patches leading to conflicts.
If you would rather apply the patch and mark the conflicts,
use the --mark-conflicts or --allow-conflicts options to apply
These can set as defaults by adding
 apply mark-conflicts
to _darcs/prefs/defaults in the target repo. 
Apply failed!
13:44:28 | morn@twi:/tmp/b -> cd ..
13:45:31 | morn@twi:/tmp -> darcs get b y
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.

This breaks symmetry with get and is pretty confusing, too. I guess adding --

On Mon, Sep 07, 2009 at 11:46:39 +0000, Petr Ročkai wrote:
> This breaks symmetry with get and is pretty confusing, too. I guess adding --

Did you just get bitten by issue1596?

Eric Kow <bugs@darcs.net> writes:

I have no idea. I used the web form to enter that comment. This has happened
before... I guess roundup just isn't very reliable. The rest probably just
talked about --allow-conflicts in apply when used by put.

Yours,
   Petr.

I don't mean to be a pain, but could you send that as a patch?
http://wiki.darcs.net/RegressionTests for details

Note: I think the simplest way to fix this is with the put rewrite proposed in
issue1066, which would also solve the performance problems.

This ticket is outdated, and in a sense resolved. The "put" command
(which was really init + push) no longer exists and the feature of
cloning to remove ssh is part of the "clone" command, which created a
local clone then copies it by ssh.