The bug is not critical since we currently don't have any formats
that we can read but not write (or vice versa).

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

patch d16454aed52d9e7670fc98585c67088c49dc74c8
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Sep 30 19:03:16 CEST 2018
  * bugfix in identifyRepositoryFor
  
  The problem may be due to a misunderstanding on my part when I refactored
  this code for the first time. The first parameter is not necessarily teh
  source and the second not necessarily the target. In fact, these roles are
  different for e.g. push and pull. Instead, the first is the local repo and
  the second is the remote one. To call transferProblem correctly requires
  that we know whether we are going to read or write so we pass that as an
  additional argument.

Attachments

• bugfix-in-identifyrepositoryfor.dpatch
• patch-preview.txt
• unnamed

When was the first refactoring you're referring to? The only one I
could find was "make type Repository abstract" from a year ago that
didn't seem to affect this code.

I looked back a little way (to 2.12) and the logic always seems to 
have been to look at 'transferProblem target source'.

I guess I meant this one:

patch e76075aeacf09a0b6620c58b2e902cf6b2a2f7b0
Author: Ben Franksen <benjamin.franksen@helmholtz-berlin.de>
Date:   Sat Feb 14 02:56:31 CET 2015
  * cleanup: Repository.Format and .Internal haddocks and variable 
names
  
  Also rename readfromAndWritetoProblem to transferProblem.

But I see now that it only clarifies which repo is which by naming 
them source/target and does not change semantics. So you are right 
and this bug was there to begin with.

This patch turns out to break the 'rebase-remote' test if applied 
without the rebase refactoring (patch1731).

Are you sure that this patch:

"adapt rebase tests to new style of storing rebase patch"

is not applied? It probably misses an explicit dependency on the 
rebase changes.