This happens with current Darcs HEAD.

I don't think it's worthwile to write a regression test since it would
involve running a ssh server (in the case the test succeeds).

Here are the minimal steps to reproduce the bug:

```
/tmp$ darcs init R
/tmp$ cd R
/tmp/R$ echo x > x
/tmp/R$ darcs record -lam x
/tmp/R$ darcs clone . usr@host:path
Creating local clone...

darcs failed:  Couldn't fetch
`4e36eace85956d1aeb6749c5e889a88697535133ef507be5365d2303ad7ae9f7'
in subdir pristine.hashed from sources:

thisrepo:/tmp/clone/local
cache:/home/user/.cache/darcs
readonly:/home/user/.darcs/cache
```

See also issue2241. This is currently blocking me from using the HEAD at
work.

Sorry, typo. Meant to say: See issue2421.

The following patch sent by Guillaume Hoffmann <guillaumh@gmail.com> updated issue issue2437 with
status=resolved;resolvedin=2.10.0 HEAD

* resolve issue2437: fix cloning to ssh by forgetting source repo later 
Ignore-this: bbc33f6cc6762c93bb4a60661073215c

It is not resolved. With the current HEAD I still get

franksen@elbe: ...epics/ioc/BII-Controls > darcs pull                       
Pulling from
"rcsadm@repo.acc.bessy.de:/opt/repositories/controls/darcs/epics/ioc/BII-Controls/base-3-14-12"...
darcs: failed to read patch:
patch cdaa8e60e7e632cfb072d06f48523d7db231a71f
Author: Sabine.Giray@helmholtz-berlin.de.de
Date:   Wed Mar  4 13:40:25 CET 2015
  * minor changes (RFApp)
Couldn't fetch
`0000001156-372a52661eb9c63ff8a7b4e37530646808c626509c3d4b41d9ceb5919b5bfa94'
in subdir patches from sources:

thisrepo:/srv/projects/ctl/franksen/epics/ioc/BII-Controls
cache:/home/franksen/.cache/darcs
cache:/opt/csr/share/cache/darcs
cache:/tmp/darcs-franksen/cache
repo:rcsadm@repo.acc.bessy.de:/opt/repositories/controls/darcs/epics/ioc/BII-Controls/base-3-14-12

See also issue2421 and issue2400, which are more or less duplicates.

Clearly it's a different bug from 2421, and I believe ticket 2400 is a
mix of the current ticket's bug (which *is* resolved) and of 2421 (but I
suspect it has already been open before).

The current bug is about cloning from a local repo to a ssh destination
only, not pulling or cloning from http.

In that case: sorry for mixing things up. I thought it must be the same
problem because of the very similar error message.