Attempting to get a hashed repo results in an empty _darcs/patches.
The following transcript demonstrates the error:

$ cd `mktemp -d`
$ HOME=$PWD
$ mkdir 1
$ darcs init --repodir 1
$ touch 1/x
$ darcs rec --repodir 1 -lam x x
Recording changes in "x":

Finished recording patch 'x'
$ ls 1/_darcs/patches
20080203035903-4ef00-295fa59e3f9a899d8700fbf7d4168e9d7f475601.gz
pending
pending.tentative
$ darcs get --hashed 1 2
Finished getting.
$ ls 2/_darcs/patches
f7c97897f7b111fb006a49c9739849eab71d72c1
pending.tentative
$ darcs get --hashed 2 3
Finished getting.
$ ls 3/_darcs/patches
pending.tentative

3/_darcs/patches should contain a file
f7c97897f7b111fb006a49c9739849eab71d72c1.  This occurs with both
2.0.0pre2 and 2.0.0pre3.

Trent,

Thanks for the example session script. 

However, when I run your test script against a darcs binary built earlier today,
the bug is not triggered. 

What OS version and GHC version are you using? 

Please submit a darcs patch with a formal test case version to the  tests/
directory of the darcs repo, and we'll see it fails or passes for anyone else. 

I'm using Ubuntu Gutsy 7.10 with GHC 6.6.1 and didn't trigger the issue: 

To be clear, the final "ls" on the "3" directory reports a patch in there,
unlike your "screen shot".

On Sun, Feb 03, 2008 at 04:29:09AM -0000, Mark Stosberg wrote:
> However, when I run your test script against a darcs binary built
> earlier today, the bug is not triggered.
>
> What OS version and GHC version are you using?

Debian Lenny i386.

I deleted the chroot used to make the .deb, but I believe it was
whatever Lenny had yesterday, which *should* be 6.6.1-2.  Note that
I'm using the prereleases, not a up-to-the-minute checkout.

Oh also, it occurs to me that my /tmp is a tmpfs, which might have
bizarro semantics.  I also have this issue when getting FROM an ssh
repository (the remote filesystem is NFS backed by ext3) TO an ext2
filesystem.

> Please submit a darcs patch with a formal test case version to the
> tests/ directory of the darcs repo, and we'll see it fails or passes
> for anyone else.

I'll try to get this done today, otherwise it probably won't happen
before next weekend.

Hi Trent,

Could I prod you to submit a formal test case?  Thanks!

On Wed, May 07, 2008 at 03:57:27PM -0000, Eric Kow wrote:
> Could I prod you to submit a formal test case?  Thanks!

I cannot reproduce this issue with 2.0.0, as this transcript shows.
Suggest closing this ticket.

$ cd `mktemp -d`
$ HOME=$PWD
$ mkdir 1
$ darcs init --repodir 1
$ touch 1/x
$ darcs rec --repodir 1 -lam x x
Recording changes in "x":

Finished recording patch 'x'
$ ls 1/_darcs/patches
20080517161647-4ef00-5fb1f956a92529a2fdee2cb08ea75dab4a0fe53f.gz
pending
pending.tentative
$ darcs get --hashed 1 2
Finished getting.
$ ls 2/_darcs/patches
0000000051-74171c2be399d3a64e65db33406080a2b622d96f13b3ea3063e670d849947e92
pending
pending.tentative
$ darcs get --hashed 2 3
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.
$ ls 3/_darcs/patches
0000000051-74171c2be399d3a64e65db33406080a2b622d96f13b3ea3063e670d849947e92
pending.tentative
$ darcs --version
2.0.0 (unknown)
$ darcs --exact-version
darcs compiled on Apr 10 2008, at 02:20:19
unknown
$

Thanks.  Marking resolved.  Hopefully this is something that really was fixed.