2005-04-08 02:16:10 +04:00
|
|
|
/*
|
|
|
|
* GIT - The information manager from hell
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*/
|
2019-01-24 11:29:12 +03:00
|
|
|
#define USE_THE_INDEX_COMPATIBILITY_MACROS
|
2005-04-08 02:13:13 +04:00
|
|
|
#include "cache.h"
|
2017-06-14 21:07:36 +03:00
|
|
|
#include "config.h"
|
2006-05-24 15:08:46 +04:00
|
|
|
#include "builtin.h"
|
2017-05-24 08:15:10 +03:00
|
|
|
#include "diff.h"
|
2008-05-23 18:19:42 +04:00
|
|
|
#include "parse-options.h"
|
2010-06-15 19:50:28 +04:00
|
|
|
#include "userdiff.h"
|
2012-03-07 14:54:17 +04:00
|
|
|
#include "streaming.h"
|
2015-05-20 20:03:40 +03:00
|
|
|
#include "tree-walk.h"
|
2015-06-22 14:06:32 +03:00
|
|
|
#include "sha1-array.h"
|
2017-08-19 01:20:38 +03:00
|
|
|
#include "packfile.h"
|
2018-05-16 02:42:15 +03:00
|
|
|
#include "object-store.h"
|
2019-06-25 16:40:31 +03:00
|
|
|
#include "promisor-remote.h"
|
2008-05-23 18:19:42 +04:00
|
|
|
|
2015-06-22 13:41:03 +03:00
|
|
|
struct batch_options {
|
|
|
|
int enabled;
|
|
|
|
int follow_symlinks;
|
|
|
|
int print_contents;
|
2015-06-22 13:45:17 +03:00
|
|
|
int buffer_output;
|
2015-06-22 13:45:59 +03:00
|
|
|
int all_objects;
|
cat-file: support "unordered" output for --batch-all-objects
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related deltas next to each other. By contrast, hash order
is effectively random, since the sha1 has no discernible
relationship to the content.
This patch introduces an "--unordered" option to cat-file
which iterates over packs in pack-order under the hood. You
can see the results when dumping all of the file content:
$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
6883195596
real 0m44.491s
user 0m42.902s
sys 0m5.230s
$ time ./git cat-file --unordered \
--batch-all-objects --buffer --batch | wc -c
6883195596
real 0m6.075s
user 0m4.774s
sys 0m3.548s
Same output, different order, way faster. The same speed-up
applies even if you end up accessing the object content in a
different process, like:
git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c
Adding "--unordered" to the first command drops the runtime
in git.git from 24s to 3.5s.
Side note: there are actually further speedups available
for doing it all in-process now. Since we are outputting
the object content during the actual pack iteration, we
know where to find the object and could skip the extra
lookup done by oid_object_info(). This patch stops short
of that optimization since the underlying API isn't ready
for us to make those sorts of direct requests.
So if --unordered is so much better, why not make it the
default? Two reasons:
1. We've promised in the documentation that --batch-all-objects
outputs in hash order. Since cat-file is plumbing,
people may be relying on that default, and we can't
change it.
2. It's actually _slower_ for some cases. We have to
compute the pack revindex to walk in pack order. And
our de-duplication step uses an oidset, rather than a
sort-and-dedup, which can end up being more expensive.
If we're just accessing the type and size of each
object, for example, like:
git cat-file --batch-all-objects --buffer --batch-check
my best-of-five warm cache timings go from 900ms to
1100ms using --unordered. Though it's possible in a
cold-cache or under memory pressure that we could do
better, since we'd have better locality within the
packfile.
And one final question: why is it "--unordered" and not
"--pack-order"? The answer is again two-fold:
1. "pack order" isn't a well-defined thing across the
whole set of objects. We're hitting loose objects, as
well as objects in multiple packs, and the only
ordering we're promising is _within_ a single pack. The
rest is apparently random.
2. The point here is optimization. So we don't want to
promise any particular ordering, but only to say that
we will choose an ordering which is likely to be
efficient for accessing the object content. That leaves
the door open for further changes in the future without
having to add another compatibility option.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-11 02:24:57 +03:00
|
|
|
int unordered;
|
2016-09-09 13:10:54 +03:00
|
|
|
int cmdmode; /* may be 'w' or 'c' for --filters or --textconv */
|
2015-06-22 13:41:03 +03:00
|
|
|
const char *format;
|
|
|
|
};
|
|
|
|
|
2016-09-09 13:10:50 +03:00
|
|
|
static const char *force_path;
|
|
|
|
|
2016-08-24 15:23:39 +03:00
|
|
|
static int filter_object(const char *path, unsigned mode,
|
2016-09-22 01:15:18 +03:00
|
|
|
const struct object_id *oid,
|
2016-08-24 15:23:39 +03:00
|
|
|
char **buf, unsigned long *size)
|
|
|
|
{
|
|
|
|
enum object_type type;
|
|
|
|
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
*buf = read_object_file(oid, &type, size);
|
2016-08-24 15:23:39 +03:00
|
|
|
if (!*buf)
|
|
|
|
return error(_("cannot read object %s '%s'"),
|
2016-09-22 01:15:18 +03:00
|
|
|
oid_to_hex(oid), path);
|
2016-08-24 15:23:39 +03:00
|
|
|
if ((type == OBJ_BLOB) && S_ISREG(mode)) {
|
|
|
|
struct strbuf strbuf = STRBUF_INIT;
|
2020-03-16 21:05:03 +03:00
|
|
|
struct checkout_metadata meta;
|
|
|
|
|
|
|
|
init_checkout_metadata(&meta, NULL, NULL, oid);
|
|
|
|
if (convert_to_working_tree(&the_index, path, *buf, *size, &strbuf, &meta)) {
|
2016-08-24 15:23:39 +03:00
|
|
|
free(*buf);
|
|
|
|
*size = strbuf.len;
|
|
|
|
*buf = strbuf_detach(&strbuf, NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-10-31 02:23:38 +03:00
|
|
|
static int stream_blob(const struct object_id *oid)
|
|
|
|
{
|
|
|
|
if (stream_blob_to_fd(1, oid, NULL, 0))
|
|
|
|
die("unable to stream %s to stdout", oid_to_hex(oid));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-03 17:30:01 +03:00
|
|
|
static int cat_one_file(int opt, const char *exp_type, const char *obj_name,
|
|
|
|
int unknown_type)
|
2005-04-08 02:13:13 +04:00
|
|
|
{
|
2016-09-05 23:07:57 +03:00
|
|
|
struct object_id oid;
|
2007-02-26 22:55:59 +03:00
|
|
|
enum object_type type;
|
2010-06-15 19:50:28 +04:00
|
|
|
char *buf;
|
2005-04-08 02:13:13 +04:00
|
|
|
unsigned long size;
|
2010-06-15 19:50:28 +04:00
|
|
|
struct object_context obj_context;
|
provide an initializer for "struct object_info"
An all-zero initializer is fine for this struct, but because
the first element is a pointer, call sites need to know to
use "NULL" instead of "0". Otherwise some static checkers
like "sparse" will complain; see d099b71 (Fix some sparse
warnings, 2013-07-18) for example. So let's provide an
initializer to make this easier to get right.
But let's also comment that memset() to zero is explicitly
OK[1]. One of the callers embeds object_info in another
struct which is initialized via memset (expand_data in
builtin/cat-file.c). Since our subset of C doesn't allow
assignment from a compound literal, handling this in any
other way is awkward, so we'd like to keep the ability to
initialize by memset(). By documenting this property, it
should make anybody who wants to change the initializer
think twice before doing so.
There's one other caller of interest. In parse_sha1_header(),
we did not initialize the struct fully in the first place.
This turned out not to be a bug because the sub-function it
calls does not look at any other fields except the ones we
did initialize. But that assumption might not hold in the
future, so it's a dangerous construct. This patch switches
it to initializing the whole struct, which protects us
against unexpected reads of the other fields.
[1] Obviously using memset() to initialize a pointer
violates the C standard, but we long ago decided that it
was an acceptable tradeoff in the real world.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11 12:24:35 +03:00
|
|
|
struct object_info oi = OBJECT_INFO_INIT;
|
2015-05-03 17:30:01 +03:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2017-06-22 03:40:19 +03:00
|
|
|
unsigned flags = OBJECT_INFO_LOOKUP_REPLACE;
|
2016-09-09 13:10:50 +03:00
|
|
|
const char *path = force_path;
|
2015-05-03 17:30:01 +03:00
|
|
|
|
|
|
|
if (unknown_type)
|
2017-06-22 03:40:18 +03:00
|
|
|
flags |= OBJECT_INFO_ALLOW_UNKNOWN_TYPE;
|
2007-04-22 05:14:39 +04:00
|
|
|
|
2019-01-12 05:13:28 +03:00
|
|
|
if (get_oid_with_context(the_repository, obj_name,
|
|
|
|
GET_OID_RECORD_PATH,
|
sha1_name: convert get_sha1* to get_oid*
Now that all the callers of get_sha1 directly or indirectly use struct
object_id, rename the functions starting with get_sha1 to start with
get_oid. Convert the internals in sha1_name.c to use struct object_id
as well, and eliminate explicit length checks where possible. Convert a
use of 40 in get_oid_basic to GIT_SHA1_HEXSZ.
Outside of sha1_name.c and cache.h, this transition was made with the
following semantic patch:
@@
expression E1, E2;
@@
- get_sha1(E1, E2.hash)
+ get_oid(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1(E1, E2->hash)
+ get_oid(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_committish(E1, E2.hash)
+ get_oid_committish(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_committish(E1, E2->hash)
+ get_oid_committish(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_treeish(E1, E2.hash)
+ get_oid_treeish(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_treeish(E1, E2->hash)
+ get_oid_treeish(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_commit(E1, E2.hash)
+ get_oid_commit(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_commit(E1, E2->hash)
+ get_oid_commit(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_tree(E1, E2.hash)
+ get_oid_tree(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_tree(E1, E2->hash)
+ get_oid_tree(E1, E2)
@@
expression E1, E2;
@@
- get_sha1_blob(E1, E2.hash)
+ get_oid_blob(E1, &E2)
@@
expression E1, E2;
@@
- get_sha1_blob(E1, E2->hash)
+ get_oid_blob(E1, E2)
@@
expression E1, E2, E3, E4;
@@
- get_sha1_with_context(E1, E2, E3.hash, E4)
+ get_oid_with_context(E1, E2, &E3, E4)
@@
expression E1, E2, E3, E4;
@@
- get_sha1_with_context(E1, E2, E3->hash, E4)
+ get_oid_with_context(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-14 02:49:28 +03:00
|
|
|
&oid, &obj_context))
|
2007-04-22 05:14:39 +04:00
|
|
|
die("Not a valid object name %s", obj_name);
|
2005-12-04 04:57:48 +03:00
|
|
|
|
2016-09-09 13:10:50 +03:00
|
|
|
if (!path)
|
|
|
|
path = obj_context.path;
|
|
|
|
if (obj_context.mode == S_IFINVALID)
|
|
|
|
obj_context.mode = 0100644;
|
|
|
|
|
2005-12-04 04:57:48 +03:00
|
|
|
buf = NULL;
|
|
|
|
switch (opt) {
|
|
|
|
case 't':
|
2018-02-14 21:59:23 +03:00
|
|
|
oi.type_name = &sb;
|
2018-04-25 21:20:58 +03:00
|
|
|
if (oid_object_info_extended(the_repository, &oid, &oi, flags) < 0)
|
2015-05-03 17:30:01 +03:00
|
|
|
die("git cat-file: could not get object info");
|
|
|
|
if (sb.len) {
|
|
|
|
printf("%s\n", sb.buf);
|
|
|
|
strbuf_release(&sb);
|
2005-06-28 10:58:45 +04:00
|
|
|
return 0;
|
2005-05-02 06:28:18 +04:00
|
|
|
}
|
2005-12-04 04:57:48 +03:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 's':
|
2015-05-03 17:30:01 +03:00
|
|
|
oi.sizep = &size;
|
2018-04-25 21:20:58 +03:00
|
|
|
if (oid_object_info_extended(the_repository, &oid, &oi, flags) < 0)
|
2015-05-03 17:30:01 +03:00
|
|
|
die("git cat-file: could not get object info");
|
2018-11-11 10:05:04 +03:00
|
|
|
printf("%"PRIuMAX"\n", (uintmax_t)size);
|
2015-05-03 17:30:01 +03:00
|
|
|
return 0;
|
2005-12-04 04:57:48 +03:00
|
|
|
|
|
|
|
case 'e':
|
2016-09-05 23:07:57 +03:00
|
|
|
return !has_object_file(&oid);
|
2005-12-04 04:57:48 +03:00
|
|
|
|
2016-08-24 15:23:39 +03:00
|
|
|
case 'w':
|
2017-09-21 09:21:40 +03:00
|
|
|
if (!path)
|
2016-08-24 15:23:39 +03:00
|
|
|
die("git cat-file --filters %s: <object> must be "
|
|
|
|
"<sha1:path>", obj_name);
|
|
|
|
|
2016-09-09 13:10:50 +03:00
|
|
|
if (filter_object(path, obj_context.mode,
|
2016-09-22 01:15:18 +03:00
|
|
|
&oid, &buf, &size))
|
2016-08-24 15:23:39 +03:00
|
|
|
return -1;
|
|
|
|
break;
|
|
|
|
|
2013-05-10 19:10:13 +04:00
|
|
|
case 'c':
|
2017-09-21 09:21:40 +03:00
|
|
|
if (!path)
|
2013-05-10 19:10:13 +04:00
|
|
|
die("git cat-file --textconv %s: <object> must be <sha1:path>",
|
|
|
|
obj_name);
|
|
|
|
|
2018-09-21 18:57:22 +03:00
|
|
|
if (textconv_object(the_repository, path, obj_context.mode,
|
|
|
|
&oid, 1, &buf, &size))
|
2013-05-10 19:10:13 +04:00
|
|
|
break;
|
consistently use "fallthrough" comments in switches
Gcc 7 adds -Wimplicit-fallthrough, which can warn when a
switch case falls through to the next case. The general idea
is that the compiler can't tell if this was intentional or
not, so you should annotate any intentional fall-throughs as
such, leaving it to complain about any unannotated ones.
There's a GNU __attribute__ which can be used for
annotation, but of course we'd have to #ifdef it away on
non-gcc compilers. Gcc will also recognize
specially-formatted comments, which matches our current
practice. Let's extend that practice to all of the
unannotated sites (which I did look over and verify that
they were behaving as intended).
Ideally in each case we'd actually give some reasons in the
comment about why we're falling through, or what we're
falling through to. And gcc does support that with
-Wimplicit-fallthrough=2, which relaxes the comment pattern
matching to anything that contains "fallthrough" (or a
variety of spelling variants). However, this isn't the
default for -Wimplicit-fallthrough, nor for -Wextra. In the
name of simplicity, it's probably better for us to support
the default level, which requires "fallthrough" to be the
only thing in the comment (modulo some window dressing like
"else" and some punctuation; see the gcc manual for the
complete set of patterns).
This patch suppresses all warnings due to
-Wimplicit-fallthrough. We might eventually want to add that
to the DEVELOPER Makefile knob, but we should probably wait
until gcc 7 is more widely adopted (since earlier versions
will complain about the unknown warning type).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-21 09:25:41 +03:00
|
|
|
/* else fallthrough */
|
2013-05-10 19:10:13 +04:00
|
|
|
|
2006-03-02 03:43:19 +03:00
|
|
|
case 'p':
|
2018-04-25 21:20:59 +03:00
|
|
|
type = oid_object_info(the_repository, &oid, NULL);
|
2007-02-26 22:55:59 +03:00
|
|
|
if (type < 0)
|
2007-04-22 05:14:39 +04:00
|
|
|
die("Not a valid object name %s", obj_name);
|
2006-03-02 03:43:19 +03:00
|
|
|
|
|
|
|
/* custom pretty-print here */
|
2007-04-22 05:14:39 +04:00
|
|
|
if (type == OBJ_TREE) {
|
2010-05-14 13:31:33 +04:00
|
|
|
const char *ls_args[3] = { NULL };
|
|
|
|
ls_args[0] = "ls-tree";
|
|
|
|
ls_args[1] = obj_name;
|
2007-04-22 05:14:39 +04:00
|
|
|
return cmd_ls_tree(2, ls_args, NULL);
|
|
|
|
}
|
2006-03-02 03:43:19 +03:00
|
|
|
|
2012-03-07 14:54:17 +04:00
|
|
|
if (type == OBJ_BLOB)
|
2018-10-31 02:23:38 +03:00
|
|
|
return stream_blob(&oid);
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
buf = read_object_file(&oid, &type, &size);
|
2006-03-02 03:43:19 +03:00
|
|
|
if (!buf)
|
2007-04-22 05:14:39 +04:00
|
|
|
die("Cannot read object %s", obj_name);
|
2006-03-02 03:43:19 +03:00
|
|
|
|
|
|
|
/* otherwise just spit out the data */
|
|
|
|
break;
|
2010-06-15 19:50:28 +04:00
|
|
|
|
2005-12-04 04:57:48 +03:00
|
|
|
case 0:
|
2012-03-07 14:54:17 +04:00
|
|
|
if (type_from_string(exp_type) == OBJ_BLOB) {
|
2016-09-05 23:07:57 +03:00
|
|
|
struct object_id blob_oid;
|
2018-04-25 21:20:59 +03:00
|
|
|
if (oid_object_info(the_repository, &oid, NULL) == OBJ_TAG) {
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
char *buffer = read_object_file(&oid, &type,
|
|
|
|
&size);
|
2014-10-04 22:54:50 +04:00
|
|
|
const char *target;
|
|
|
|
if (!skip_prefix(buffer, "object ", &target) ||
|
2016-09-05 23:07:57 +03:00
|
|
|
get_oid_hex(target, &blob_oid))
|
|
|
|
die("%s not a valid tag", oid_to_hex(&oid));
|
2012-03-07 14:54:17 +04:00
|
|
|
free(buffer);
|
|
|
|
} else
|
2016-09-05 23:07:57 +03:00
|
|
|
oidcpy(&blob_oid, &oid);
|
2012-03-07 14:54:17 +04:00
|
|
|
|
2018-04-25 21:20:59 +03:00
|
|
|
if (oid_object_info(the_repository, &blob_oid, NULL) == OBJ_BLOB)
|
2018-10-31 02:23:38 +03:00
|
|
|
return stream_blob(&blob_oid);
|
2012-03-07 14:54:17 +04:00
|
|
|
/*
|
|
|
|
* we attempted to dereference a tag to a blob
|
|
|
|
* and failed; there may be new dereference
|
|
|
|
* mechanisms this code is not aware of.
|
|
|
|
* fall-back to the usual case.
|
|
|
|
*/
|
|
|
|
}
|
2019-06-27 12:28:47 +03:00
|
|
|
buf = read_object_with_reference(the_repository,
|
|
|
|
&oid, exp_type, &size, NULL);
|
2005-12-04 04:57:48 +03:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2009-01-04 21:38:41 +03:00
|
|
|
die("git cat-file: unknown option: %s", exp_type);
|
2005-04-08 20:16:38 +04:00
|
|
|
}
|
|
|
|
|
2005-05-02 06:28:18 +04:00
|
|
|
if (!buf)
|
2008-08-30 15:12:53 +04:00
|
|
|
die("git cat-file %s: bad file", obj_name);
|
2005-05-02 06:28:18 +04:00
|
|
|
|
2006-08-21 22:43:43 +04:00
|
|
|
write_or_die(1, buf, size);
|
2017-05-04 16:56:17 +03:00
|
|
|
free(buf);
|
2017-05-19 15:54:43 +03:00
|
|
|
free(obj_context.path);
|
2005-04-08 20:16:38 +04:00
|
|
|
return 0;
|
2005-04-08 02:13:13 +04:00
|
|
|
}
|
2008-04-23 23:17:44 +04:00
|
|
|
|
2013-07-10 15:45:47 +04:00
|
|
|
struct expand_data {
|
2016-09-05 23:07:56 +03:00
|
|
|
struct object_id oid;
|
2013-07-10 15:45:47 +04:00
|
|
|
enum object_type type;
|
|
|
|
unsigned long size;
|
2016-07-13 18:43:59 +03:00
|
|
|
off_t disk_size;
|
cat-file: only split on whitespace when %(rest) is used
Commit c334b87b (cat-file: split --batch input lines on whitespace,
2013-07-11) taught `cat-file --batch-check` to split input lines on
the first whitespace, and stash everything after the first token
into the %(rest) output format element. It claimed:
Object names cannot contain spaces, so any input with
spaces would have resulted in a "missing" line.
But that is not correct. Refs, object sha1s, and various peeling
suffixes cannot contain spaces, but some object names can. In
particular:
1. Tree paths like "[<tree>]:path with whitespace"
2. Reflog specifications like "@{2 days ago}"
3. Commit searches like "rev^{/grep me}" or ":/grep me"
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit reverted.
Resurrect its attempt but in a weaker form; only do the splitting
when "%(rest)" is used in the output format. Since that element did
not exist at all before c334b87, old scripts cannot be affected.
The existence of object names with spaces does mean that you
cannot reliably do:
echo ":path with space and other data" |
git cat-file --batch-check="%(objectname) %(rest)"
as it would split the path and feed only ":path" to get_sha1. But
that command is nonsensical. If you wanted to see "and other data"
in "%(rest)", git cannot possibly know where the filename ends and
the "rest" begins.
It might be more robust to have something like "-z" to separate the
input elements. But this patch is still a reasonable step before
having that. It makes the easy cases easy; people who do not care
about %(rest) do not have to consider it, and the %(rest) code
handles the spaces and newlines of "rev-list --objects" correctly.
Hard cases remain hard but possible (if you might get whitespace in
your input, you do not get to use %(rest) and must split and join
the output yourself using more flexible tools). And most
importantly, it does not preclude us from having different splitting
rules later if a "-z" (or similar) option is added. So we can make
the hard cases easier later, if we choose to.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02 15:59:07 +04:00
|
|
|
const char *rest;
|
2016-09-05 23:07:56 +03:00
|
|
|
struct object_id delta_base_oid;
|
2013-07-10 15:45:47 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If mark_query is true, we do not expand anything, but rather
|
|
|
|
* just mark the object_info with items we wish to query.
|
|
|
|
*/
|
|
|
|
int mark_query;
|
|
|
|
|
cat-file: only split on whitespace when %(rest) is used
Commit c334b87b (cat-file: split --batch input lines on whitespace,
2013-07-11) taught `cat-file --batch-check` to split input lines on
the first whitespace, and stash everything after the first token
into the %(rest) output format element. It claimed:
Object names cannot contain spaces, so any input with
spaces would have resulted in a "missing" line.
But that is not correct. Refs, object sha1s, and various peeling
suffixes cannot contain spaces, but some object names can. In
particular:
1. Tree paths like "[<tree>]:path with whitespace"
2. Reflog specifications like "@{2 days ago}"
3. Commit searches like "rev^{/grep me}" or ":/grep me"
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit reverted.
Resurrect its attempt but in a weaker form; only do the splitting
when "%(rest)" is used in the output format. Since that element did
not exist at all before c334b87, old scripts cannot be affected.
The existence of object names with spaces does mean that you
cannot reliably do:
echo ":path with space and other data" |
git cat-file --batch-check="%(objectname) %(rest)"
as it would split the path and feed only ":path" to get_sha1. But
that command is nonsensical. If you wanted to see "and other data"
in "%(rest)", git cannot possibly know where the filename ends and
the "rest" begins.
It might be more robust to have something like "-z" to separate the
input elements. But this patch is still a reasonable step before
having that. It makes the easy cases easy; people who do not care
about %(rest) do not have to consider it, and the %(rest) code
handles the spaces and newlines of "rev-list --objects" correctly.
Hard cases remain hard but possible (if you might get whitespace in
your input, you do not get to use %(rest) and must split and join
the output yourself using more flexible tools). And most
importantly, it does not preclude us from having different splitting
rules later if a "-z" (or similar) option is added. So we can make
the hard cases easier later, if we choose to.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02 15:59:07 +04:00
|
|
|
/*
|
|
|
|
* Whether to split the input on whitespace before feeding it to
|
|
|
|
* get_sha1; this is decided during the mark_query phase based on
|
|
|
|
* whether we have a %(rest) token in our format.
|
|
|
|
*/
|
|
|
|
int split_on_whitespace;
|
|
|
|
|
2013-07-10 15:45:47 +04:00
|
|
|
/*
|
|
|
|
* After a mark_query run, this object_info is set up to be
|
2019-01-07 11:34:12 +03:00
|
|
|
* passed to oid_object_info_extended. It will point to the data
|
2013-07-10 15:45:47 +04:00
|
|
|
* elements above, so you can retrieve the response from there.
|
|
|
|
*/
|
|
|
|
struct object_info info;
|
cat-file: avoid noop calls to sha1_object_info_extended
It is not unreasonable to ask cat-file for a batch-check
format of simply "%(objectname)". At first glance this seems
like a noop (you are generally already feeding the object
names on stdin!), but it has a few uses:
1. With --batch-all-objects, you can generate a listing of
the sha1s present in the repository, without any input.
2. You do not have to feed sha1s; you can feed arbitrary
sha1 expressions and have git resolve them en masse.
3. You can even feed a raw sha1, with the result that git
will tell you whether we actually have the object or
not.
In case 3, the call to sha1_object_info is useful; it tells
us whether the object exists or not (technically we could
swap this out for has_sha1_file, but the cost is roughly the
same).
In case 2, the existence check is of debatable value. A
mass-resolution might prefer performance to safety (against
outputting a value for a corrupted ref, for example).
However, the object lookup cost is likely not as noticeable
compared to the resolution cost. And since we have provided
that safety in the past, the conservative choice is to keep
it.
In case 1, though, the object lookup is a definite noop; we
know about the object because we found it in the object
database. There is no new information gained by making the
call.
This patch detects that case and optimizes out the call.
Here are best-of-five timings for linux.git:
[before]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m2.117s
user 0m2.044s
sys 0m0.072s
[after]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m1.230s
user 0m1.176s
sys 0m0.052s
There are two implementation details to note here.
One is that we detect the noop case by seeing that "struct
object_info" does not request any information. But besides
object existence, there is one other piece of information
which sha1_object_info may fill in: whether the object is
cached, loose, or packed. We don't currently provide that
information in the output, but if we were to do so later,
we'd need to take note and disable the optimization in that
case.
And that leads to the second note. If we were to output
that information, a better implementation would be to
remember where we saw the object in --batch-all-objects in
the first place, and avoid looking it up again by sha1.
In fact, we could probably squeeze out some extra
performance for less-trivial cases, too, by remembering the
pack location where we saw the object, and going directly
there to find its information (like type, size, etc). That
would in theory make this optimization unnecessary.
I didn't pursue that path here for two reasons:
1. It's non-trivial to implement, and has memory
implications. Because we sort and de-dup the list of
output sha1s, we'd have to record the pack information
for each object, too.
2. It doesn't save as much as you might hope. It saves the
find_pack_entry() call, but getting the size and type
for deltified objects requires walking down the delta
chain (for the real type) or reading the delta data
header (for the size). These costs tend to dominate the
non-trivial cases.
By contrast, this optimization is easy and self-contained,
and speeds up a real-world case I've used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:55:23 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This flag will be true if the requested batch format and options
|
2019-01-07 11:34:12 +03:00
|
|
|
* don't require us to call oid_object_info, which can then be
|
cat-file: avoid noop calls to sha1_object_info_extended
It is not unreasonable to ask cat-file for a batch-check
format of simply "%(objectname)". At first glance this seems
like a noop (you are generally already feeding the object
names on stdin!), but it has a few uses:
1. With --batch-all-objects, you can generate a listing of
the sha1s present in the repository, without any input.
2. You do not have to feed sha1s; you can feed arbitrary
sha1 expressions and have git resolve them en masse.
3. You can even feed a raw sha1, with the result that git
will tell you whether we actually have the object or
not.
In case 3, the call to sha1_object_info is useful; it tells
us whether the object exists or not (technically we could
swap this out for has_sha1_file, but the cost is roughly the
same).
In case 2, the existence check is of debatable value. A
mass-resolution might prefer performance to safety (against
outputting a value for a corrupted ref, for example).
However, the object lookup cost is likely not as noticeable
compared to the resolution cost. And since we have provided
that safety in the past, the conservative choice is to keep
it.
In case 1, though, the object lookup is a definite noop; we
know about the object because we found it in the object
database. There is no new information gained by making the
call.
This patch detects that case and optimizes out the call.
Here are best-of-five timings for linux.git:
[before]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m2.117s
user 0m2.044s
sys 0m0.072s
[after]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m1.230s
user 0m1.176s
sys 0m0.052s
There are two implementation details to note here.
One is that we detect the noop case by seeing that "struct
object_info" does not request any information. But besides
object existence, there is one other piece of information
which sha1_object_info may fill in: whether the object is
cached, loose, or packed. We don't currently provide that
information in the output, but if we were to do so later,
we'd need to take note and disable the optimization in that
case.
And that leads to the second note. If we were to output
that information, a better implementation would be to
remember where we saw the object in --batch-all-objects in
the first place, and avoid looking it up again by sha1.
In fact, we could probably squeeze out some extra
performance for less-trivial cases, too, by remembering the
pack location where we saw the object, and going directly
there to find its information (like type, size, etc). That
would in theory make this optimization unnecessary.
I didn't pursue that path here for two reasons:
1. It's non-trivial to implement, and has memory
implications. Because we sort and de-dup the list of
output sha1s, we'd have to record the pack information
for each object, too.
2. It doesn't save as much as you might hope. It saves the
find_pack_entry() call, but getting the size and type
for deltified objects requires walking down the delta
chain (for the real type) or reading the delta data
header (for the size). These costs tend to dominate the
non-trivial cases.
By contrast, this optimization is easy and self-contained,
and speeds up a real-world case I've used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:55:23 +03:00
|
|
|
* optimized out.
|
|
|
|
*/
|
|
|
|
unsigned skip_object_info : 1;
|
2013-07-10 15:45:47 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static int is_atom(const char *atom, const char *s, int slen)
|
|
|
|
{
|
|
|
|
int alen = strlen(atom);
|
|
|
|
return alen == slen && !memcmp(atom, s, alen);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void expand_atom(struct strbuf *sb, const char *atom, int len,
|
|
|
|
void *vdata)
|
|
|
|
{
|
|
|
|
struct expand_data *data = vdata;
|
|
|
|
|
|
|
|
if (is_atom("objectname", atom, len)) {
|
|
|
|
if (!data->mark_query)
|
2016-09-05 23:07:56 +03:00
|
|
|
strbuf_addstr(sb, oid_to_hex(&data->oid));
|
2013-07-10 15:45:47 +04:00
|
|
|
} else if (is_atom("objecttype", atom, len)) {
|
2013-07-12 10:34:57 +04:00
|
|
|
if (data->mark_query)
|
|
|
|
data->info.typep = &data->type;
|
|
|
|
else
|
2018-02-14 21:59:24 +03:00
|
|
|
strbuf_addstr(sb, type_name(data->type));
|
2013-07-10 15:45:47 +04:00
|
|
|
} else if (is_atom("objectsize", atom, len)) {
|
|
|
|
if (data->mark_query)
|
|
|
|
data->info.sizep = &data->size;
|
|
|
|
else
|
2018-11-11 10:05:04 +03:00
|
|
|
strbuf_addf(sb, "%"PRIuMAX , (uintmax_t)data->size);
|
2013-07-10 15:46:25 +04:00
|
|
|
} else if (is_atom("objectsize:disk", atom, len)) {
|
|
|
|
if (data->mark_query)
|
|
|
|
data->info.disk_sizep = &data->disk_size;
|
|
|
|
else
|
2016-07-13 18:43:59 +03:00
|
|
|
strbuf_addf(sb, "%"PRIuMAX, (uintmax_t)data->disk_size);
|
cat-file: only split on whitespace when %(rest) is used
Commit c334b87b (cat-file: split --batch input lines on whitespace,
2013-07-11) taught `cat-file --batch-check` to split input lines on
the first whitespace, and stash everything after the first token
into the %(rest) output format element. It claimed:
Object names cannot contain spaces, so any input with
spaces would have resulted in a "missing" line.
But that is not correct. Refs, object sha1s, and various peeling
suffixes cannot contain spaces, but some object names can. In
particular:
1. Tree paths like "[<tree>]:path with whitespace"
2. Reflog specifications like "@{2 days ago}"
3. Commit searches like "rev^{/grep me}" or ":/grep me"
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit reverted.
Resurrect its attempt but in a weaker form; only do the splitting
when "%(rest)" is used in the output format. Since that element did
not exist at all before c334b87, old scripts cannot be affected.
The existence of object names with spaces does mean that you
cannot reliably do:
echo ":path with space and other data" |
git cat-file --batch-check="%(objectname) %(rest)"
as it would split the path and feed only ":path" to get_sha1. But
that command is nonsensical. If you wanted to see "and other data"
in "%(rest)", git cannot possibly know where the filename ends and
the "rest" begins.
It might be more robust to have something like "-z" to separate the
input elements. But this patch is still a reasonable step before
having that. It makes the easy cases easy; people who do not care
about %(rest) do not have to consider it, and the %(rest) code
handles the spaces and newlines of "rev-list --objects" correctly.
Hard cases remain hard but possible (if you might get whitespace in
your input, you do not get to use %(rest) and must split and join
the output yourself using more flexible tools). And most
importantly, it does not preclude us from having different splitting
rules later if a "-z" (or similar) option is added. So we can make
the hard cases easier later, if we choose to.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02 15:59:07 +04:00
|
|
|
} else if (is_atom("rest", atom, len)) {
|
|
|
|
if (data->mark_query)
|
|
|
|
data->split_on_whitespace = 1;
|
|
|
|
else if (data->rest)
|
|
|
|
strbuf_addstr(sb, data->rest);
|
2013-12-21 18:25:22 +04:00
|
|
|
} else if (is_atom("deltabase", atom, len)) {
|
|
|
|
if (data->mark_query)
|
2020-02-24 07:36:56 +03:00
|
|
|
data->info.delta_base_oid = &data->delta_base_oid;
|
2013-12-21 18:25:22 +04:00
|
|
|
else
|
2016-09-05 23:07:56 +03:00
|
|
|
strbuf_addstr(sb,
|
|
|
|
oid_to_hex(&data->delta_base_oid));
|
2013-07-10 15:45:47 +04:00
|
|
|
} else
|
|
|
|
die("unknown format element: %.*s", len, atom);
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t expand_format(struct strbuf *sb, const char *start, void *data)
|
|
|
|
{
|
|
|
|
const char *end;
|
|
|
|
|
|
|
|
if (*start != '(')
|
|
|
|
return 0;
|
|
|
|
end = strchr(start + 1, ')');
|
|
|
|
if (!end)
|
|
|
|
die("format element '%s' does not end in ')'", start);
|
|
|
|
|
|
|
|
expand_atom(sb, start + 1, end - start - 1, data);
|
|
|
|
|
|
|
|
return end - start + 1;
|
|
|
|
}
|
|
|
|
|
2015-06-22 13:45:17 +03:00
|
|
|
static void batch_write(struct batch_options *opt, const void *data, int len)
|
|
|
|
{
|
|
|
|
if (opt->buffer_output) {
|
|
|
|
if (fwrite(data, 1, len, stdout) != len)
|
|
|
|
die_errno("unable to write to stdout");
|
|
|
|
} else
|
|
|
|
write_or_die(1, data, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void print_object_or_die(struct batch_options *opt, struct expand_data *data)
|
2013-07-10 15:38:24 +04:00
|
|
|
{
|
2016-09-05 23:07:57 +03:00
|
|
|
const struct object_id *oid = &data->oid;
|
2013-12-12 03:01:42 +04:00
|
|
|
|
cat-file: handle --batch format with missing type/size
Commit 98e2092 taught cat-file to stream blobs with --batch,
which requires that we look up the object type before
loading it into memory. As a result, we now print the
object header from information in sha1_object_info, and the
actual contents from the read_sha1_file. We double-check
that the information we printed in the header matches the
content we are about to show.
Later, commit 93d2a60 allowed custom header lines for
--batch, and commit 5b08640 made type lookups optional. As a
result, specifying a header line without the type or size
means that we will not look up those items at all.
This causes our double-checking to erroneously die with an
error; we think the type or size has changed, when in fact
it was simply left at "0".
For the size, we can fix this by only doing the consistency
double-check when we have retrieved the size via
sha1_object_info. In the case that we have not retrieved the
value, that means we also did not print it, so there is
nothing for us to check that we are consistent with.
We could do the same for the type. However, besides our
consistency check, we also care about the type in deciding
whether to stream or not. So instead of handling the case
where we do not know the type, this patch instead makes sure
that we always trigger a type lookup when we are printing,
so that even a format without the type will stream as we
would in the normal case.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12 03:15:50 +04:00
|
|
|
assert(data->info.typep);
|
|
|
|
|
2013-12-12 03:01:42 +04:00
|
|
|
if (data->type == OBJ_BLOB) {
|
2015-06-22 13:45:17 +03:00
|
|
|
if (opt->buffer_output)
|
|
|
|
fflush(stdout);
|
2016-09-09 13:10:54 +03:00
|
|
|
if (opt->cmdmode) {
|
|
|
|
char *contents;
|
|
|
|
unsigned long size;
|
|
|
|
|
|
|
|
if (!data->rest)
|
2016-09-22 01:15:18 +03:00
|
|
|
die("missing path for '%s'", oid_to_hex(oid));
|
2016-09-09 13:10:54 +03:00
|
|
|
|
|
|
|
if (opt->cmdmode == 'w') {
|
2016-09-22 01:15:18 +03:00
|
|
|
if (filter_object(data->rest, 0100644, oid,
|
2016-09-09 13:10:54 +03:00
|
|
|
&contents, &size))
|
|
|
|
die("could not convert '%s' %s",
|
2016-09-22 01:15:18 +03:00
|
|
|
oid_to_hex(oid), data->rest);
|
2016-09-09 13:10:54 +03:00
|
|
|
} else if (opt->cmdmode == 'c') {
|
|
|
|
enum object_type type;
|
2018-09-21 18:57:22 +03:00
|
|
|
if (!textconv_object(the_repository,
|
|
|
|
data->rest, 0100644, oid,
|
2016-09-09 13:10:54 +03:00
|
|
|
1, &contents, &size))
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
contents = read_object_file(oid,
|
|
|
|
&type,
|
|
|
|
&size);
|
2016-09-09 13:10:54 +03:00
|
|
|
if (!contents)
|
|
|
|
die("could not convert '%s' %s",
|
2016-09-22 01:15:18 +03:00
|
|
|
oid_to_hex(oid), data->rest);
|
2016-09-09 13:10:54 +03:00
|
|
|
} else
|
2018-05-02 12:38:39 +03:00
|
|
|
BUG("invalid cmdmode: %c", opt->cmdmode);
|
2016-09-09 13:10:54 +03:00
|
|
|
batch_write(opt, contents, size);
|
|
|
|
free(contents);
|
2018-10-31 02:23:38 +03:00
|
|
|
} else {
|
|
|
|
stream_blob(oid);
|
|
|
|
}
|
2013-07-10 15:38:24 +04:00
|
|
|
}
|
|
|
|
else {
|
2013-12-12 03:01:42 +04:00
|
|
|
enum object_type type;
|
|
|
|
unsigned long size;
|
2013-07-10 15:38:24 +04:00
|
|
|
void *contents;
|
|
|
|
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:53 +03:00
|
|
|
contents = read_object_file(oid, &type, &size);
|
2013-07-10 15:38:24 +04:00
|
|
|
if (!contents)
|
2016-09-05 23:07:57 +03:00
|
|
|
die("object %s disappeared", oid_to_hex(oid));
|
2013-12-12 03:01:42 +04:00
|
|
|
if (type != data->type)
|
2016-09-05 23:07:57 +03:00
|
|
|
die("object %s changed type!?", oid_to_hex(oid));
|
cat-file: handle --batch format with missing type/size
Commit 98e2092 taught cat-file to stream blobs with --batch,
which requires that we look up the object type before
loading it into memory. As a result, we now print the
object header from information in sha1_object_info, and the
actual contents from the read_sha1_file. We double-check
that the information we printed in the header matches the
content we are about to show.
Later, commit 93d2a60 allowed custom header lines for
--batch, and commit 5b08640 made type lookups optional. As a
result, specifying a header line without the type or size
means that we will not look up those items at all.
This causes our double-checking to erroneously die with an
error; we think the type or size has changed, when in fact
it was simply left at "0".
For the size, we can fix this by only doing the consistency
double-check when we have retrieved the size via
sha1_object_info. In the case that we have not retrieved the
value, that means we also did not print it, so there is
nothing for us to check that we are consistent with.
We could do the same for the type. However, besides our
consistency check, we also care about the type in deciding
whether to stream or not. So instead of handling the case
where we do not know the type, this patch instead makes sure
that we always trigger a type lookup when we are printing,
so that even a format without the type will stream as we
would in the normal case.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12 03:15:50 +04:00
|
|
|
if (data->info.sizep && size != data->size)
|
2016-09-05 23:07:57 +03:00
|
|
|
die("object %s changed size!?", oid_to_hex(oid));
|
2013-07-10 15:38:24 +04:00
|
|
|
|
2015-06-22 13:45:17 +03:00
|
|
|
batch_write(opt, contents, size);
|
2013-07-10 15:38:24 +04:00
|
|
|
free(contents);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-14 21:20:22 +03:00
|
|
|
static void batch_object_write(const char *obj_name,
|
|
|
|
struct strbuf *scratch,
|
|
|
|
struct batch_options *opt,
|
2015-06-22 13:45:41 +03:00
|
|
|
struct expand_data *data)
|
|
|
|
{
|
cat-file: avoid noop calls to sha1_object_info_extended
It is not unreasonable to ask cat-file for a batch-check
format of simply "%(objectname)". At first glance this seems
like a noop (you are generally already feeding the object
names on stdin!), but it has a few uses:
1. With --batch-all-objects, you can generate a listing of
the sha1s present in the repository, without any input.
2. You do not have to feed sha1s; you can feed arbitrary
sha1 expressions and have git resolve them en masse.
3. You can even feed a raw sha1, with the result that git
will tell you whether we actually have the object or
not.
In case 3, the call to sha1_object_info is useful; it tells
us whether the object exists or not (technically we could
swap this out for has_sha1_file, but the cost is roughly the
same).
In case 2, the existence check is of debatable value. A
mass-resolution might prefer performance to safety (against
outputting a value for a corrupted ref, for example).
However, the object lookup cost is likely not as noticeable
compared to the resolution cost. And since we have provided
that safety in the past, the conservative choice is to keep
it.
In case 1, though, the object lookup is a definite noop; we
know about the object because we found it in the object
database. There is no new information gained by making the
call.
This patch detects that case and optimizes out the call.
Here are best-of-five timings for linux.git:
[before]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m2.117s
user 0m2.044s
sys 0m0.072s
[after]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m1.230s
user 0m1.176s
sys 0m0.052s
There are two implementation details to note here.
One is that we detect the noop case by seeing that "struct
object_info" does not request any information. But besides
object existence, there is one other piece of information
which sha1_object_info may fill in: whether the object is
cached, loose, or packed. We don't currently provide that
information in the output, but if we were to do so later,
we'd need to take note and disable the optimization in that
case.
And that leads to the second note. If we were to output
that information, a better implementation would be to
remember where we saw the object in --batch-all-objects in
the first place, and avoid looking it up again by sha1.
In fact, we could probably squeeze out some extra
performance for less-trivial cases, too, by remembering the
pack location where we saw the object, and going directly
there to find its information (like type, size, etc). That
would in theory make this optimization unnecessary.
I didn't pursue that path here for two reasons:
1. It's non-trivial to implement, and has memory
implications. Because we sort and de-dup the list of
output sha1s, we'd have to record the pack information
for each object, too.
2. It doesn't save as much as you might hope. It saves the
find_pack_entry() call, but getting the size and type
for deltified objects requires walking down the delta
chain (for the real type) or reading the delta data
header (for the size). These costs tend to dominate the
non-trivial cases.
By contrast, this optimization is easy and self-contained,
and speeds up a real-world case I've used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:55:23 +03:00
|
|
|
if (!data->skip_object_info &&
|
2018-04-25 21:20:58 +03:00
|
|
|
oid_object_info_extended(the_repository, &data->oid, &data->info,
|
sha1_file: convert sha1_object_info* to object_id
Convert sha1_object_info and sha1_object_info_extended to take pointers
to struct object_id and rename them to use "oid" instead of "sha1" in
their names. Update the declaration and definition and apply the
following semantic patch, plus the standard object_id transforms:
@@
expression E1, E2;
@@
- sha1_object_info(E1.hash, E2)
+ oid_object_info(&E1, E2)
@@
expression E1, E2;
@@
- sha1_object_info(E1->hash, E2)
+ oid_object_info(E1, E2)
@@
expression E1, E2, E3;
@@
- sha1_object_info_extended(E1.hash, E2, E3)
+ oid_object_info_extended(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- sha1_object_info_extended(E1->hash, E2, E3)
+ oid_object_info_extended(E1, E2, E3)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 05:27:46 +03:00
|
|
|
OBJECT_INFO_LOOKUP_REPLACE) < 0) {
|
2016-09-05 23:07:56 +03:00
|
|
|
printf("%s missing\n",
|
|
|
|
obj_name ? obj_name : oid_to_hex(&data->oid));
|
2015-06-22 13:45:41 +03:00
|
|
|
fflush(stdout);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-08-14 21:20:22 +03:00
|
|
|
strbuf_reset(scratch);
|
|
|
|
strbuf_expand(scratch, opt->format, expand_format, data);
|
|
|
|
strbuf_addch(scratch, '\n');
|
|
|
|
batch_write(opt, scratch->buf, scratch->len);
|
2015-06-22 13:45:41 +03:00
|
|
|
|
|
|
|
if (opt->print_contents) {
|
|
|
|
print_object_or_die(opt, data);
|
|
|
|
batch_write(opt, "\n", 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-14 21:20:22 +03:00
|
|
|
static void batch_one_object(const char *obj_name,
|
|
|
|
struct strbuf *scratch,
|
|
|
|
struct batch_options *opt,
|
2015-06-22 13:45:33 +03:00
|
|
|
struct expand_data *data)
|
2008-04-23 23:17:46 +04:00
|
|
|
{
|
2015-05-20 20:03:40 +03:00
|
|
|
struct object_context ctx;
|
2017-07-14 02:49:29 +03:00
|
|
|
int flags = opt->follow_symlinks ? GET_OID_FOLLOW_SYMLINKS : 0;
|
2019-01-18 07:19:43 +03:00
|
|
|
enum get_oid_result result;
|
2008-04-23 23:17:46 +04:00
|
|
|
|
2019-01-12 05:13:28 +03:00
|
|
|
result = get_oid_with_context(the_repository, obj_name,
|
|
|
|
flags, &data->oid, &ctx);
|
2015-05-20 20:03:40 +03:00
|
|
|
if (result != FOUND) {
|
|
|
|
switch (result) {
|
|
|
|
case MISSING_OBJECT:
|
|
|
|
printf("%s missing\n", obj_name);
|
|
|
|
break;
|
2019-01-18 07:19:43 +03:00
|
|
|
case SHORT_NAME_AMBIGUOUS:
|
|
|
|
printf("%s ambiguous\n", obj_name);
|
|
|
|
break;
|
2015-05-20 20:03:40 +03:00
|
|
|
case DANGLING_SYMLINK:
|
|
|
|
printf("dangling %"PRIuMAX"\n%s\n",
|
|
|
|
(uintmax_t)strlen(obj_name), obj_name);
|
|
|
|
break;
|
|
|
|
case SYMLINK_LOOP:
|
|
|
|
printf("loop %"PRIuMAX"\n%s\n",
|
|
|
|
(uintmax_t)strlen(obj_name), obj_name);
|
|
|
|
break;
|
|
|
|
case NOT_DIR:
|
|
|
|
printf("notdir %"PRIuMAX"\n%s\n",
|
|
|
|
(uintmax_t)strlen(obj_name), obj_name);
|
|
|
|
break;
|
|
|
|
default:
|
2018-05-02 12:38:39 +03:00
|
|
|
BUG("unknown get_sha1_with_context result %d\n",
|
2015-05-20 20:03:40 +03:00
|
|
|
result);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
fflush(stdout);
|
2015-06-22 13:45:33 +03:00
|
|
|
return;
|
2015-05-20 20:03:40 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ctx.mode == 0) {
|
|
|
|
printf("symlink %"PRIuMAX"\n%s\n",
|
|
|
|
(uintmax_t)ctx.symlink_path.len,
|
|
|
|
ctx.symlink_path.buf);
|
2008-06-03 22:34:17 +04:00
|
|
|
fflush(stdout);
|
2015-06-22 13:45:33 +03:00
|
|
|
return;
|
2008-04-23 23:17:46 +04:00
|
|
|
}
|
|
|
|
|
2018-08-14 21:20:22 +03:00
|
|
|
batch_object_write(obj_name, scratch, opt, data);
|
2008-04-23 23:17:46 +04:00
|
|
|
}
|
|
|
|
|
2015-06-22 13:45:59 +03:00
|
|
|
struct object_cb_data {
|
|
|
|
struct batch_options *opt;
|
|
|
|
struct expand_data *expand;
|
cat-file: support "unordered" output for --batch-all-objects
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related deltas next to each other. By contrast, hash order
is effectively random, since the sha1 has no discernible
relationship to the content.
This patch introduces an "--unordered" option to cat-file
which iterates over packs in pack-order under the hood. You
can see the results when dumping all of the file content:
$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
6883195596
real 0m44.491s
user 0m42.902s
sys 0m5.230s
$ time ./git cat-file --unordered \
--batch-all-objects --buffer --batch | wc -c
6883195596
real 0m6.075s
user 0m4.774s
sys 0m3.548s
Same output, different order, way faster. The same speed-up
applies even if you end up accessing the object content in a
different process, like:
git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c
Adding "--unordered" to the first command drops the runtime
in git.git from 24s to 3.5s.
Side note: there are actually further speedups available
for doing it all in-process now. Since we are outputting
the object content during the actual pack iteration, we
know where to find the object and could skip the extra
lookup done by oid_object_info(). This patch stops short
of that optimization since the underlying API isn't ready
for us to make those sorts of direct requests.
So if --unordered is so much better, why not make it the
default? Two reasons:
1. We've promised in the documentation that --batch-all-objects
outputs in hash order. Since cat-file is plumbing,
people may be relying on that default, and we can't
change it.
2. It's actually _slower_ for some cases. We have to
compute the pack revindex to walk in pack order. And
our de-duplication step uses an oidset, rather than a
sort-and-dedup, which can end up being more expensive.
If we're just accessing the type and size of each
object, for example, like:
git cat-file --batch-all-objects --buffer --batch-check
my best-of-five warm cache timings go from 900ms to
1100ms using --unordered. Though it's possible in a
cold-cache or under memory pressure that we could do
better, since we'd have better locality within the
packfile.
And one final question: why is it "--unordered" and not
"--pack-order"? The answer is again two-fold:
1. "pack order" isn't a well-defined thing across the
whole set of objects. We're hitting loose objects, as
well as objects in multiple packs, and the only
ordering we're promising is _within_ a single pack. The
rest is apparently random.
2. The point here is optimization. So we don't want to
promise any particular ordering, but only to say that
we will choose an ordering which is likely to be
efficient for accessing the object content. That leaves
the door open for further changes in the future without
having to add another compatibility option.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-11 02:24:57 +03:00
|
|
|
struct oidset *seen;
|
2018-08-14 21:20:22 +03:00
|
|
|
struct strbuf *scratch;
|
2015-06-22 13:45:59 +03:00
|
|
|
};
|
|
|
|
|
2017-03-31 04:39:59 +03:00
|
|
|
static int batch_object_cb(const struct object_id *oid, void *vdata)
|
2015-06-22 13:45:59 +03:00
|
|
|
{
|
2015-06-22 14:06:32 +03:00
|
|
|
struct object_cb_data *data = vdata;
|
2017-03-31 04:39:59 +03:00
|
|
|
oidcpy(&data->expand->oid, oid);
|
2018-08-14 21:20:22 +03:00
|
|
|
batch_object_write(NULL, data->scratch, data->opt, data->expand);
|
2016-09-26 15:00:29 +03:00
|
|
|
return 0;
|
2015-06-22 13:45:59 +03:00
|
|
|
}
|
|
|
|
|
2018-08-11 02:17:14 +03:00
|
|
|
static int collect_loose_object(const struct object_id *oid,
|
|
|
|
const char *path,
|
|
|
|
void *data)
|
2015-06-22 13:45:59 +03:00
|
|
|
{
|
2017-03-31 04:40:00 +03:00
|
|
|
oid_array_append(data, oid);
|
2015-06-22 14:06:32 +03:00
|
|
|
return 0;
|
2015-06-22 13:45:59 +03:00
|
|
|
}
|
|
|
|
|
2018-08-11 02:17:14 +03:00
|
|
|
static int collect_packed_object(const struct object_id *oid,
|
|
|
|
struct packed_git *pack,
|
|
|
|
uint32_t pos,
|
|
|
|
void *data)
|
2015-06-22 13:45:59 +03:00
|
|
|
{
|
2017-03-31 04:40:00 +03:00
|
|
|
oid_array_append(data, oid);
|
2015-06-22 14:06:32 +03:00
|
|
|
return 0;
|
2015-06-22 13:45:59 +03:00
|
|
|
}
|
|
|
|
|
cat-file: support "unordered" output for --batch-all-objects
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related deltas next to each other. By contrast, hash order
is effectively random, since the sha1 has no discernible
relationship to the content.
This patch introduces an "--unordered" option to cat-file
which iterates over packs in pack-order under the hood. You
can see the results when dumping all of the file content:
$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
6883195596
real 0m44.491s
user 0m42.902s
sys 0m5.230s
$ time ./git cat-file --unordered \
--batch-all-objects --buffer --batch | wc -c
6883195596
real 0m6.075s
user 0m4.774s
sys 0m3.548s
Same output, different order, way faster. The same speed-up
applies even if you end up accessing the object content in a
different process, like:
git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c
Adding "--unordered" to the first command drops the runtime
in git.git from 24s to 3.5s.
Side note: there are actually further speedups available
for doing it all in-process now. Since we are outputting
the object content during the actual pack iteration, we
know where to find the object and could skip the extra
lookup done by oid_object_info(). This patch stops short
of that optimization since the underlying API isn't ready
for us to make those sorts of direct requests.
So if --unordered is so much better, why not make it the
default? Two reasons:
1. We've promised in the documentation that --batch-all-objects
outputs in hash order. Since cat-file is plumbing,
people may be relying on that default, and we can't
change it.
2. It's actually _slower_ for some cases. We have to
compute the pack revindex to walk in pack order. And
our de-duplication step uses an oidset, rather than a
sort-and-dedup, which can end up being more expensive.
If we're just accessing the type and size of each
object, for example, like:
git cat-file --batch-all-objects --buffer --batch-check
my best-of-five warm cache timings go from 900ms to
1100ms using --unordered. Though it's possible in a
cold-cache or under memory pressure that we could do
better, since we'd have better locality within the
packfile.
And one final question: why is it "--unordered" and not
"--pack-order"? The answer is again two-fold:
1. "pack order" isn't a well-defined thing across the
whole set of objects. We're hitting loose objects, as
well as objects in multiple packs, and the only
ordering we're promising is _within_ a single pack. The
rest is apparently random.
2. The point here is optimization. So we don't want to
promise any particular ordering, but only to say that
we will choose an ordering which is likely to be
efficient for accessing the object content. That leaves
the door open for further changes in the future without
having to add another compatibility option.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-11 02:24:57 +03:00
|
|
|
static int batch_unordered_object(const struct object_id *oid, void *vdata)
|
|
|
|
{
|
|
|
|
struct object_cb_data *data = vdata;
|
|
|
|
|
2018-08-14 21:14:27 +03:00
|
|
|
if (oidset_insert(data->seen, oid))
|
cat-file: support "unordered" output for --batch-all-objects
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related deltas next to each other. By contrast, hash order
is effectively random, since the sha1 has no discernible
relationship to the content.
This patch introduces an "--unordered" option to cat-file
which iterates over packs in pack-order under the hood. You
can see the results when dumping all of the file content:
$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
6883195596
real 0m44.491s
user 0m42.902s
sys 0m5.230s
$ time ./git cat-file --unordered \
--batch-all-objects --buffer --batch | wc -c
6883195596
real 0m6.075s
user 0m4.774s
sys 0m3.548s
Same output, different order, way faster. The same speed-up
applies even if you end up accessing the object content in a
different process, like:
git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c
Adding "--unordered" to the first command drops the runtime
in git.git from 24s to 3.5s.
Side note: there are actually further speedups available
for doing it all in-process now. Since we are outputting
the object content during the actual pack iteration, we
know where to find the object and could skip the extra
lookup done by oid_object_info(). This patch stops short
of that optimization since the underlying API isn't ready
for us to make those sorts of direct requests.
So if --unordered is so much better, why not make it the
default? Two reasons:
1. We've promised in the documentation that --batch-all-objects
outputs in hash order. Since cat-file is plumbing,
people may be relying on that default, and we can't
change it.
2. It's actually _slower_ for some cases. We have to
compute the pack revindex to walk in pack order. And
our de-duplication step uses an oidset, rather than a
sort-and-dedup, which can end up being more expensive.
If we're just accessing the type and size of each
object, for example, like:
git cat-file --batch-all-objects --buffer --batch-check
my best-of-five warm cache timings go from 900ms to
1100ms using --unordered. Though it's possible in a
cold-cache or under memory pressure that we could do
better, since we'd have better locality within the
packfile.
And one final question: why is it "--unordered" and not
"--pack-order"? The answer is again two-fold:
1. "pack order" isn't a well-defined thing across the
whole set of objects. We're hitting loose objects, as
well as objects in multiple packs, and the only
ordering we're promising is _within_ a single pack. The
rest is apparently random.
2. The point here is optimization. So we don't want to
promise any particular ordering, but only to say that
we will choose an ordering which is likely to be
efficient for accessing the object content. That leaves
the door open for further changes in the future without
having to add another compatibility option.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-11 02:24:57 +03:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return batch_object_cb(oid, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int batch_unordered_loose(const struct object_id *oid,
|
|
|
|
const char *path,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
return batch_unordered_object(oid, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int batch_unordered_packed(const struct object_id *oid,
|
|
|
|
struct packed_git *pack,
|
|
|
|
uint32_t pos,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
return batch_unordered_object(oid, data);
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:38:58 +04:00
|
|
|
static int batch_objects(struct batch_options *opt)
|
2008-04-23 23:17:46 +04:00
|
|
|
{
|
2018-08-14 21:18:06 +03:00
|
|
|
struct strbuf input = STRBUF_INIT;
|
|
|
|
struct strbuf output = STRBUF_INIT;
|
2013-07-10 15:45:47 +04:00
|
|
|
struct expand_data data;
|
2014-03-13 00:05:43 +04:00
|
|
|
int save_warning;
|
2014-01-08 02:10:15 +04:00
|
|
|
int retval = 0;
|
2013-07-10 15:45:47 +04:00
|
|
|
|
|
|
|
if (!opt->format)
|
|
|
|
opt->format = "%(objectname) %(objecttype) %(objectsize)";
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Expand once with our special mark_query flag, which will prime the
|
2019-01-07 11:34:12 +03:00
|
|
|
* object_info to be handed to oid_object_info_extended for each
|
2013-07-10 15:45:47 +04:00
|
|
|
* object.
|
|
|
|
*/
|
|
|
|
memset(&data, 0, sizeof(data));
|
|
|
|
data.mark_query = 1;
|
2018-08-14 21:18:06 +03:00
|
|
|
strbuf_expand(&output, opt->format, expand_format, &data);
|
2013-07-10 15:45:47 +04:00
|
|
|
data.mark_query = 0;
|
2018-08-14 21:18:06 +03:00
|
|
|
strbuf_release(&output);
|
2016-09-09 13:10:54 +03:00
|
|
|
if (opt->cmdmode)
|
|
|
|
data.split_on_whitespace = 1;
|
2008-04-23 23:17:46 +04:00
|
|
|
|
cat-file: avoid noop calls to sha1_object_info_extended
It is not unreasonable to ask cat-file for a batch-check
format of simply "%(objectname)". At first glance this seems
like a noop (you are generally already feeding the object
names on stdin!), but it has a few uses:
1. With --batch-all-objects, you can generate a listing of
the sha1s present in the repository, without any input.
2. You do not have to feed sha1s; you can feed arbitrary
sha1 expressions and have git resolve them en masse.
3. You can even feed a raw sha1, with the result that git
will tell you whether we actually have the object or
not.
In case 3, the call to sha1_object_info is useful; it tells
us whether the object exists or not (technically we could
swap this out for has_sha1_file, but the cost is roughly the
same).
In case 2, the existence check is of debatable value. A
mass-resolution might prefer performance to safety (against
outputting a value for a corrupted ref, for example).
However, the object lookup cost is likely not as noticeable
compared to the resolution cost. And since we have provided
that safety in the past, the conservative choice is to keep
it.
In case 1, though, the object lookup is a definite noop; we
know about the object because we found it in the object
database. There is no new information gained by making the
call.
This patch detects that case and optimizes out the call.
Here are best-of-five timings for linux.git:
[before]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m2.117s
user 0m2.044s
sys 0m0.072s
[after]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m1.230s
user 0m1.176s
sys 0m0.052s
There are two implementation details to note here.
One is that we detect the noop case by seeing that "struct
object_info" does not request any information. But besides
object existence, there is one other piece of information
which sha1_object_info may fill in: whether the object is
cached, loose, or packed. We don't currently provide that
information in the output, but if we were to do so later,
we'd need to take note and disable the optimization in that
case.
And that leads to the second note. If we were to output
that information, a better implementation would be to
remember where we saw the object in --batch-all-objects in
the first place, and avoid looking it up again by sha1.
In fact, we could probably squeeze out some extra
performance for less-trivial cases, too, by remembering the
pack location where we saw the object, and going directly
there to find its information (like type, size, etc). That
would in theory make this optimization unnecessary.
I didn't pursue that path here for two reasons:
1. It's non-trivial to implement, and has memory
implications. Because we sort and de-dup the list of
output sha1s, we'd have to record the pack information
for each object, too.
2. It doesn't save as much as you might hope. It saves the
find_pack_entry() call, but getting the size and type
for deltified objects requires walking down the delta
chain (for the real type) or reading the delta data
header (for the size). These costs tend to dominate the
non-trivial cases.
By contrast, this optimization is easy and self-contained,
and speeds up a real-world case I've used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:55:23 +03:00
|
|
|
if (opt->all_objects) {
|
provide an initializer for "struct object_info"
An all-zero initializer is fine for this struct, but because
the first element is a pointer, call sites need to know to
use "NULL" instead of "0". Otherwise some static checkers
like "sparse" will complain; see d099b71 (Fix some sparse
warnings, 2013-07-18) for example. So let's provide an
initializer to make this easier to get right.
But let's also comment that memset() to zero is explicitly
OK[1]. One of the callers embeds object_info in another
struct which is initialized via memset (expand_data in
builtin/cat-file.c). Since our subset of C doesn't allow
assignment from a compound literal, handling this in any
other way is awkward, so we'd like to keep the ability to
initialize by memset(). By documenting this property, it
should make anybody who wants to change the initializer
think twice before doing so.
There's one other caller of interest. In parse_sha1_header(),
we did not initialize the struct fully in the first place.
This turned out not to be a bug because the sub-function it
calls does not look at any other fields except the ones we
did initialize. But that assumption might not hold in the
future, so it's a dangerous construct. This patch switches
it to initializing the whole struct, which protects us
against unexpected reads of the other fields.
[1] Obviously using memset() to initialize a pointer
violates the C standard, but we long ago decided that it
was an acceptable tradeoff in the real world.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11 12:24:35 +03:00
|
|
|
struct object_info empty = OBJECT_INFO_INIT;
|
cat-file: avoid noop calls to sha1_object_info_extended
It is not unreasonable to ask cat-file for a batch-check
format of simply "%(objectname)". At first glance this seems
like a noop (you are generally already feeding the object
names on stdin!), but it has a few uses:
1. With --batch-all-objects, you can generate a listing of
the sha1s present in the repository, without any input.
2. You do not have to feed sha1s; you can feed arbitrary
sha1 expressions and have git resolve them en masse.
3. You can even feed a raw sha1, with the result that git
will tell you whether we actually have the object or
not.
In case 3, the call to sha1_object_info is useful; it tells
us whether the object exists or not (technically we could
swap this out for has_sha1_file, but the cost is roughly the
same).
In case 2, the existence check is of debatable value. A
mass-resolution might prefer performance to safety (against
outputting a value for a corrupted ref, for example).
However, the object lookup cost is likely not as noticeable
compared to the resolution cost. And since we have provided
that safety in the past, the conservative choice is to keep
it.
In case 1, though, the object lookup is a definite noop; we
know about the object because we found it in the object
database. There is no new information gained by making the
call.
This patch detects that case and optimizes out the call.
Here are best-of-five timings for linux.git:
[before]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m2.117s
user 0m2.044s
sys 0m0.072s
[after]
$ time git cat-file --buffer \
--batch-all-objects \
--batch-check='%(objectname)'
real 0m1.230s
user 0m1.176s
sys 0m0.052s
There are two implementation details to note here.
One is that we detect the noop case by seeing that "struct
object_info" does not request any information. But besides
object existence, there is one other piece of information
which sha1_object_info may fill in: whether the object is
cached, loose, or packed. We don't currently provide that
information in the output, but if we were to do so later,
we'd need to take note and disable the optimization in that
case.
And that leads to the second note. If we were to output
that information, a better implementation would be to
remember where we saw the object in --batch-all-objects in
the first place, and avoid looking it up again by sha1.
In fact, we could probably squeeze out some extra
performance for less-trivial cases, too, by remembering the
pack location where we saw the object, and going directly
there to find its information (like type, size, etc). That
would in theory make this optimization unnecessary.
I didn't pursue that path here for two reasons:
1. It's non-trivial to implement, and has memory
implications. Because we sort and de-dup the list of
output sha1s, we'd have to record the pack information
for each object, too.
2. It doesn't save as much as you might hope. It saves the
find_pack_entry() call, but getting the size and type
for deltified objects requires walking down the delta
chain (for the real type) or reading the delta data
header (for the size). These costs tend to dominate the
non-trivial cases.
By contrast, this optimization is easy and self-contained,
and speeds up a real-world case I've used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:55:23 +03:00
|
|
|
if (!memcmp(&data.info, &empty, sizeof(empty)))
|
|
|
|
data.skip_object_info = 1;
|
|
|
|
}
|
|
|
|
|
cat-file: handle --batch format with missing type/size
Commit 98e2092 taught cat-file to stream blobs with --batch,
which requires that we look up the object type before
loading it into memory. As a result, we now print the
object header from information in sha1_object_info, and the
actual contents from the read_sha1_file. We double-check
that the information we printed in the header matches the
content we are about to show.
Later, commit 93d2a60 allowed custom header lines for
--batch, and commit 5b08640 made type lookups optional. As a
result, specifying a header line without the type or size
means that we will not look up those items at all.
This causes our double-checking to erroneously die with an
error; we think the type or size has changed, when in fact
it was simply left at "0".
For the size, we can fix this by only doing the consistency
double-check when we have retrieved the size via
sha1_object_info. In the case that we have not retrieved the
value, that means we also did not print it, so there is
nothing for us to check that we are consistent with.
We could do the same for the type. However, besides our
consistency check, we also care about the type in deciding
whether to stream or not. So instead of handling the case
where we do not know the type, this patch instead makes sure
that we always trigger a type lookup when we are printing,
so that even a format without the type will stream as we
would in the normal case.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12 03:15:50 +04:00
|
|
|
/*
|
|
|
|
* If we are printing out the object, then always fill in the type,
|
|
|
|
* since we will want to decide whether or not to stream.
|
|
|
|
*/
|
|
|
|
if (opt->print_contents)
|
|
|
|
data.info.typep = &data.type;
|
|
|
|
|
2015-06-22 13:45:59 +03:00
|
|
|
if (opt->all_objects) {
|
|
|
|
struct object_cb_data cb;
|
2015-06-22 14:06:32 +03:00
|
|
|
|
2019-06-25 16:40:31 +03:00
|
|
|
if (has_promisor_remote())
|
|
|
|
warning("This repository uses promisor remotes. Some objects may not be loaded.");
|
2015-06-22 14:06:32 +03:00
|
|
|
|
2015-06-22 13:45:59 +03:00
|
|
|
cb.opt = opt;
|
|
|
|
cb.expand = &data;
|
2018-08-14 21:20:22 +03:00
|
|
|
cb.scratch = &output;
|
2015-06-22 14:06:32 +03:00
|
|
|
|
cat-file: support "unordered" output for --batch-all-objects
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related deltas next to each other. By contrast, hash order
is effectively random, since the sha1 has no discernible
relationship to the content.
This patch introduces an "--unordered" option to cat-file
which iterates over packs in pack-order under the hood. You
can see the results when dumping all of the file content:
$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
6883195596
real 0m44.491s
user 0m42.902s
sys 0m5.230s
$ time ./git cat-file --unordered \
--batch-all-objects --buffer --batch | wc -c
6883195596
real 0m6.075s
user 0m4.774s
sys 0m3.548s
Same output, different order, way faster. The same speed-up
applies even if you end up accessing the object content in a
different process, like:
git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c
Adding "--unordered" to the first command drops the runtime
in git.git from 24s to 3.5s.
Side note: there are actually further speedups available
for doing it all in-process now. Since we are outputting
the object content during the actual pack iteration, we
know where to find the object and could skip the extra
lookup done by oid_object_info(). This patch stops short
of that optimization since the underlying API isn't ready
for us to make those sorts of direct requests.
So if --unordered is so much better, why not make it the
default? Two reasons:
1. We've promised in the documentation that --batch-all-objects
outputs in hash order. Since cat-file is plumbing,
people may be relying on that default, and we can't
change it.
2. It's actually _slower_ for some cases. We have to
compute the pack revindex to walk in pack order. And
our de-duplication step uses an oidset, rather than a
sort-and-dedup, which can end up being more expensive.
If we're just accessing the type and size of each
object, for example, like:
git cat-file --batch-all-objects --buffer --batch-check
my best-of-five warm cache timings go from 900ms to
1100ms using --unordered. Though it's possible in a
cold-cache or under memory pressure that we could do
better, since we'd have better locality within the
packfile.
And one final question: why is it "--unordered" and not
"--pack-order"? The answer is again two-fold:
1. "pack order" isn't a well-defined thing across the
whole set of objects. We're hitting loose objects, as
well as objects in multiple packs, and the only
ordering we're promising is _within_ a single pack. The
rest is apparently random.
2. The point here is optimization. So we don't want to
promise any particular ordering, but only to say that
we will choose an ordering which is likely to be
efficient for accessing the object content. That leaves
the door open for further changes in the future without
having to add another compatibility option.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-11 02:24:57 +03:00
|
|
|
if (opt->unordered) {
|
|
|
|
struct oidset seen = OIDSET_INIT;
|
|
|
|
|
|
|
|
cb.seen = &seen;
|
|
|
|
|
|
|
|
for_each_loose_object(batch_unordered_loose, &cb, 0);
|
|
|
|
for_each_packed_object(batch_unordered_packed, &cb,
|
|
|
|
FOR_EACH_OBJECT_PACK_ORDER);
|
|
|
|
|
|
|
|
oidset_clear(&seen);
|
|
|
|
} else {
|
|
|
|
struct oid_array sa = OID_ARRAY_INIT;
|
|
|
|
|
|
|
|
for_each_loose_object(collect_loose_object, &sa, 0);
|
|
|
|
for_each_packed_object(collect_packed_object, &sa, 0);
|
|
|
|
|
|
|
|
oid_array_for_each_unique(&sa, batch_object_cb, &cb);
|
|
|
|
|
|
|
|
oid_array_clear(&sa);
|
|
|
|
}
|
|
|
|
|
2018-08-14 21:20:22 +03:00
|
|
|
strbuf_release(&output);
|
2015-06-22 13:45:59 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
cat-file: disable object/refname ambiguity check for batch mode
A common use of "cat-file --batch-check" is to feed a list
of objects from "rev-list --objects" or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately, get_sha1() recognizes a 40-byte sha1 before
doing any hard work trying to look up refs, meaning this
scenario should end up spending very little time converting
the input into an object sha1. However, since 798c35f
(get_sha1: warn about full or short object names that look
like refs, 2013-05-29), when we encounter this case, we
spend the extra effort to do a refname lookup anyway, just
to print a warning. This is further exacerbated by ca91993
(get_packed_ref_cache: reload packed-refs file when it
changes, 2013-06-20), which makes individual ref lookup more
expensive by requiring a stat() of the packed-refs file for
each missing ref.
With no patches, this is the time it takes to run:
$ git rev-list --objects --all >objects
$ time git cat-file --batch-check='%(objectname)' <objects
on the linux.git repository:
real 1m13.494s
user 0m25.924s
sys 0m47.532s
If we revert ca91993, the packed-refs up-to-date check, it
gets a little better:
real 0m54.697s
user 0m21.692s
sys 0m32.916s
but we are still spending quite a bit of time on ref lookup
(and we would not want to revert that patch, anyway, which
has correctness issues). If we revert 798c35f, disabling
the warning entirely, we get a much more reasonable time:
real 0m7.452s
user 0m6.836s
sys 0m0.608s
This patch does the moral equivalent of this final case (and
gets similar speedups). We introduce a global flag that
callers of get_sha1() can use to avoid paying the price for
the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12 10:20:05 +04:00
|
|
|
/*
|
|
|
|
* We are going to call get_sha1 on a potentially very large number of
|
|
|
|
* objects. In most large cases, these will be actual object sha1s. The
|
|
|
|
* cost to double-check that each one is not also a ref (just so we can
|
|
|
|
* warn) ends up dwarfing the actual cost of the object lookups
|
|
|
|
* themselves. We can work around it by just turning off the warning.
|
|
|
|
*/
|
2014-03-13 00:05:43 +04:00
|
|
|
save_warning = warn_on_object_refname_ambiguity;
|
cat-file: disable object/refname ambiguity check for batch mode
A common use of "cat-file --batch-check" is to feed a list
of objects from "rev-list --objects" or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately, get_sha1() recognizes a 40-byte sha1 before
doing any hard work trying to look up refs, meaning this
scenario should end up spending very little time converting
the input into an object sha1. However, since 798c35f
(get_sha1: warn about full or short object names that look
like refs, 2013-05-29), when we encounter this case, we
spend the extra effort to do a refname lookup anyway, just
to print a warning. This is further exacerbated by ca91993
(get_packed_ref_cache: reload packed-refs file when it
changes, 2013-06-20), which makes individual ref lookup more
expensive by requiring a stat() of the packed-refs file for
each missing ref.
With no patches, this is the time it takes to run:
$ git rev-list --objects --all >objects
$ time git cat-file --batch-check='%(objectname)' <objects
on the linux.git repository:
real 1m13.494s
user 0m25.924s
sys 0m47.532s
If we revert ca91993, the packed-refs up-to-date check, it
gets a little better:
real 0m54.697s
user 0m21.692s
sys 0m32.916s
but we are still spending quite a bit of time on ref lookup
(and we would not want to revert that patch, anyway, which
has correctness issues). If we revert 798c35f, disabling
the warning entirely, we get a much more reasonable time:
real 0m7.452s
user 0m6.836s
sys 0m0.608s
This patch does the moral equivalent of this final case (and
gets similar speedups). We introduce a global flag that
callers of get_sha1() can use to avoid paying the price for
the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12 10:20:05 +04:00
|
|
|
warn_on_object_refname_ambiguity = 0;
|
|
|
|
|
2018-08-14 21:18:06 +03:00
|
|
|
while (strbuf_getline(&input, stdin) != EOF) {
|
cat-file: only split on whitespace when %(rest) is used
Commit c334b87b (cat-file: split --batch input lines on whitespace,
2013-07-11) taught `cat-file --batch-check` to split input lines on
the first whitespace, and stash everything after the first token
into the %(rest) output format element. It claimed:
Object names cannot contain spaces, so any input with
spaces would have resulted in a "missing" line.
But that is not correct. Refs, object sha1s, and various peeling
suffixes cannot contain spaces, but some object names can. In
particular:
1. Tree paths like "[<tree>]:path with whitespace"
2. Reflog specifications like "@{2 days ago}"
3. Commit searches like "rev^{/grep me}" or ":/grep me"
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit reverted.
Resurrect its attempt but in a weaker form; only do the splitting
when "%(rest)" is used in the output format. Since that element did
not exist at all before c334b87, old scripts cannot be affected.
The existence of object names with spaces does mean that you
cannot reliably do:
echo ":path with space and other data" |
git cat-file --batch-check="%(objectname) %(rest)"
as it would split the path and feed only ":path" to get_sha1. But
that command is nonsensical. If you wanted to see "and other data"
in "%(rest)", git cannot possibly know where the filename ends and
the "rest" begins.
It might be more robust to have something like "-z" to separate the
input elements. But this patch is still a reasonable step before
having that. It makes the easy cases easy; people who do not care
about %(rest) do not have to consider it, and the %(rest) code
handles the spaces and newlines of "rev-list --objects" correctly.
Hard cases remain hard but possible (if you might get whitespace in
your input, you do not get to use %(rest) and must split and join
the output yourself using more flexible tools). And most
importantly, it does not preclude us from having different splitting
rules later if a "-z" (or similar) option is added. So we can make
the hard cases easier later, if we choose to.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02 15:59:07 +04:00
|
|
|
if (data.split_on_whitespace) {
|
|
|
|
/*
|
|
|
|
* Split at first whitespace, tying off the beginning
|
|
|
|
* of the string and saving the remainder (or NULL) in
|
|
|
|
* data.rest.
|
|
|
|
*/
|
2018-08-14 21:18:06 +03:00
|
|
|
char *p = strpbrk(input.buf, " \t");
|
cat-file: only split on whitespace when %(rest) is used
Commit c334b87b (cat-file: split --batch input lines on whitespace,
2013-07-11) taught `cat-file --batch-check` to split input lines on
the first whitespace, and stash everything after the first token
into the %(rest) output format element. It claimed:
Object names cannot contain spaces, so any input with
spaces would have resulted in a "missing" line.
But that is not correct. Refs, object sha1s, and various peeling
suffixes cannot contain spaces, but some object names can. In
particular:
1. Tree paths like "[<tree>]:path with whitespace"
2. Reflog specifications like "@{2 days ago}"
3. Commit searches like "rev^{/grep me}" or ":/grep me"
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit reverted.
Resurrect its attempt but in a weaker form; only do the splitting
when "%(rest)" is used in the output format. Since that element did
not exist at all before c334b87, old scripts cannot be affected.
The existence of object names with spaces does mean that you
cannot reliably do:
echo ":path with space and other data" |
git cat-file --batch-check="%(objectname) %(rest)"
as it would split the path and feed only ":path" to get_sha1. But
that command is nonsensical. If you wanted to see "and other data"
in "%(rest)", git cannot possibly know where the filename ends and
the "rest" begins.
It might be more robust to have something like "-z" to separate the
input elements. But this patch is still a reasonable step before
having that. It makes the easy cases easy; people who do not care
about %(rest) do not have to consider it, and the %(rest) code
handles the spaces and newlines of "rev-list --objects" correctly.
Hard cases remain hard but possible (if you might get whitespace in
your input, you do not get to use %(rest) and must split and join
the output yourself using more flexible tools). And most
importantly, it does not preclude us from having different splitting
rules later if a "-z" (or similar) option is added. So we can make
the hard cases easier later, if we choose to.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-02 15:59:07 +04:00
|
|
|
if (p) {
|
|
|
|
while (*p && strchr(" \t", *p))
|
|
|
|
*p++ = '\0';
|
|
|
|
}
|
|
|
|
data.rest = p;
|
|
|
|
}
|
|
|
|
|
2018-08-14 21:20:22 +03:00
|
|
|
batch_one_object(input.buf, &output, opt, &data);
|
2008-04-23 23:17:46 +04:00
|
|
|
}
|
|
|
|
|
2018-08-14 21:18:06 +03:00
|
|
|
strbuf_release(&input);
|
2018-08-14 21:20:22 +03:00
|
|
|
strbuf_release(&output);
|
2014-03-13 00:05:43 +04:00
|
|
|
warn_on_object_refname_ambiguity = save_warning;
|
2014-01-08 02:10:15 +04:00
|
|
|
return retval;
|
2008-04-23 23:17:46 +04:00
|
|
|
}
|
|
|
|
|
2008-05-23 18:19:42 +04:00
|
|
|
static const char * const cat_file_usage[] = {
|
2016-09-22 01:15:18 +03:00
|
|
|
N_("git cat-file (-t [--allow-unknown-type] | -s [--allow-unknown-type] | -e | -p | <type> | --textconv | --filters) [--path=<path>] <object>"),
|
|
|
|
N_("git cat-file (--batch | --batch-check) [--follow-symlinks] [--textconv | --filters]"),
|
2008-05-23 18:19:42 +04:00
|
|
|
NULL
|
|
|
|
};
|
2008-04-23 23:17:45 +04:00
|
|
|
|
2010-06-15 19:50:28 +04:00
|
|
|
static int git_cat_file_config(const char *var, const char *value, void *cb)
|
|
|
|
{
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
if (userdiff_config(var, value) < 0)
|
2010-06-15 19:50:28 +04:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
return git_default_config(var, value, cb);
|
|
|
|
}
|
|
|
|
|
2013-07-10 15:38:58 +04:00
|
|
|
static int batch_option_callback(const struct option *opt,
|
|
|
|
const char *arg,
|
|
|
|
int unset)
|
|
|
|
{
|
|
|
|
struct batch_options *bo = opt->value;
|
|
|
|
|
assert NOARG/NONEG behavior of parse-options callbacks
When we define a parse-options callback, the flags we put in the option
struct must match what the callback expects. For example, a callback
which does not handle the "unset" parameter should only be used with
PARSE_OPT_NONEG. But since the callback and the option struct are not
defined next to each other, it's easy to get this wrong (as earlier
patches in this series show).
Fortunately, the compiler can help us here: compiling with
-Wunused-parameters can show us which callbacks ignore their "unset"
parameters (and likewise, ones that ignore "arg" expect to be triggered
with PARSE_OPT_NOARG).
But after we've inspected a callback and determined that all of its
callers use the right flags, what do we do next? We'd like to silence
the compiler warning, but do so in a way that will catch any wrong calls
in the future.
We can do that by actually checking those variables and asserting that
they match our expectations. Because this is such a common pattern,
we'll introduce some helper macros. The resulting messages aren't
as descriptive as we could make them, but the file/line information from
BUG() is enough to identify the problem (and anyway, the point is that
these should never be seen).
Each of the annotated callbacks in this patch triggers
-Wunused-parameters, and was manually inspected to make sure all callers
use the correct options (so none of these BUGs should be triggerable).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 09:45:42 +03:00
|
|
|
BUG_ON_OPT_NEG(unset);
|
|
|
|
|
2015-05-20 20:03:40 +03:00
|
|
|
if (bo->enabled) {
|
2018-11-05 09:43:44 +03:00
|
|
|
return error(_("only one batch option may be specified"));
|
2013-07-10 15:38:58 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
bo->enabled = 1;
|
|
|
|
bo->print_contents = !strcmp(opt->long_name, "batch");
|
2013-07-10 15:45:47 +04:00
|
|
|
bo->format = arg;
|
2013-07-10 15:38:58 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-23 23:17:44 +04:00
|
|
|
int cmd_cat_file(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2013-07-10 15:38:58 +04:00
|
|
|
int opt = 0;
|
2008-04-23 23:17:45 +04:00
|
|
|
const char *exp_type = NULL, *obj_name = NULL;
|
2013-07-10 15:38:58 +04:00
|
|
|
struct batch_options batch = {0};
|
2015-05-03 17:30:01 +03:00
|
|
|
int unknown_type = 0;
|
2008-04-23 23:17:44 +04:00
|
|
|
|
2008-05-23 18:19:42 +04:00
|
|
|
const struct option options[] = {
|
2012-08-20 16:31:56 +04:00
|
|
|
OPT_GROUP(N_("<type> can be one of: blob, tree, commit, tag")),
|
2015-05-03 17:30:00 +03:00
|
|
|
OPT_CMDMODE('t', NULL, &opt, N_("show object type"), 't'),
|
|
|
|
OPT_CMDMODE('s', NULL, &opt, N_("show object size"), 's'),
|
|
|
|
OPT_CMDMODE('e', NULL, &opt,
|
2012-08-20 16:31:56 +04:00
|
|
|
N_("exit with zero when there's no error"), 'e'),
|
2015-05-03 17:30:00 +03:00
|
|
|
OPT_CMDMODE('p', NULL, &opt, N_("pretty-print object's content"), 'p'),
|
|
|
|
OPT_CMDMODE(0, "textconv", &opt,
|
2012-08-20 16:31:56 +04:00
|
|
|
N_("for blob objects, run textconv on object's content"), 'c'),
|
2016-08-24 15:23:39 +03:00
|
|
|
OPT_CMDMODE(0, "filters", &opt,
|
|
|
|
N_("for blob objects, run filters on object's content"), 'w'),
|
2016-09-09 13:10:50 +03:00
|
|
|
OPT_STRING(0, "path", &force_path, N_("blob"),
|
|
|
|
N_("use a specific path for --textconv/--filters")),
|
2015-06-22 13:40:56 +03:00
|
|
|
OPT_BOOL(0, "allow-unknown-type", &unknown_type,
|
2015-05-03 17:30:01 +03:00
|
|
|
N_("allow -s and -t to work with broken/corrupt objects")),
|
2015-06-22 13:45:17 +03:00
|
|
|
OPT_BOOL(0, "buffer", &batch.buffer_output, N_("buffer --batch output")),
|
2013-07-10 15:45:47 +04:00
|
|
|
{ OPTION_CALLBACK, 0, "batch", &batch, "format",
|
2013-07-10 15:38:58 +04:00
|
|
|
N_("show info and content of objects fed from the standard input"),
|
2018-11-05 09:40:10 +03:00
|
|
|
PARSE_OPT_OPTARG | PARSE_OPT_NONEG,
|
|
|
|
batch_option_callback },
|
2013-07-10 15:45:47 +04:00
|
|
|
{ OPTION_CALLBACK, 0, "batch-check", &batch, "format",
|
2013-07-10 15:38:58 +04:00
|
|
|
N_("show info about objects fed from the standard input"),
|
2018-11-05 09:40:10 +03:00
|
|
|
PARSE_OPT_OPTARG | PARSE_OPT_NONEG,
|
|
|
|
batch_option_callback },
|
2015-05-20 20:03:40 +03:00
|
|
|
OPT_BOOL(0, "follow-symlinks", &batch.follow_symlinks,
|
|
|
|
N_("follow in-tree symlinks (used with --batch or --batch-check)")),
|
2015-06-22 13:45:59 +03:00
|
|
|
OPT_BOOL(0, "batch-all-objects", &batch.all_objects,
|
|
|
|
N_("show all objects with --batch or --batch-check")),
|
cat-file: support "unordered" output for --batch-all-objects
If you're going to access the contents of every object in a
packfile, it's generally much more efficient to do so in
pack order, rather than in hash order. That increases the
locality of access within the packfile, which in turn is
friendlier to the delta base cache, since the packfile puts
related deltas next to each other. By contrast, hash order
is effectively random, since the sha1 has no discernible
relationship to the content.
This patch introduces an "--unordered" option to cat-file
which iterates over packs in pack-order under the hood. You
can see the results when dumping all of the file content:
$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
6883195596
real 0m44.491s
user 0m42.902s
sys 0m5.230s
$ time ./git cat-file --unordered \
--batch-all-objects --buffer --batch | wc -c
6883195596
real 0m6.075s
user 0m4.774s
sys 0m3.548s
Same output, different order, way faster. The same speed-up
applies even if you end up accessing the object content in a
different process, like:
git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c
Adding "--unordered" to the first command drops the runtime
in git.git from 24s to 3.5s.
Side note: there are actually further speedups available
for doing it all in-process now. Since we are outputting
the object content during the actual pack iteration, we
know where to find the object and could skip the extra
lookup done by oid_object_info(). This patch stops short
of that optimization since the underlying API isn't ready
for us to make those sorts of direct requests.
So if --unordered is so much better, why not make it the
default? Two reasons:
1. We've promised in the documentation that --batch-all-objects
outputs in hash order. Since cat-file is plumbing,
people may be relying on that default, and we can't
change it.
2. It's actually _slower_ for some cases. We have to
compute the pack revindex to walk in pack order. And
our de-duplication step uses an oidset, rather than a
sort-and-dedup, which can end up being more expensive.
If we're just accessing the type and size of each
object, for example, like:
git cat-file --batch-all-objects --buffer --batch-check
my best-of-five warm cache timings go from 900ms to
1100ms using --unordered. Though it's possible in a
cold-cache or under memory pressure that we could do
better, since we'd have better locality within the
packfile.
And one final question: why is it "--unordered" and not
"--pack-order"? The answer is again two-fold:
1. "pack order" isn't a well-defined thing across the
whole set of objects. We're hitting loose objects, as
well as objects in multiple packs, and the only
ordering we're promising is _within_ a single pack. The
rest is apparently random.
2. The point here is optimization. So we don't want to
promise any particular ordering, but only to say that
we will choose an ordering which is likely to be
efficient for accessing the object content. That leaves
the door open for further changes in the future without
having to add another compatibility option.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-11 02:24:57 +03:00
|
|
|
OPT_BOOL(0, "unordered", &batch.unordered,
|
|
|
|
N_("do not order --batch-all-objects output")),
|
2008-05-23 18:19:42 +04:00
|
|
|
OPT_END()
|
|
|
|
};
|
2008-04-23 23:17:47 +04:00
|
|
|
|
2010-06-15 19:50:28 +04:00
|
|
|
git_config(git_cat_file_config, NULL);
|
2008-04-23 23:17:45 +04:00
|
|
|
|
cat-file: default to --buffer when --batch-all-objects is used
Traditionally cat-file's batch-mode does not do any output
buffering. The reason is that a caller may have pipes
connected to its input and output, and would want to use
cat-file interactively, getting output immediately for each
input it sends.
This may involve a lot of small write() calls, which can be
slow. So we introduced --buffer to improve this, but we
can't turn it on by default, as it would break the
interactive case above.
However, when --batch-all-objects is used, we do not read
stdin at all. We generate the output ourselves as quickly as
possible, and then exit. In this case buffering is a strict
win, and it is simply a hassle for the user to have to
remember to specify --buffer.
This patch makes --buffer the default when --batch-all-objects
is used. Specifying "--buffer" manually is still OK, and you
can even override it with "--no-buffer" if you're a
masochist (or debugging).
For some real numbers, running:
git cat-file --batch-all-objects --batch-check='%(objectname)'
on torvalds/linux goes from:
real 0m1.464s
user 0m1.208s
sys 0m0.252s
to:
real 0m1.230s
user 0m1.172s
sys 0m0.056s
for a 16% speedup.
Suggested-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:56:14 +03:00
|
|
|
batch.buffer_output = -1;
|
2009-05-23 22:53:12 +04:00
|
|
|
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
|
2008-04-23 23:17:46 +04:00
|
|
|
|
2008-05-23 18:19:42 +04:00
|
|
|
if (opt) {
|
2016-09-09 13:10:54 +03:00
|
|
|
if (batch.enabled && (opt == 'c' || opt == 'w'))
|
|
|
|
batch.cmdmode = opt;
|
|
|
|
else if (argc == 1)
|
2008-05-23 18:19:42 +04:00
|
|
|
obj_name = argv[0];
|
|
|
|
else
|
|
|
|
usage_with_options(cat_file_usage, options);
|
|
|
|
}
|
2013-07-10 15:38:58 +04:00
|
|
|
if (!opt && !batch.enabled) {
|
2008-05-23 18:19:42 +04:00
|
|
|
if (argc == 2) {
|
|
|
|
exp_type = argv[0];
|
|
|
|
obj_name = argv[1];
|
|
|
|
} else
|
|
|
|
usage_with_options(cat_file_usage, options);
|
|
|
|
}
|
2016-09-09 13:10:54 +03:00
|
|
|
if (batch.enabled) {
|
|
|
|
if (batch.cmdmode != opt || argc)
|
|
|
|
usage_with_options(cat_file_usage, options);
|
|
|
|
if (batch.cmdmode && batch.all_objects)
|
|
|
|
die("--batch-all-objects cannot be combined with "
|
|
|
|
"--textconv nor with --filters");
|
2008-04-23 23:17:44 +04:00
|
|
|
}
|
|
|
|
|
2015-06-22 13:45:59 +03:00
|
|
|
if ((batch.follow_symlinks || batch.all_objects) && !batch.enabled) {
|
2015-05-20 20:03:40 +03:00
|
|
|
usage_with_options(cat_file_usage, options);
|
|
|
|
}
|
|
|
|
|
2016-09-09 13:10:50 +03:00
|
|
|
if (force_path && opt != 'c' && opt != 'w') {
|
|
|
|
error("--path=<path> needs --textconv or --filters");
|
|
|
|
usage_with_options(cat_file_usage, options);
|
|
|
|
}
|
|
|
|
|
2016-09-09 13:10:54 +03:00
|
|
|
if (force_path && batch.enabled) {
|
|
|
|
error("--path=<path> incompatible with --batch");
|
|
|
|
usage_with_options(cat_file_usage, options);
|
|
|
|
}
|
|
|
|
|
cat-file: default to --buffer when --batch-all-objects is used
Traditionally cat-file's batch-mode does not do any output
buffering. The reason is that a caller may have pipes
connected to its input and output, and would want to use
cat-file interactively, getting output immediately for each
input it sends.
This may involve a lot of small write() calls, which can be
slow. So we introduced --buffer to improve this, but we
can't turn it on by default, as it would break the
interactive case above.
However, when --batch-all-objects is used, we do not read
stdin at all. We generate the output ourselves as quickly as
possible, and then exit. In this case buffering is a strict
win, and it is simply a hassle for the user to have to
remember to specify --buffer.
This patch makes --buffer the default when --batch-all-objects
is used. Specifying "--buffer" manually is still OK, and you
can even override it with "--no-buffer" if you're a
masochist (or debugging).
For some real numbers, running:
git cat-file --batch-all-objects --batch-check='%(objectname)'
on torvalds/linux goes from:
real 0m1.464s
user 0m1.208s
sys 0m0.252s
to:
real 0m1.230s
user 0m1.172s
sys 0m0.056s
for a 16% speedup.
Suggested-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 19:56:14 +03:00
|
|
|
if (batch.buffer_output < 0)
|
|
|
|
batch.buffer_output = batch.all_objects;
|
|
|
|
|
2013-07-10 15:38:58 +04:00
|
|
|
if (batch.enabled)
|
|
|
|
return batch_objects(&batch);
|
2008-04-23 23:17:46 +04:00
|
|
|
|
2015-05-03 17:30:01 +03:00
|
|
|
if (unknown_type && opt != 't' && opt != 's')
|
|
|
|
die("git cat-file --allow-unknown-type: use with -s or -t");
|
|
|
|
return cat_one_file(opt, exp_type, obj_name, unknown_type);
|
2008-04-23 23:17:44 +04:00
|
|
|
}
|