Reading your post and browsing your Haskell code, a few things jumped out at me that might help.

It takes a lot of getting used to for a C or scripting language hacker, but functions really do bind more tightly than operators, so you can write things like this:

error $ show errnum ++ " failed"

Or:

uriUserInfo a ++ uriRegName a ++ uriPort a

You don't need to put parentheses around a function application.

Also, language constructs like if have higher syntactic "precedence" than anything else, so you can write:

if foo && not $ null l then ...

You might also find the when function useful; it works like if in a monad, but it has no else, and assumes you don't want a result; so, for instance, in tryRun':

when (errnum > 0) $ error $ show errnum ++ " failed"

(Note the lack of an else return ().)

And since you write Perl, you'll probably appreciate the corresponding unless.

In the GitRepo module, you have two different constructors for Repo, but they share three out of four fields, and they only differ depending on whether you have a FilePath or URI. You might consider changing that to use a single constructor and have one of the fields use a data type that itself can contain either a FilePath or a URI. That would simplify workTree, repoFromPath, and repoFromUrl, among many other functions.

You really want to use pattern matching rather than conditionals. In general, you rarely want if; think of pattern matching as your primary control structure, and if as a special case. You can write things like:

workTree (UrlRepo { url = repoUrl }) = repoUrl
workTree (Repo { top = path }) = path

Or (assuming you unify the two Repo constructors):

repoDescribe (Repo { remoteName = Just r }) = r
repoDescribe (...)

Or:

bare repo = case Map.lookup "core.bare" $ config repo of
    Just value -> value == "true"
    Nothing -> error ...

(Pattern matching has become such a natural control structure for me that I had to resist the impulse to write the one-line-longer-but-more-pattern-matchy Just "true" -> .... Also, I think Git has a default for deciding about bare/non-bare repositories, based on the path ending in .git or not; you might consider using that default to avoid error.)

You should probably also have far fewer calls to error, but that's a different and somewhat more difficult problem. At a minimum, you might consider using something like the ErrorT monad rather than thrown and caught exceptions. You also almost never want pure code generating exceptions of any kind.

Josh, thanks for the comments. I know I'm writing baby haskell -- had not thought about using pattern matching to dig inside record types, and will take that on board. I use ifs when I'm thinking procedurally. :) I suspect I should also use guards more (well, at al), but I've not internalized that syntax yet either.

I had thought about unifying the two Repo types, and could very well not have made the best decision there, but it seemed that adding a new type like RepoLocation = Url URI | Dir FilePath would involve lots more tedious pulling apart the nested data types in the places that need to get at those values. With @ pattern matching inside record types, it's not too bad.

workTree r@(Repo { location = Url _ }) = urlPath r
workTree (Repo { location = Dir d }) = d

Managing exceptions seems like one of the bigger cans of worms in Haskell.

(when is nice to know -- pity about all that punctuation needed though..)

BTW, Git's use of dir.git for bare repos is mostly a heuristic or UI abbreviation and not to be trusted.

Regarding the bare repo detection, even if git's own detection only works as a heuristic, making git-annex match git's behavior seems preferable to simply erroring out if you don't have the configuration option.

And yes, exceptions do indeed represent quite a can of worms. I personally fall in the camp that thinks Haskell ought to require declaring possible thrown exceptions as part of types, or not have them at all. They feel like a dynamic sore thumb sticking out of an otherwise static language, and they break my usual heuristic of "it compiles, it must be correct". :)

That said, I won't necessarily argue that you need to get rid of your use of exceptions entirely. And obviously you have to deal with the exceptions generated by other code regardless. But you might consider adding your own explicit exception type, and then only catching the exceptions you know how to deal with. And I'd highly recommend not catching the exception "error" generates, and not using that for expected failures. Most Haskell code I've seen reserves "error" for "program logic error that I couldn't detect until runtime" (such as head [] or fromJust Nothing).