From patchwork Thu Jun 16 05:03:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Abhradeep Chakraborty X-Patchwork-Id: 12883321 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 183E5C43334 for ; Thu, 16 Jun 2022 05:04:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348403AbiFPFED (ORCPT ); Thu, 16 Jun 2022 01:04:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242923AbiFPFEA (ORCPT ); Thu, 16 Jun 2022 01:04:00 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0027544EF for ; Wed, 15 Jun 2022 22:03:59 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id j5-20020a05600c1c0500b0039c5dbbfa48so2185983wms.5 for ; Wed, 15 Jun 2022 22:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=aHlDPl766bclNObWLHStvODiPaABsIyLCA7q3kHw6ak=; b=XjDg2/QTfX2UuFOBoXbg7ibRCHNk/YIrSdqlGjP27ZlhJu+mT0sSL3aK8jSATLVJYl iFMlvl07gTK+0Kg705BH9pvPOYOgRsYiImNaWLwJ9nEQdZWdRdeJdcm5nV5EILABcj42 moAJ2YWJRGcL46djP+EI7yC9KchzaJXGLNRi3SEzcvJB2lRT7jWQ9YvHnVl4gKsjiUIz FLWMRleC9rgAH9kVCZ+53L4i5f4h8E/C90aR7MG+hbGA2Ghk+ET5buLNYG27F2XGVSO8 392U/xEcf3Hb1jCUxnVCmTmt4HzFK0vuMWZvJUEdi4/N9y1B81AadIu3RH6JAgRknhKx q0fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=aHlDPl766bclNObWLHStvODiPaABsIyLCA7q3kHw6ak=; b=MCJY+pX+jS/KkXu+NUOWnyTbBq8bgYrPtk4WHnVdFjzWaip+2U57BuvfSuhZKvhw45 QH3Enm7kMcPW/1dxQM+c6MB+4uCL0c4jMOFVpiRjTuUMVcp03Na94LtSIdGiN+vaCL/6 KIifTJniJPOVdSwJfrdu6hDuDYrwjkGIL/nTBIqPXu+zjyELrWtGJT/jF8gGuSmgelzD 1TFdb9r6ZL9OTYBIzG6njSc3voVRKWkpPZgQVh1KBd6jqoFeySPG7pvdalvtv3Ql+SDB RkhNngSOOdmIHNeCM/hGuNzyqKroq2V09zV4gKB3dyHh3NmwDkzpUZ1j4OF+3ASoSZsh VWsQ== X-Gm-Message-State: AJIora+d1HL5jAnakEyTIM/9qrh0v7YKFKB9LLDy7l1FNQcIK3jtlMYC Ud5hG9jcEQMnprjFShaWy9AaBe8RwOGrog== X-Google-Smtp-Source: AGRyM1tsldx0zms37TusGPrOfp9gxvPIhHZd0F00xwk4ZDEQm+EOo0JXcNCcAWG0JlyGNCcTwlCM0g== X-Received: by 2002:a05:600c:1e09:b0:39c:5351:789a with SMTP id ay9-20020a05600c1e0900b0039c5351789amr2944572wmb.177.1655355837744; Wed, 15 Jun 2022 22:03:57 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id k24-20020a05600c1c9800b00397122e63b6sm958713wms.29.2022.06.15.22.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 22:03:56 -0700 (PDT) Message-Id: <494c1c1bd522a6de1d6bc811b86f579ca6507013.1655355834.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Thu, 16 Jun 2022 05:03:52 +0000 Subject: [PATCH v4 1/3] bitmap-format.txt: feed the file to asciidoc to generate html Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Taylor Blau , Kaartic Sivaraam , Derrick Stolee , Junio C Hamano , Abhradeep Chakraborty , Abhradeep Chakraborty Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Abhradeep Chakraborty From: Abhradeep Chakraborty Documentation/Makefile does not include bitmap-format.txt to generate a html page using asciidoc. Teach Documentation/Makefile to also generate a html page for Documentation/technical/bitmap-format.txt file. Signed-off-by: Abhradeep Chakraborty --- Documentation/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/Makefile b/Documentation/Makefile index f2e7fc1daa5..4f801f4e4c9 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -94,6 +94,7 @@ TECH_DOCS += MyFirstContribution TECH_DOCS += MyFirstObjectWalk TECH_DOCS += SubmittingPatches TECH_DOCS += ToolsForGit +TECH_DOCS += technical/bitmap-format TECH_DOCS += technical/bundle-format TECH_DOCS += technical/cruft-packs TECH_DOCS += technical/hash-function-transition From patchwork Thu Jun 16 05:03:53 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Abhradeep Chakraborty X-Patchwork-Id: 12883322 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97F08CCA47A for ; Thu, 16 Jun 2022 05:04:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229501AbiFPFEF (ORCPT ); Thu, 16 Jun 2022 01:04:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238953AbiFPFEC (ORCPT ); Thu, 16 Jun 2022 01:04:02 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 168D853712 for ; Wed, 15 Jun 2022 22:04:01 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id m24so292348wrb.10 for ; Wed, 15 Jun 2022 22:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=8NVEdeAslaWje9c2lM4NsWUuUpvssohcGa9xqMX7fBs=; b=aOFc9lKfyPSuUgMFIsNEUxnA+FrZMLlTLMM8j8UXQChRvnJH0JN5R74hbzeoh7k4zw c441hxbOINug+BQU7wfJEd90etFU8Ej9P2Abc+iNknOTF1qX6Irw7BXP/vN4jEs4f/Zq hR8UtXIcGDxO5AHwPze6FgpJ+KZ6TElv7wfeOsiIKZj7wmQ97hnORmk2AQggo388IAEF 2seGmjooCrRG/wPFLgxYUT+uaZ9hJdKQoIIfwcPLZfp0EVnicPAMDLPnE4QTiqJLNgz4 hQRdVZxIik3cTlf+nqfyQEV9hRv1ZQA7doJ+P80cZodtpkoO/6Bzj6YKkgzQs86EeJsD K/kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=8NVEdeAslaWje9c2lM4NsWUuUpvssohcGa9xqMX7fBs=; b=Lvrbo0yrjXmlrHs/c0rtxxGFZe4Dobf/VZMmuL6qm/Dq5S4DME4sQLFs39KLC+f8az zpxXAYMZcKPiDLrK58OHqg+Z4N4StARa8qXnfNYjDrpNipJOKa+MOrltKZYr228IuYik tzhixkdmp6MQpyuAovBPbTmVtI9wEPPcnkUr9vyesASpCc86xkO9pNfd/TdjnBAnmc6N LSqOIgclgSSqi2UopK7COSc+3zd8WsAEbRvTNJOl0HI5188dW9X265SAyl1GTlFGAfr7 vDK2q8kctbPJfjIN9ED4RhIuJqp8PdF8uKMv589Uc/TLwzw/jcKAsaROa8WLU5nqqOr0 8Gmw== X-Gm-Message-State: AJIora/kPXnHy6FBWzmzoG3PRaexpPvyFCOljje1fsZ/MF0cYDq/jMfx v+LLC1afLGk3WIcW535m9vqMMk2IbuOJ6Q== X-Google-Smtp-Source: AGRyM1uE0SVKjz4FFBdl8IkkJlpw6ZQeFvLdafwPpF5xddI+00dD6XAa9enWjSbinvJzd8uPKGy4qw== X-Received: by 2002:a05:6000:1b0f:b0:210:313a:ef2a with SMTP id f15-20020a0560001b0f00b00210313aef2amr2778811wrz.281.1655355839072; Wed, 15 Jun 2022 22:03:59 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id l3-20020a5d5263000000b0020ff7246934sm671302wrc.95.2022.06.15.22.03.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 22:03:58 -0700 (PDT) Message-Id: <25512aa9c5b6d6df0c20c0400a0cac11afb64842.1655355834.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Thu, 16 Jun 2022 05:03:53 +0000 Subject: [PATCH v4 2/3] bitmap-format.txt: fix some formatting issues Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Taylor Blau , Kaartic Sivaraam , Derrick Stolee , Junio C Hamano , Abhradeep Chakraborty , Abhradeep Chakraborty Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Abhradeep Chakraborty From: Abhradeep Chakraborty The asciidoc generated html for `Documentation/technical/bitmap- format.txt` is broken. This is mainly because `-` is used for nested lists (which is not allowed in asciidoc) instead of `*`. Fix these and also reformat it for better readability of the html page. Signed-off-by: Abhradeep Chakraborty --- Documentation/technical/bitmap-format.txt | 199 +++++++++++----------- 1 file changed, 103 insertions(+), 96 deletions(-) diff --git a/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt index 04b3ec21785..49c8e819804 100644 --- a/Documentation/technical/bitmap-format.txt +++ b/Documentation/technical/bitmap-format.txt @@ -25,9 +25,9 @@ An object is uniquely described by its bit position within a bitmap: is defined as follows: o1 <= o2 <==> pack(o1) <= pack(o2) /\ offset(o1) <= offset(o2) - - The ordering between packs is done according to the MIDX's .rev file. - Notably, the preferred pack sorts ahead of all other packs. ++ +The ordering between packs is done according to the MIDX's .rev file. +Notably, the preferred pack sorts ahead of all other packs. The on-disk representation (described below) of a bitmap is the same regardless of whether or not that bitmap belongs to a packfile or a MIDX. The only @@ -39,97 +39,104 @@ MIDXs, both the bit-cache and rev-cache extensions are required. == On-disk format - - A header appears at the beginning: - - 4-byte signature: {'B', 'I', 'T', 'M'} - - 2-byte version number (network byte order) - The current implementation only supports version 1 - of the bitmap index (the same one as JGit). - - 2-byte flags (network byte order) - - The following flags are supported: - - - BITMAP_OPT_FULL_DAG (0x1) REQUIRED - This flag must always be present. It implies that the - bitmap index has been generated for a packfile or - multi-pack index (MIDX) with full closure (i.e. where - every single object in the packfile/MIDX can find its - parent links inside the same packfile/MIDX). This is a - requirement for the bitmap index format, also present in - JGit, that greatly reduces the complexity of the - implementation. - - - BITMAP_OPT_HASH_CACHE (0x4) - If present, the end of the bitmap file contains - `N` 32-bit name-hash values, one per object in the - pack/MIDX. The format and meaning of the name-hash is - described below. - - 4-byte entry count (network byte order) - - The total count of entries (bitmapped commits) in this bitmap index. - - 20-byte checksum - - The SHA1 checksum of the pack/MIDX this bitmap index - belongs to. - - - 4 EWAH bitmaps that act as type indexes - - Type indexes are serialized after the hash cache in the shape - of four EWAH bitmaps stored consecutively (see Appendix A for - the serialization format of an EWAH bitmap). - - There is a bitmap for each Git object type, stored in the following - order: - - - Commits - - Trees - - Blobs - - Tags - - In each bitmap, the `n`th bit is set to true if the `n`th object - in the packfile or multi-pack index is of that type. - - The obvious consequence is that the OR of all 4 bitmaps will result - in a full set (all bits set), and the AND of all 4 bitmaps will - result in an empty bitmap (no bits set). - - - N entries with compressed bitmaps, one for each indexed commit - - Where `N` is the total amount of entries in this bitmap index. - Each entry contains the following: - - - 4-byte object position (network byte order) - The position **in the index for the packfile or - multi-pack index** where the bitmap for this commit is - found. - - - 1-byte XOR-offset - The xor offset used to compress this bitmap. For an entry - in position `x`, a XOR offset of `y` means that the actual - bitmap representing this commit is composed by XORing the - bitmap for this entry with the bitmap in entry `x-y` (i.e. - the bitmap `y` entries before this one). - - Note that this compression can be recursive. In order to - XOR this entry with a previous one, the previous entry needs - to be decompressed first, and so on. - - The hard-limit for this offset is 160 (an entry can only be - xor'ed against one of the 160 entries preceding it). This - number is always positive, and hence entries are always xor'ed - with **previous** bitmaps, not bitmaps that will come afterwards - in the index. - - - 1-byte flags for this bitmap - At the moment the only available flag is `0x1`, which hints - that this bitmap can be re-used when rebuilding bitmap indexes - for the repository. - - - The compressed bitmap itself, see Appendix A. + * A header appears at the beginning: + + 4-byte signature: :: {'B', 'I', 'T', 'M'} + + 2-byte version number (network byte order): :: + + The current implementation only supports version 1 + of the bitmap index (the same one as JGit). + + 2-byte flags (network byte order): :: + + The following flags are supported: + + ** {empty} + BITMAP_OPT_FULL_DAG (0x1) REQUIRED: ::: + + This flag must always be present. It implies that the + bitmap index has been generated for a packfile or + multi-pack index (MIDX) with full closure (i.e. where + every single object in the packfile/MIDX can find its + parent links inside the same packfile/MIDX). This is a + requirement for the bitmap index format, also present in + JGit, that greatly reduces the complexity of the + implementation. + + ** {empty} + BITMAP_OPT_HASH_CACHE (0x4): ::: + + If present, the end of the bitmap file contains + `N` 32-bit name-hash values, one per object in the + pack/MIDX. The format and meaning of the name-hash is + described below. + + 4-byte entry count (network byte order): :: + The total count of entries (bitmapped commits) in this bitmap index. + + 20-byte checksum: :: + The SHA1 checksum of the pack/MIDX this bitmap index + belongs to. + + * 4 EWAH bitmaps that act as type indexes ++ +Type indexes are serialized after the hash cache in the shape +of four EWAH bitmaps stored consecutively (see Appendix A for +the serialization format of an EWAH bitmap). ++ +There is a bitmap for each Git object type, stored in the following +order: ++ + - Commits + - Trees + - Blobs + - Tags + ++ +In each bitmap, the `n`th bit is set to true if the `n`th object +in the packfile or multi-pack index is of that type. ++ +The obvious consequence is that the OR of all 4 bitmaps will result +in a full set (all bits set), and the AND of all 4 bitmaps will +result in an empty bitmap (no bits set). + + * N entries with compressed bitmaps, one for each indexed commit ++ +Where `N` is the total amount of entries in this bitmap index. +Each entry contains the following: + + ** {empty} + 4-byte object position (network byte order): :: + The position **in the index for the packfile or + multi-pack index** where the bitmap for this commit is + found. + + ** {empty} + 1-byte XOR-offset: :: + The xor offset used to compress this bitmap. For an entry + in position `x`, a XOR offset of `y` means that the actual + bitmap representing this commit is composed by XORing the + bitmap for this entry with the bitmap in entry `x-y` (i.e. + the bitmap `y` entries before this one). ++ +NOTE: This compression can be recursive. In order to +XOR this entry with a previous one, the previous entry needs +to be decompressed first, and so on. ++ +The hard-limit for this offset is 160 (an entry can only be +xor'ed against one of the 160 entries preceding it). This +number is always positive, and hence entries are always xor'ed +with **previous** bitmaps, not bitmaps that will come afterwards +in the index. + + ** {empty} + 1-byte flags for this bitmap: :: + At the moment the only available flag is `0x1`, which hints + that this bitmap can be re-used when rebuilding bitmap indexes + for the repository. + + ** The compressed bitmap itself, see Appendix A. == Appendix A: Serialization format for an EWAH bitmap @@ -142,8 +149,8 @@ implementation: - 4-byte number of words of the COMPRESSED bitmap, when stored - N x 8-byte words, as specified by the previous field - - This is the actual content of the compressed bitmap. ++ +This is the actual content of the compressed bitmap. - 4-byte position of the current RLW for the compressed bitmap From patchwork Thu Jun 16 05:03:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Abhradeep Chakraborty X-Patchwork-Id: 12883323 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D533CC43334 for ; Thu, 16 Jun 2022 05:04:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350811AbiFPFEM (ORCPT ); Thu, 16 Jun 2022 01:04:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349153AbiFPFEE (ORCPT ); Thu, 16 Jun 2022 01:04:04 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63966544EF for ; Wed, 15 Jun 2022 22:04:02 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id h5so344794wrb.0 for ; Wed, 15 Jun 2022 22:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=tXMPoiGM3eUmc86fZkpV5Y8BDy83416sQIkbyZgSgM0=; b=PRguAry5o8dwlxMxMb2LE7fxtEeTm9WpmJM/SfUrcP85thszjnswrMbtwUaK46H8+8 AGhsa6UYX41KgyGesyUBLWyhM8RIRPhYp463Kzd2JwNcOUN3YPwabTmiaXfs75yg37m+ F73Q1sYeZU+UGOLatnHRMQ6NyhDNk8aV/BJCUarqjkcW4ACHTHTfWTyj1hS4BAzoDDyp 12+pmNr3HWF/JoD5PNFY6i8czmZmEI2DV0u78xUKlJPIfVgZleAG2CKifAQ0CDiLCJVl 3yR+ihtfTTGrUG6WWxYLpR+RkW+enNs8I5+6SojvHy2iY+Qs5d8uAmU52zqgKNaiOQos S40Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=tXMPoiGM3eUmc86fZkpV5Y8BDy83416sQIkbyZgSgM0=; b=UtdkMDofybrVLEmaGFb/U7wj2x+qpUZnbRbO1WE9NIiG+1X/5LHh0T0zMJEV2cLw88 6xLi6wXjDc3utSUx/8qjblzebGRXvn/x5w6f7EpXSrSmfiymngG84n4GpTz8tNGY12Zy 2b8r3Nvg8FgolLqOoMlStp/II4whwtBMDY4yPzRF+CbfFXrwlx+1nG7UNklQnRCpNxQw 8dlYsagpUP2LCfuAI9FZ7wNC7kI/xM3pwSS4lrj/rE1163hNNhatkWBhqlrJcJ7RAjYp zbJa4K1/rpGuLjnLHkHTvOPOW048FL7LICHJ0uRjIqGZRnTQoqOhiFlypOAOKstRKuER gtFQ== X-Gm-Message-State: AJIora9gQYlBTHCoVBVv7fbYQGmWaiD35PUx46xKP6/6YX8FjBBI3y7L yaBflXgcTCP73M9rR0950uituGRBGgaviQ== X-Google-Smtp-Source: AGRyM1uxe1gCzUPV99BC5W0fYi+EtVyf3vosH82pL1ooSVmYUUJxL9lpJHtOG8wJRzsvR6R+k83kgQ== X-Received: by 2002:a05:6000:11:b0:210:302d:e787 with SMTP id h17-20020a056000001100b00210302de787mr2788209wrx.535.1655355840544; Wed, 15 Jun 2022 22:04:00 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id h28-20020adfa4dc000000b0020fff0ea0a3sm662341wrb.116.2022.06.15.22.03.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jun 2022 22:03:59 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Thu, 16 Jun 2022 05:03:54 +0000 Subject: [PATCH v4 3/3] bitmap-format.txt: add information for trailing checksum Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: Taylor Blau , Kaartic Sivaraam , Derrick Stolee , Junio C Hamano , Abhradeep Chakraborty , Abhradeep Chakraborty Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Abhradeep Chakraborty From: Abhradeep Chakraborty Bitmap file has a trailing checksum at the end of the file. However there is no information in the bitmap-format documentation about it. Add a trailer section to include the trailing checksum info in the `Documentation/technical/bitmap-format.txt` file. Signed-off-by: Abhradeep Chakraborty --- Documentation/technical/bitmap-format.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt index 49c8e819804..7be5f2318ba 100644 --- a/Documentation/technical/bitmap-format.txt +++ b/Documentation/technical/bitmap-format.txt @@ -138,6 +138,10 @@ in the index. ** The compressed bitmap itself, see Appendix A. + * {empty} + TRAILER: :: + Trailing checksum of the preceding contents. + == Appendix A: Serialization format for an EWAH bitmap Ewah bitmaps are serialized in the same protocol as the JAVAEWAH