Git: Use of file content-hash to map to file revision is insufficient

When FishEye indexes a Git repository, the git commands that are used return a content hash for the file (e.g. to refer to the parent(s) of a file, or when getting the manifest at the head of a branch). Fisheye uses this content hash to find the matching file revision, but matches on the content hash only. This is insufficient, because (versions of) different files can have the same contents and therefore the same hashcode.

The result is that in these cases too many file revisions are being marked as being 'head' on a branch, tagged. Or in the case of finding the parent revision, the wrong revision could be chosen.

An example of this is FE-2725. Here, a directory is moved, but the content-hashes of the files don't change. When determining which revisions are head on branch, all revisions with the content-hash are marked as head and as a result both the old and the new directory shows up as being active.