[PATCH] index-format.txt: be more liberal on what can represent invalid cache tree
We have been writing -1 as invalid since day 1. On that same day we accept all negative entry counts as invalid. So in theory all C Git versions out there would be happy to accept any negative numbers. JGit seems to do exactly the same. Correct the document to reflect the fact that -1 is not the only magic number. At least one implementation, libgit2, is found to treat -1 this way. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/technical/index-format.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..2028a49 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -161,8 +161,8 @@ GIT index format 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. In this case, there is no object name - and the next entry starts immediately after the newline. + a negative number 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.8.0.rc2.23.g1fb49df -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] index-format.txt: be more liberal on what can represent invalid cache tree
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: We have been writing -1 as invalid since day 1. On that same day we accept all negative entry counts as invalid. So in theory all C Git versions out there would be happy to accept any negative numbers. JGit seems to do exactly the same. I am of two minds here. The existing code is being more lenient than specified when they read stuff others wrote, but it still adheres to -1 when writing. Allowing random implementations to write random negative values will close the door for us to later update the specification to encode more informatin about these invalid entries by using negative value other than -1 here. I am OK with a reword to say negative means invalid, and writers should write -1 for invalid entries, but without the latter half, this change is not justified. diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..2028a49 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -161,8 +161,8 @@ GIT index format 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. In this case, there is no object name - and the next entry starts immediately after the newline. + a negative number 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
