Repository.readMergeHeads() will return you the content from MERGE_HEAD, or null if the file isn't present.  When there is more than one item in the resulting list the UI probably should have a notion of this and offer the user a way to deal with the 2nd, 3rd, etc. items.  Its a UI wart that C Git accepts MERGE_HEAD and always assumes the 1st item.

We don't have a reader for FETCH_HEAD, that's true.  We should implement one.  But again here, FETCH_HEAD may have multiple results, and the UI might want to be smarter about how it uses the information that is contained in FETCH_HEAD.  That is, if I say "cherry-pick FETCH_HEAD" I might want an option to include the URL and branch that I cherry-picked this from, similar to the way `git pull` works.  And even better, if I say "merge FETCH_HEAD" I should be offered a default merge message similar to the way pull would have done it... and that needs the URL and branch data from FETCH_HEAD, data that wouldn't normally be available in a Ref object.

Since the two data objects (FETCH_HEAD and MERGE_HEAD) contain different information beyond what a simple Ref is, I think its reasonable to say that these are *not* treated as a Ref and aren't returned by default in the Ref collections that an application can access.  If you do want this data, you should inquire for it against Repository... and we already have one of those accessors implemented, we just need FETCH_HEAD to re-create the FetchResult object that the prior fetch() call would have created in-memory anyway.

If an application Just Doesn't Care (tm), it can always do:

  Map<String, Ref> all = repo.getAllRefs();
  Ref r =  repo.getRef("MERGE_HEAD");
  if (r != null)
    r.put("MERGE_HEAD", r);
  r = repo.getRef("FETCH_HEAD");
  if (r != null)
    r.put("FETCH_HEAD", r);

but my argument above is, applications that want to support these two names in a way that is more sophisticated than simply taking a users-specified revision string and passing it into Repository.resolve(String) should be using other APIs that provide the full richness of the data they are accessing, rather than trying to shoe-horn the data into the rather limited Ref interface.