threads / patch / 27926

patchDocumentation: clarify the invalidated tree entry format

Subject: [PATCH] Documentation: clarify the invalidated tree entry format

## tl;dr

One message between Jul 26, 2011 and Jul 26, 2011. Diffs are folded; open one to read it.

replies: 0people: 1as markdown or json

Carlos Martín Nieto· Jul 26, 2011, 12:27 UTC · lore

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(-)
Show changes to Documentation/technical/index-format.txt +3 −2
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

← back to recent threads