| Message ID | 20221022222539.2333-4-philipoakley@iee.email (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add some Glossary of terms information | expand |
Hey Philip, Glad that you're working on this :) On Sun, Oct 23, 2022 at 3:55 AM Philip Oakley <philipoakley@iee.email> wrote: > > Describe the purpose of the reachability bitmap. > > Signed-off-by: Philip Oakley <philipoakley@iee.email> > --- > Documentation/glossary-content.txt | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt > index 97050826e5..3d67b452aa 100644 > --- a/Documentation/glossary-content.txt > +++ b/Documentation/glossary-content.txt > @@ -508,6 +508,14 @@ exclude;; > <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> > that they contain. > > +[[def_reachability_bitmap]]reachability bitmaps:: > + Reachability bitmaps store information about the > + <<def_reachable,reachability>> of a selected set of objects in > + a packfile, or a multi-pack index (MIDX) to speed up object search. Looks good to me. Initially I thought that we could explain it more but as you already linked the "reachability" here, we don't need to. > + A repository may have at > + most one bitmap. The bitmap may belong to either one pack, or the > + repository's multi-pack index (if it exists). > + Small correction here - A repository may have multiple bitmaps (one for each selected commit from the preferred packfile or a multi-pack-index) but it can have only one ".bitmap" file (as of now). Bitmaps for the selected commits are stored in that ".bitmap" file. So I think the below lines (or similar) will work - The bitmaps are stored in a ".bitmap" file. A repository may have at most one ".bitmap" file. The file may belong to either one pack, or the repository's multi-pack-index (if it exists). Feel free to rephrase it accordingly. Thanks :)
Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com> writes: > Small correction here - A repository may have multiple bitmaps (one > for each selected commit from the preferred packfile or a > multi-pack-index) but it can have only one ".bitmap" file (as of now). > Bitmaps for the selected commits are stored in that ".bitmap" file. > So I think the below lines (or similar) will work - > > The bitmaps are stored in a ".bitmap" file. A repository may have > at most one ".bitmap" file. The file may belong to either one pack, or the > repository's multi-pack-index (if it exists). > > Feel free to rephrase it accordingly. Sounds good to me. Or Philip's original can be tweaked minimally to say "... may have at most one bitmap file (which stores multiple bitmaps)". Thanks.
On 24/10/2022 17:39, Junio C Hamano wrote: > Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com> writes: > >> Small correction here - A repository may have multiple bitmaps (one >> for each selected commit from the preferred packfile or a >> multi-pack-index) but it can have only one ".bitmap" file (as of now). >> Bitmaps for the selected commits are stored in that ".bitmap" file. >> So I think the below lines (or similar) will work - >> >> The bitmaps are stored in a ".bitmap" file. A repository may have >> at most one ".bitmap" file. The file may belong to either one pack, or the >> repository's multi-pack-index (if it exists). >> >> Feel free to rephrase it accordingly. > Sounds good to me. Or Philip's original can be tweaked minimally to > say "... may have at most one bitmap file (which stores multiple > bitmaps)". > Thanks both. I'll tweak the description in a day or so to allow Stolee to comment if required. P.
On 10/24/2022 5:23 PM, Philip Oakley wrote: > On 24/10/2022 17:39, Junio C Hamano wrote: >> Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com> writes: >> >>> Small correction here - A repository may have multiple bitmaps (one >>> for each selected commit from the preferred packfile or a >>> multi-pack-index) but it can have only one ".bitmap" file (as of now). >>> Bitmaps for the selected commits are stored in that ".bitmap" file. >>> So I think the below lines (or similar) will work - >>> >>> The bitmaps are stored in a ".bitmap" file. A repository may have >>> at most one ".bitmap" file. The file may belong to either one pack, or the >>> repository's multi-pack-index (if it exists). >>> >>> Feel free to rephrase it accordingly. >> Sounds good to me. Or Philip's original can be tweaked minimally to >> say "... may have at most one bitmap file (which stores multiple >> bitmaps)". >> > Thanks both. I'll tweak the description in a day or so to allow Stolee > to comment if required. I added my comments about the commit-graph file, and agree with Abhradeep's suggestions here. Adding Taylor as a possible reviewer, too. The one thing I will say is that there can be multiple .bitmap files, but Git will only use one of them. Not sure if that is worth being pedantic about here, though. We'll need to keep this glossary section in mind in case things change (such as "at most one bitmap file"). Thanks, -Stolee
Derrick Stolee <derrickstolee@github.com> writes: > The one thing I will say is that there can be multiple .bitmap > files, but Git will only use one of them. Not sure if that is > worth being pedantic about here, though. That matches my understanding, but "can be" is less of the norm these days, no? "repack -b" would refuse without "-a" so we may have more than one by accident, or am I missing a common scenario that we do perfectly normal things and still end up with multiple? I agree with you that it probably is a good idea to say there can be, so that the readers do not have to alarmed. Only one '.bitmap' file (which stores multiple reachability bitmaps) per repository is used in a repository (note. it is not wrong to have more than one). The bitmap file may belong to either one pack, or the repository's multi-pack index (if it exists). But then the readers who do have more than one would next think "how do I get rid of the ones that are not used? they are wasting my precious disk space". So I also am not sure if it helps to write more. "It is generally true that.." white lie may be better than technical correctness in this case. > We'll need to keep this glossary section in mind in case things > change (such as "at most one bitmap file"). True. Thanks.
On 25/10/2022 13:34, Derrick Stolee wrote: > On 10/24/2022 5:23 PM, Philip Oakley wrote: >> On 24/10/2022 17:39, Junio C Hamano wrote: >>> Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com> writes: >>> >>>> Small correction here - A repository may have multiple bitmaps (one >>>> for each selected commit from the preferred packfile or a >>>> multi-pack-index) but it can have only one ".bitmap" file (as of now). >>>> Bitmaps for the selected commits are stored in that ".bitmap" file. >>>> So I think the below lines (or similar) will work - >>>> >>>> The bitmaps are stored in a ".bitmap" file. A repository may have >>>> at most one ".bitmap" file. The file may belong to either one pack, or the >>>> repository's multi-pack-index (if it exists). >>>> >>>> Feel free to rephrase it accordingly. >>> Sounds good to me. Or Philip's original can be tweaked minimally to >>> say "... may have at most one bitmap file (which stores multiple >>> bitmaps)". >>> >> Thanks both. I'll tweak the description in a day or so to allow Stolee >> to comment if required. > I added my comments about the commit-graph file, and agree with > Abhradeep's suggestions here. > > Adding Taylor as a possible reviewer, too. > > The one thing I will say is that there can be multiple .bitmap > files, but Git will only use one of them. Not sure if that is > worth being pedantic about here, though. > > We'll need to keep this glossary section in mind in case things > change (such as "at most one bitmap file"). > > Thanks, > -Stolee I've gone with the phrase "at most one bitmap file in use." here. The updated series should be sent shortly. Philip.
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 97050826e5..3d67b452aa 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -508,6 +508,14 @@ exclude;; <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> that they contain. +[[def_reachability_bitmap]]reachability bitmaps:: + Reachability bitmaps store information about the + <<def_reachable,reachability>> of a selected set of objects in + a packfile, or a multi-pack index (MIDX) to speed up object search. + A repository may have at + most one bitmap. The bitmap may belong to either one pack, or the + repository's multi-pack index (if it exists). + [[def_rebase]]rebase:: To reapply a series of changes from a <<def_branch,branch>> to a different base, and reset the <<def_head,head>> of that branch
Describe the purpose of the reachability bitmap. Signed-off-by: Philip Oakley <philipoakley@iee.email> --- Documentation/glossary-content.txt | 8 ++++++++ 1 file changed, 8 insertions(+)