Is there an recommended way to refer to bitkeepr commits?

[ebiederm@xmission.com (Eric W. Biederman)]

(Apologies resent as I forgot to include linux-kernel when I sent this
 the first time)
 
I am in the process of digging through the intersection of threads,
signals, ptrace, and exec and I am encountering bugs that predate
2.6.12-rc2 the first version in our current git tree.  I am trying
to figure out what to put in the fixes tag so that someone else
can find the commits.

I have an old tree that appears to be no longer available on kernel.org
that has all of the commits from the bit keeper era as well as the
annotations indicating the bit keeper revisions those commits came from.

Thomas Gleixner appears to have a tree with all of those same commits
except with the BKrev tags stripped out.

While reading through the post 2.6.12-rc2 commits I ran into a commit
from I think Linus that references what I believe was a pre 2.6.12-rc2
with what looked like a truncated sha1 hash.  There title of the
commit/patch was no included and the sha1 was not in any tree that I
have so I didn't know how to follow that reference.  I wish I had saved
off which commit that was so I could make this description more
concrete.

I was thinking of referring to the old commit that was broken as:
Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] linux-2.5.66-signal-cleanup.patch")

With no trees that have a BKrev in them publicly available it doesn't
look like anyone will be able to find that code.  It use a git sha1 hash
we would need a standard tree that we can reference and we don't appear
to have that either.

Is there any plan or standard recommendation on how handle bitkeeper era
commits?  Was there something sane and it was not properly restored
after the kernel.org break-in?

Eric