@khanchi97 Some explanations, and be aware it is a gross simplification.
In Git, file content (called Blobs) and directory listings (called Trees) have object identifiers (OIDs) by which they can be directly addressed. Since Gitaly is meant to expose Git content, these notions are directly part of the interface. See for example the Blob service. These OIDs are actually SHAs, but it doesn't matter here.
Therefore, the normal operation of a Gitaly client to access the content of file foo/bar in a given commit can be to retrieve the OID for the Tree representing the foo directory in that commit, then of the Blob for file bar in that Tree. The resulting Blob OID can be used to access actual file content. The Rails app does indeed represent Git Blobs and Trees (see Gitlab::Git::Tree and Gitlab::Git::Blob).
It turns out that Gitaly also provides shortcuts that don't involve these OIDs, such as this ListFiles. That's what I meant with "does not exchange OIDs": ListFiles doesn't have such OIDs in its arguments (ListFilesRequest) nor in its return type (ListFilesResponse).
The fact that Mercurial does not work exactly this way is the main reason for the split into %HGitaly1: Hg SHAs and %HGitaly2: fully native milestones: we'll have to find the proper way to be compatible with that (certainly involving trade-offs and tough choices). I didn't want to deal with this in the first round of implementation, because I felt we would need actual experience with the Gitaly protocol and a nice playing ground. We could now start experimenting around this problem, but the priority has to be to fill the remaining gaps in the first milestone.
Re-assigning to "%HGitaly2: fully native, even though it doesn't involve Tree/Blob OIDs because I had the Rails app call ListFiles on the inner auxiliary Git repo in %Heptapod 0.17.0. It is therefore not needed for consistency of current Mercurial native projects.