[PATCH] Documentation: clarify the invalidated tree entry format

[PATCH] Documentation: clarify the invalidated tree entry format

[Carlos Martín Nieto]

When the entry_count is -1, the tree is invalidated and therefore has
not associated hash (or object name). Explicitly state that the next
entry starts after the newline.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---

This might be considered obvious, but IMO the hash (ojbect name) could
just as well be zeroed out and ignored by the parser. At any rate,
it's good to be explicit.

 Documentation/technical/index-format.txt |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
index 7b233ca..8930b3f 100644
--- a/Documentation/technical/index-format.txt
+++ b/Documentation/technical/index-format.txt
@@ -147,8 +147,9 @@ GIT index format
   - 160-bit object name for the object that would result from writing
     this span of index as a tree.
 
-  An entry can be in an invalidated state and is represented by having -1
-  in the entry_count field.
+  An entry can be in an invalidated state and is represented by having
+  -1 in the entry_count field. In this case, there is no object name
+  and the next entry starts immediately after the newline.
 
   The entries are written out in the top-down, depth-first order.  The
   first entry represents the root level of the repository, followed by the
-- 
1.7.5.2.585.gfbd48