{"thread":{"id":"32321","subject":"[PATCH] index-format.txt: be more liberal on what can represent invalid cache tree","startedAt":"2012-12-12T12:44:36Z","lastAt":"2012-12-13T18:11:46Z","messageCount":5,"participants":["Nguyễn Thái Ngọc Duy","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"204741","messageId":"1355316276-7661-1-git-send-email-pclouds@gmail.com","threadId":"32321","inReplyTo":null,"subject":"[PATCH] index-format.txt: be more liberal on what can represent invalid cache tree","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-12-12T12:44:36Z","receivedAt":"2012-12-12T12:44:36Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"We have been writing -1 as \"invalid\" since day 1. On that same day we\naccept all negative entry counts as \"invalid\". So in theory all C Git\nversions out there would be happy to accept any negative numbers. JGit\nseems to do exactly the same.\n\nCorrect the document to reflect the fact that -1 is not the only magic\nnumber. At least one implementation, libgit2, is found to treat -1\nthis way.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Documentation/technical/index-format.txt | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt\nindex 9d25b30..2028a49 100644\n--- a/Documentation/technical/index-format.txt\n+++ b/Documentation/technical/index-format.txt\n@@ -161,8 +161,8 @@ GIT index format\n this span of index as a tree.\n \n An entry can be in an invalidated state and is represented by having\n- -1 in the entry_count field. In this case, there is no object name\n- and the next entry starts immediately after the newline.\n+ a negative number in the entry_count field. In this case, there is no\n+ object name and the next entry starts immediately after the newline.\n \n The entries are written out in the top-down, depth-first order. The\n first entry represents the root level of the repository, followed by the\n-- \n1.8.0.rc2.23.g1fb49df\n"},{"id":"204767","messageId":"7v4njr5eac.fsf@alter.siamese.dyndns.org","threadId":"32321","inReplyTo":"1355316276-7661-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] index-format.txt: be more liberal on what can represent invalid cache tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T18:14:03Z","receivedAt":"2012-12-12T18:14:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> We have been writing -1 as \"invalid\" since day 1. On that same day we\n> accept all negative entry counts as \"invalid\". So in theory all C Git\n> versions out there would be happy to accept any negative numbers. JGit\n> seems to do exactly the same.\n\nI am of two minds here.\n\nThe existing code is being more lenient than specified when they\nread stuff others wrote, but it still adheres to -1 when writing.\nAllowing random implementations to write random negative values will\nclose the door for us to later update the specification to encode\nmore informatin about these invalid entries by using negative value\nother than -1 here.\n\nI am OK with a reword to say \"negative means invalid, and writers\nshould write -1 for invalid entries\", but without the latter half,\nthis change is not justified.\n\n> diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt\n> index 9d25b30..2028a49 100644\n> --- a/Documentation/technical/index-format.txt\n> +++ b/Documentation/technical/index-format.txt\n> @@ -161,8 +161,8 @@ GIT index format\n> this span of index as a tree.\n> \n> An entry can be in an invalidated state and is represented by having\n> - -1 in the entry_count field. In this case, there is no object name\n> - and the next entry starts immediately after the newline.\n> + a negative number in the entry_count field. In this case, there is no\n> + object name and the next entry starts immediately after the newline.\n> \n> The entries are written out in the top-down, depth-first order. The\n> first entry represents the root level of the repository, followed by the\n"},{"id":"204815","messageId":"1355361287-10875-1-git-send-email-pclouds@gmail.com","threadId":"32321","inReplyTo":"7v4njr5eac.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-12-13T01:14:47Z","receivedAt":"2012-12-13T01:14:47Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"We have been writing -1 as \"invalid\" since day 1. On that same day we\naccept all negative entry counts as \"invalid\". So in theory all C Git\nversions out there would be happy to accept any negative numbers. JGit\nseems to do exactly the same.\n\nCorrect the document to reflect the fact that -1 is not the only magic\nnumber. At least one implementation, libgit2, is found to treat -1\nthis way.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n On Thu, Dec 13, 2012 at 1:14 AM, Junio C Hamano wrote:\n > Nguyễn Thái Ngọc Duy writes:\n >\n >> We have been writing -1 as \"invalid\" since day 1. On that same day we\n >> accept all negative entry counts as \"invalid\". So in theory all C Git\n >> versions out there would be happy to accept any negative numbers. JGit\n >> seems to do exactly the same.\n >\n > I am of two minds here.\n >\n > The existing code is being more lenient than specified when they\n > read stuff others wrote, but it still adheres to -1 when writing.\n > Allowing random implementations to write random negative values will\n > close the door for us to later update the specification to encode\n > more informatin about these invalid entries by using negative value\n > other than -1 here.\n\n How would that work with existing versions? If you write -2 in\n cache-tree, the next time 1.8.0 updates cache tree it writes -1 back.\n That loses whatever information you attach to -2. A new cache-tree\n extension is probably better.\n\n > I am OK with a reword to say \"negative means invalid, and writers\n > should write -1 for invalid entries\", but without the latter half,\n > this change is not justified.\n\n Done.\n\n Documentation/technical/index-format.txt | 5 +++--\n 1 file changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt\nindex 9d25b30..ce28a7a 100644\n--- a/Documentation/technical/index-format.txt\n+++ b/Documentation/technical/index-format.txt\n@@ -161,8 +161,9 @@ GIT index format\n this span of index as a tree.\n \n An entry can be in an invalidated state and is represented by having\n- -1 in the entry_count field. In this case, there is no object name\n- and the next entry starts immediately after the newline.\n+ a negative number in the entry_count field. In this case, there is no\n+ object name and the next entry starts immediately after the newline.\n+ When writing an invalid entry, -1 should always be used as entry_count.\n \n The entries are written out in the top-down, depth-first order. The\n first entry represents the root level of the repository, followed by the\n-- \n1.8.0.rc2.23.g1fb49df\n"},{"id":"204818","messageId":"7v8v921zt6.fsf@alter.siamese.dyndns.org","threadId":"32321","inReplyTo":"1355361287-10875-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-13T01:55:01Z","receivedAt":"2012-12-13T01:55:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> How would that work with existing versions? If you write -2 in\n> cache-tree, the next time 1.8.0 updates cache tree it writes -1 back.\n> That loses whatever information you attach to -2. A new cache-tree\n> extension is probably better.\n\nYou can easily imagine a definition like this:\n\n - If non-negative, the entry is valid and it is the number of index\n entries that are covered by this subtree;\n\n - If -1, the cached-tree does not know the object name of the tree\n object, and nothing else is known. The caller needs to walk the\n index to skip the entries that could have been covered by this\n subtree, if the cached tree information were valid;\n\n - If less than -1, the cached-tree does not know the object name of\n the tree object, but we know the number of index entries that are\n covered by this subtree. The caller, instead of walking the index,\n can subtract the count from -1 and skip that many entries to find\n the index entry after the part that is inside this directory.\n\nNewer Git may write -201 and newer Git may be able to take advantage\nof the new information encoded there, saving 200 calls to\nprefixcmp(), while given the same index, older Git will operate just\nas correctly as before. An older Git may write that part of the\ncache-tree back with -1, defeating the optimization when a newer Git\nreads it back, but by definition the older Git does not know what to\nwrite to help that optimization that did not exist when it was done,\nand writing -1 will not confuse the newer Git.\n"},{"id":"204841","messageId":"7vk3slzusd.fsf@alter.siamese.dyndns.org","threadId":"32321","inReplyTo":"7v8v921zt6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-13T18:11:46Z","receivedAt":"2012-12-13T18:11:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> How would that work with existing versions? If you write -2 in\n>> cache-tree, the next time 1.8.0 updates cache tree it writes -1 back.\n>> That loses whatever information you attach to -2. A new cache-tree\n>> extension is probably better.\n>\n> You can easily imagine a definition like this:\n> ...\n\nAs we clarified that we do not allow implementations to write\nanything but -1 for invalidated entries until we decide what we will\nuse other values for, the whole log message needs to be updated, I\nthink.\n\n-- >8 --\nFrom: Nguyễn Thái Ngọc Duy \nDate: Thu, 13 Dec 2012 08:14:47 +0700\nSubject: [PATCH] index-format.txt: clarify what is \"invalid\"\n\nA cache-tree entry with a negative entry count is considered \"invalid\"\nin the current Git; it records that we do not know the object name\nof a tree that would result by writing the directory covered by the\ncache-tree as a tree object.\n\nClarify that any entry with a negative entry count is invalid, but\nthe implementations must write -1 there. This way, we can later\ndecide to allow writers to use negative values other than -1 to\nencode optional information without harming interoperability; we do\nnot know what is encoded how, so keep these other negative values as\nreserved for now.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \nSigned-off-by: Junio C Hamano \n---\n Documentation/technical/index-format.txt | 5 +++--\n 1 file changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt\nindex 9d25b30..ce28a7a 100644\n--- a/Documentation/technical/index-format.txt\n+++ b/Documentation/technical/index-format.txt\n@@ -161,8 +161,9 @@ GIT index format\n this span of index as a tree.\n \n An entry can be in an invalidated state and is represented by having\n- -1 in the entry_count field. In this case, there is no object name\n- and the next entry starts immediately after the newline.\n+ a negative number in the entry_count field. In this case, there is no\n+ object name and the next entry starts immediately after the newline.\n+ When writing an invalid entry, -1 should always be used as entry_count.\n \n The entries are written out in the top-down, depth-first order. The\n first entry represents the root level of the repository, followed by the\n-- \n1.8.1.rc1.141.g0ffea5d\n"}]}