I agree that FETCH_HEAD and MERGE_HEAD are not really refs because they 
point potentially to a set of objects and not to a single one. Since there 
are valid use-cases using these ref'ish objects like refs (e.g. fetching a 
changeset from gerrit with the commands gerrit publishes) we should support 
using this ref-like objects as refs as native git does. And yes, we	 
support that already because you can call repo.getRef("FETCH_HEAD") already.
Nothing to be done here. I'll only propose a good getter for FETCH_HEAD 
like for MERGE_HEAD.

Only one thing is where I disagree: I still think it is responsibility of 
JGit to tell which refs it accept. Let's talk Java:

if (repo.getRef("FETCH_HEAD")!=null)
	assert(repo.getAllRefs().containsKey("FETCH_HEAD"));

Currently this assert might fail and that looks strange to me. If the 
RefDatabase accepts FETCH_HEAD and returns a single ref then why shouldn't 
it be exposed it when asking for all refs? 

By the way: adding ORIG_HEAD to the RefsDatabase is ok, or? We are
working on rebase and I would like to offer users the possibility to compare
with ORIG_HEAD.