On Tue, Oct 05, 2021 at 11:02:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
> > index 4eb0421b3f..6467707c6e 100644
> > --- a/Documentation/git-cat-file.txt
> > +++ b/Documentation/git-cat-file.txt
> > @@ -94,8 +94,9 @@ OPTIONS
> > Instead of reading a list of objects on stdin, perform the
> > requested batch operation on all objects in the repository and
> > any alternate object stores (not just reachable objects).
> > - Requires `--batch` or `--batch-check` be specified. Note that
> > - the objects are visited in order sorted by their hashes.
> > + Requires `--batch` or `--batch-check` be specified. By default,
> > + the objects are visited in order sorted by their hashes; see
> > + also `--unordered` below.
> >
> > --buffer::
> > Normally batch output is flushed after each object is output, so
>
> Since you're doing while-you're-at-it anyway: Isn't the --unordered
> documentation also incorrect to reference --batch, which I take as it
> lazily using as a shorthand for --batch-all-objects.
I don't think so. It says:
--unordered::
When `--batch-all-objects` is in use, visit objects in an
order which may be more efficient for accessing the object
contents than hash order. The exact details of the order are
unspecified, but if you do not require a specific order, this
should generally result in faster output, especially with
`--batch`. Note that `cat-file` will still show each object
only once, even if it is stored multiple times in the
repository.
So it correctly mentions that it is affecting --batch-all-objects in the
first sentence. The "especially with --batch" is correct, too. The
ordering has more of an effect if you are accessing the full object,
since there we are increasing the locality which the delta-base cache
relies on. Whereas with --batch-check, even with size or type, that
locality is much less important (it might help disk or even RAM caches a
bit, but we are examining each object independently, even if it's a
delta, and not caching the intermediate results in any way ourselves).
Does that answer your question, or were you thinking of something else?
-Peff
