I did a darcs get --lazy http://darcs.net/screened.
Then I did darcs changes to view a list of patches.
In the final step I decided to run darcs check to see if the repository 
is 'ok'.

I saw the binary spinning up in memory usage while maintaining really 
low on CPU. I checked my network connection and saw it started pulling 
patches from the network.

Darcs did not inform me that the action will result in network 
communication and it does not display any progress of the currently 
performed actions (including the fact that it's downloading patches).

This behavior is also not documented in 
http://www.darcs.net/manual/Darcs_commands.html#SECTION00683000000000000
000

Darcs annotate on a lazy repo also initiates network activity without a 
warning.
This has the potential of making new users think that darcs annotate takes 
extremely long to perform because no indication of what darcs is doing is 
reported by the software.

http://wiki.darcs.net/Internals/CacheSystem may help anybody trying to 
figure out what is going on there

issue2093 is possibly related to this issue if the reporter worked on a
--lazy repository.

I think this is a more general feature request, one that stretches beyond 
darcs check.

Basically, when you're doing something like a darcs get or a darcs pull, 
you *expect* to grab files from the fetched repo.  But there are some 
situations where you won't be expecting such a thing to happen:

- operations that are not specifically about retrieval (so not pull/get)
- fetching from repositories other than the one you asked for (--lazy 
chaining: darcs get --lazy X Y; darcs get Y Z; cd Z; darcs pull)

In cases where it is not immediately obvious that Darcs should want to 
fetch files from some remote source, we should announce that we are doing 
so.

We don't need to mention this for each file that we fetch.  It's enough 
to mention the location once:

Fetching some missing patches from location X

Note also that we don't necessarily have to make the distinction between 
expecting fetching and not-expected.  Maybe the same UI could be used to 
report that we're fetching files from the places we'd expect (which could 
be reassuring)

I think here we have a UI design sketched out (?), but we now need 
somebody to figure out the code-design and hopefully implement it