Add note on why we consume the tree for looking up an entry. (#470)

The disadvantage of doing that is that we copy the name, which
allocates, instead of just returning it by reference.

Author: Byron

git-repository/src/object/tree/iter.rs

@@ -6,7 +6,7 @@ pub struct EntryRef<'repo, 'a> {
     /// The actual entry ref we are wrapping.
     pub inner: git_object::tree::EntryRef<'a>,
 
-    repo: &'repo Repository,
+    pub(crate) repo: &'repo Repository,
 }
 
 impl<'repo, 'a> EntryRef<'repo, 'a> {
@@ -24,6 +24,11 @@ impl<'repo, 'a> EntryRef<'repo, 'a> {
     pub fn id(&self) -> crate::Id<'repo> {
         crate::Id::from_id(self.inner.oid, self.repo)
     }
+
+    /// Return the entries id, without repository connection.
+    pub fn oid(&self) -> git_hash::ObjectId {
+        self.inner.oid.to_owned()
+    }
 }
 
 impl<'repo, 'a> std::fmt::Display for EntryRef<'repo, 'a> {

git-repository/src/object/tree/mod.rs

@@ -31,6 +31,12 @@ impl<'repo> Tree<'repo> {
     /// Searching tree entries is currently done in sequence, which allows to the search to be allocation free. It would be possible
     /// to re-use a vector and use a binary search instead, which might be able to improve performance over all.
     /// However, a benchmark should be created first to have some data and see which trade-off to choose here.
+    ///
+    /// # Why is this consunming?
+    ///
+    /// The borrow checker shows pathological behaviour in loops that mutate a buffer, but also want to return from it.
+    /// Workarounds include keeping an index and doing a separate access to the memory, which seems hard to do here without
+    /// re-parsing the entries.
     pub fn lookup_entry<I, P>(mut self, path: I) -> Result<Option<git_object::tree::Entry>, find::existing::Error>
     where
         I: IntoIterator<Item = P>,