{"thread":{"id":"47582","subject":"[PATCH v2 14/18] ref-filter: get rid of expand_atom_into_fields","startedAt":"2018-01-10T09:36:54Z","lastAt":"2018-01-19T20:13:02Z","messageCount":47,"participants":["Olga Telezhnaya","Jeff King","Оля Тележная","Christian Couder","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":18},"messages":[{"id":"336351","messageId":"01020160df6dc59c-62462c0b-9d87-4fba-bfe7-2399dfb4eebb-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 14/18] ref-filter: get rid of expand_atom_into_fields","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:36:54Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Remove expand_atom_into_fields function and create same logic\nin terms of ref-filter style.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n ref-filter.c | 45 +++++++++++++++++++++------------------------\n 1 file changed, 21 insertions(+), 24 deletions(-)\n\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 35e16cec6d862..93248ce18152f 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -255,13 +255,29 @@ static void objectname_atom_parser(const struct ref_format *format, struct used_\n static void objectsize_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n {\n \tif (!arg)\n-\t\t; /* default to normal object size */\n+\t\tcat_file_info->info.sizep = &cat_file_info->size;\n \telse if (!strcmp(arg, \"disk\"))\n \t\tcat_file_info->info.disk_sizep = &cat_file_info->disk_size;\n \telse\n \t\tdie(_(\"urecognized %%(objectsize) argument: %s\"), arg);\n }\n \n+static void objecttype_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n+{\n+\tif (!arg)\n+\t\tcat_file_info->info.typep = &cat_file_info->type;\n+\telse\n+\t\tdie(_(\"urecognized %%(objecttype) argument: %s\"), arg);\n+}\n+\n+static void deltabase_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n+{\n+\tif (!arg)\n+\t\tcat_file_info->info.delta_base_sha1 = cat_file_info->delta_base_oid.hash;\n+\telse\n+\t\tdie(_(\"urecognized %%(deltabase) argument: %s\"), arg);\n+}\n+\n static void refname_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n {\n \trefname_atom_parser_internal(&atom->u.refname, arg, atom->name);\n@@ -384,10 +400,10 @@ static struct valid_atom {\n \n static struct valid_atom valid_cat_file_atom[] = {\n \t{ \"objectname\" },\n-\t{ \"objecttype\" },\n+\t{ \"objecttype\", FIELD_STR, objecttype_atom_parser },\n \t{ \"objectsize\", FIELD_ULONG, objectsize_atom_parser },\n \t{ \"rest\" },\n-\t{ \"deltabase\" },\n+\t{ \"deltabase\", FIELD_STR, deltabase_atom_parser },\n };\n \n #define REF_FORMATTING_STATE_INIT { 0, NULL }\n@@ -411,25 +427,6 @@ struct atom_value {\n \tstruct used_atom *atom;\n };\n \n-static int is_atom(const char *atom, const char *s, int slen)\n-{\n-\tint alen = strlen(atom);\n-\treturn alen == slen && !memcmp(atom, s, alen);\n-}\n-\n-static void expand_atom_into_fields(const char *atom, int len,\n-\t\t\t\t struct expand_data *data)\n-{\n-\tif (is_atom(\"objecttype\", atom, len))\n-\t\tdata->info.typep = &data->type;\n-\telse if (is_atom(\"objectsize\", atom, len))\n-\t\tdata->info.sizep = &data->size;\n-\telse if (is_atom(\"rest\", atom, len))\n-\t\tdata->split_on_whitespace = 1;\n-\telse if (is_atom(\"deltabase\", atom, len))\n-\t\tdata->info.delta_base_sha1 = data->delta_base_oid.hash;\n-}\n-\n /*\n * Used to parse format string and sort specifiers\n */\n@@ -496,8 +493,8 @@ static int parse_ref_filter_atom(const struct ref_format *format,\n \t\tneed_tagged = 1;\n \tif (!strcmp(valid_atom[i].name, \"symref\"))\n \t\tneed_symref = 1;\n-\tif (cat_file_info)\n-\t\texpand_atom_into_fields(atom, atom_len, cat_file_info);\n+\tif (cat_file_info && !strcmp(valid_atoms[i].name, \"rest\"))\n+\t\tcat_file_info->split_on_whitespace = 1;\n \treturn at;\n }\n \n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336352","messageId":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160db0679c9-799a0bc4-b6d1-43e2-ad3b-80be4e4c55e9-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:36:57Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Split expand_atom function into 2 different functions,\nexpand_atom_into_fields prepares variable for further filling,\n(new) expand_atom creates resulting string.\nNeed that for further reusing of formatting logic from ref-filter.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 73 +++++++++++++++++++++++++++++-------------------------\n 1 file changed, 39 insertions(+), 34 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex f5fa4fd75af26..f783b39b9bd5c 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -217,47 +217,49 @@ static int is_atom(const char *atom, const char *s, int slen)\n \treturn alen == slen && !memcmp(atom, s, alen);\n }\n \n-static void expand_atom(struct strbuf *sb, const char *atom, int len,\n-\t\t\tvoid *vdata)\n+static void expand_atom_into_fields(struct strbuf *sb, const char *atom, int len,\n+\t\t\tstruct expand_data *data)\n {\n-\tstruct expand_data *data = vdata;\n+\tif (is_atom(\"objectname\", atom, len))\n+\t\t; /* do nothing */\n+\telse if (is_atom(\"objecttype\", atom, len))\n+\t\tdata->info.typep = &data->type;\n+\telse if (is_atom(\"objectsize\", atom, len))\n+\t\tdata->info.sizep = &data->size;\n+\telse if (is_atom(\"objectsize:disk\", atom, len))\n+\t\tdata->info.disk_sizep = &data->disk_size;\n+\telse if (is_atom(\"rest\", atom, len))\n+\t\tdata->split_on_whitespace = 1;\n+\telse if (is_atom(\"deltabase\", atom, len))\n+\t\tdata->info.delta_base_sha1 = data->delta_base_oid.hash;\n+\telse\n+\t\tdie(\"unknown format element: %.*s\", len, atom);\n+}\n \n-\tif (is_atom(\"objectname\", atom, len)) {\n-\t\tif (!data->mark_query)\n-\t\t\tstrbuf_addstr(sb, oid_to_hex(&data->oid));\n-\t} else if (is_atom(\"objecttype\", atom, len)) {\n-\t\tif (data->mark_query)\n-\t\t\tdata->info.typep = &data->type;\n-\t\telse\n-\t\t\tstrbuf_addstr(sb, typename(data->type));\n-\t} else if (is_atom(\"objectsize\", atom, len)) {\n-\t\tif (data->mark_query)\n-\t\t\tdata->info.sizep = &data->size;\n-\t\telse\n-\t\t\tstrbuf_addf(sb, \"%lu\", data->size);\n-\t} else if (is_atom(\"objectsize:disk\", atom, len)) {\n-\t\tif (data->mark_query)\n-\t\t\tdata->info.disk_sizep = &data->disk_size;\n-\t\telse\n-\t\t\tstrbuf_addf(sb, \"%\"PRIuMAX, (uintmax_t)data->disk_size);\n-\t} else if (is_atom(\"rest\", atom, len)) {\n-\t\tif (data->mark_query)\n-\t\t\tdata->split_on_whitespace = 1;\n-\t\telse if (data->rest)\n+static void expand_atom(struct strbuf *sb, const char *atom, int len,\n+\t\t\t struct expand_data *data)\n+{\n+\tif (is_atom(\"objectname\", atom, len))\n+\t\tstrbuf_addstr(sb, oid_to_hex(&data->oid));\n+\telse if (is_atom(\"objecttype\", atom, len))\n+\t\tstrbuf_addstr(sb, typename(data->type));\n+\telse if (is_atom(\"objectsize\", atom, len))\n+\t\tstrbuf_addf(sb, \"%lu\", data->size);\n+\telse if (is_atom(\"objectsize:disk\", atom, len))\n+\t\tstrbuf_addf(sb, \"%\"PRIuMAX, (uintmax_t)data->disk_size);\n+\telse if (is_atom(\"rest\", atom, len)) {\n+\t\tif (data->rest)\n \t\t\tstrbuf_addstr(sb, data->rest);\n-\t} else if (is_atom(\"deltabase\", atom, len)) {\n-\t\tif (data->mark_query)\n-\t\t\tdata->info.delta_base_sha1 = data->delta_base_oid.hash;\n-\t\telse\n-\t\t\tstrbuf_addstr(sb,\n-\t\t\t\t oid_to_hex(&data->delta_base_oid));\n-\t} else\n+\t} else if (is_atom(\"deltabase\", atom, len))\n+\t\tstrbuf_addstr(sb, oid_to_hex(&data->delta_base_oid));\n+\telse\n \t\tdie(\"unknown format element: %.*s\", len, atom);\n }\n \n-static size_t expand_format(struct strbuf *sb, const char *start, void *data)\n+static size_t expand_format(struct strbuf *sb, const char *start, void *vdata)\n {\n \tconst char *end;\n+\tstruct expand_data *data = vdata;\n \n \tif (*start != '(')\n \t\treturn 0;\n@@ -265,7 +267,10 @@ static size_t expand_format(struct strbuf *sb, const char *start, void *data)\n \tif (!end)\n \t\tdie(\"format element '%s' does not end in ')'\", start);\n \n-\texpand_atom(sb, start + 1, end - start - 1, data);\n+\tif (data->mark_query)\n+\t\texpand_atom_into_fields(sb, start + 1, end - start - 1, data);\n+\telse\n+\t\texpand_atom(sb, start + 1, end - start - 1, data);\n \n \treturn end - start + 1;\n }\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336353","messageId":"01020160df6dc59f-522bf760-0897-4557-91dc-a5abb47d6215-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 15/18] ref-filter: add is_cat flag","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:01Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Add is_cat flag, further it helps to get rid of cat_file_data field\nin ref_format.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 1 +\n ref-filter.c | 8 +++++---\n ref-filter.h | 1 +\n 3 files changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex e11dbf88e386c..289912ab1f858 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -393,6 +393,7 @@ static int batch_objects(struct batch_options *opt)\n \t */\n \tmemset(&data, 0, sizeof(data));\n \topt->format->cat_file_data = &data;\n+\topt->format->is_cat = 1;\n \tverify_ref_format(opt->format);\n \tif (opt->cmdmode)\n \t\tdata.split_on_whitespace = 1;\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 93248ce18152f..2c955e90bb4c9 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -101,6 +101,7 @@ static struct used_atom {\n } *used_atom;\n static int used_atom_cnt, need_tagged, need_symref;\n struct expand_data *cat_file_info;\n+static int is_cat = 0;\n \n static void color_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *color_value)\n {\n@@ -493,7 +494,7 @@ static int parse_ref_filter_atom(const struct ref_format *format,\n \t\tneed_tagged = 1;\n \tif (!strcmp(valid_atom[i].name, \"symref\"))\n \t\tneed_symref = 1;\n-\tif (cat_file_info && !strcmp(valid_atoms[i].name, \"rest\"))\n+\tif (is_cat && !strcmp(valid_atoms[i].name, \"rest\"))\n \t\tcat_file_info->split_on_whitespace = 1;\n \treturn at;\n }\n@@ -739,6 +740,7 @@ int verify_ref_format(struct ref_format *format)\n \tconst char *cp, *sp;\n \n \tcat_file_info = format->cat_file_data;\n+\tis_cat = format->is_cat;\n \tformat->need_color_reset_at_eol = 0;\n \tfor (cp = format->format; *cp && (sp = find_next(cp)); ) {\n \t\tconst char *color, *ep = strchr(sp, ')');\n@@ -748,7 +750,7 @@ int verify_ref_format(struct ref_format *format)\n \t\t\treturn error(_(\"malformed format string %s\"), sp);\n \t\t/* sp points at \"%(\" and ep points at the closing \")\" */\n \n-\t\tif (format->cat_file_data) {\n+\t\tif (is_cat) {\n \t\t\tat = parse_ref_filter_atom(format, valid_cat_file_atom,\n \t\t\t\t\t\t ARRAY_SIZE(valid_cat_file_atom), sp + 2, ep);\n \t\t} else {\n@@ -1464,7 +1466,7 @@ int populate_value(struct ref_array_item *ref)\n \t\t\tref->symref = \"\";\n \t}\n \n-\tif (cat_file_info) {\n+\tif (is_cat) {\n \t\tif (!cat_file_info->skip_object_info &&\n \t\t sha1_object_info_extended(ref->objectname.hash, &cat_file_info->info,\n \t\t\t\t\t OBJECT_INFO_LOOKUP_REPLACE) < 0) {\ndiff --git a/ref-filter.h b/ref-filter.h\nindex 0c7253913735b..12a938b0aa6a3 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -126,6 +126,7 @@ struct ref_format {\n \t * hopefully would be reduced later.\n \t */\n \tstruct expand_data *cat_file_data;\n+\tint is_cat;\n };\n \n #define REF_FORMAT_INIT { NULL, 0, -1 }\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336354","messageId":"01020160df6dc5ba-269b8786-0038-41be-95b2-dee29fcde83f-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 16/18] ref_format: add split_on_whitespace flag","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:04Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Add flag to ref_format struct so that we could pass needed info\nto cat-file.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 1 +\n ref-filter.c | 4 ++--\n ref-filter.h | 1 +\n 3 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 289912ab1f858..5aac10b9808ff 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -394,6 +394,7 @@ static int batch_objects(struct batch_options *opt)\n \tmemset(&data, 0, sizeof(data));\n \topt->format->cat_file_data = &data;\n \topt->format->is_cat = 1;\n+\topt->format->split_on_whitespace = &data.split_on_whitespace;\n \tverify_ref_format(opt->format);\n \tif (opt->cmdmode)\n \t\tdata.split_on_whitespace = 1;\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 2c955e90bb4c9..0fb33198fb450 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -494,8 +494,8 @@ static int parse_ref_filter_atom(const struct ref_format *format,\n \t\tneed_tagged = 1;\n \tif (!strcmp(valid_atom[i].name, \"symref\"))\n \t\tneed_symref = 1;\n-\tif (is_cat && !strcmp(valid_atoms[i].name, \"rest\"))\n-\t\tcat_file_info->split_on_whitespace = 1;\n+\tif (!strcmp(valid_atom[i].name, \"rest\"))\n+\t\t*format->split_on_whitespace = 1;\n \treturn at;\n }\n \ndiff --git a/ref-filter.h b/ref-filter.h\nindex 12a938b0aa6a3..aaf1790e43e62 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -127,6 +127,7 @@ struct ref_format {\n \t */\n \tstruct expand_data *cat_file_data;\n \tint is_cat;\n+\tint *split_on_whitespace;\n };\n \n #define REF_FORMAT_INIT { NULL, 0, -1 }\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336355","messageId":"01020160df6dc55c-8460a406-3567-42b0-9f03-733e7c64792a-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 08/18] ref-filter: get rid of goto","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:07Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Get rid of goto command in ref-filter for better readability.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n ref-filter.c | 103 ++++++++++++++++++++++++++++++-----------------------------\n 1 file changed, 53 insertions(+), 50 deletions(-)\n\ndiff --git a/ref-filter.c b/ref-filter.c\nindex bb09875e2dbf4..575c5351d0f79 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -1403,16 +1403,60 @@ static const char *get_refname(struct used_atom *atom, struct ref_array_item *re\n \treturn show_ref(&atom->u.refname, ref->refname);\n }\n \n+static void need_object(struct ref_array_item *ref) {\n+\tstruct object *obj;\n+\tconst struct object_id *tagged;\n+\tunsigned long size;\n+\tint eaten;\n+\tvoid *buf = get_obj(&ref->objectname, &obj, &size, &eaten);\n+\tif (!buf)\n+\t\tdie(_(\"missing object %s for %s\"),\n+\t\t oid_to_hex(&ref->objectname), ref->refname);\n+\tif (!obj)\n+\t\tdie(_(\"parse_object_buffer failed on %s for %s\"),\n+\t\t oid_to_hex(&ref->objectname), ref->refname);\n+\n+\tgrab_values(ref->value, 0, obj, buf, size);\n+\tif (!eaten)\n+\t\tfree(buf);\n+\n+\t/*\n+\t * If there is no atom that wants to know about tagged\n+\t * object, we are done.\n+\t */\n+\tif (!need_tagged || (obj->type != OBJ_TAG))\n+\t\treturn;\n+\n+\t/*\n+\t * If it is a tag object, see if we use a value that derefs\n+\t * the object, and if we do grab the object it refers to.\n+\t */\n+\ttagged = &((struct tag *)obj)->tagged->oid;\n+\n+\t/*\n+\t * NEEDSWORK: This derefs tag only once, which\n+\t * is good to deal with chains of trust, but\n+\t * is not consistent with what deref_tag() does\n+\t * which peels the onion to the core.\n+\t */\n+\tbuf = get_obj(tagged, &obj, &size, &eaten);\n+\tif (!buf)\n+\t\tdie(_(\"missing object %s for %s\"),\n+\t\t oid_to_hex(tagged), ref->refname);\n+\tif (!obj)\n+\t\tdie(_(\"parse_object_buffer failed on %s for %s\"),\n+\t\t oid_to_hex(tagged), ref->refname);\n+\tgrab_values(ref->value, 1, obj, buf, size);\n+\tif (!eaten)\n+\t\tfree(buf);\n+}\n+\n /*\n * Parse the object referred by ref, and grab needed value.\n */\n static void populate_value(struct ref_array_item *ref)\n {\n-\tvoid *buf;\n-\tstruct object *obj;\n-\tint eaten, i;\n-\tunsigned long size;\n-\tconst struct object_id *tagged;\n+\tint i;\n \n \tref->value = xcalloc(used_atom_cnt, sizeof(struct atom_value));\n \n@@ -1526,53 +1570,12 @@ static void populate_value(struct ref_array_item *ref)\n \n \tfor (i = 0; i < used_atom_cnt; i++) {\n \t\tstruct atom_value *v = &ref->value[i];\n-\t\tif (v->s == NULL)\n-\t\t\tgoto need_obj;\n+\t\tif (v->s == NULL) {\n+\t\t\tneed_object(ref);\n+\t\t\tbreak;\n+\t\t}\n \t}\n \treturn;\n-\n- need_obj:\n-\tbuf = get_obj(&ref->objectname, &obj, &size, &eaten);\n-\tif (!buf)\n-\t\tdie(_(\"missing object %s for %s\"),\n-\t\t oid_to_hex(&ref->objectname), ref->refname);\n-\tif (!obj)\n-\t\tdie(_(\"parse_object_buffer failed on %s for %s\"),\n-\t\t oid_to_hex(&ref->objectname), ref->refname);\n-\n-\tgrab_values(ref->value, 0, obj, buf, size);\n-\tif (!eaten)\n-\t\tfree(buf);\n-\n-\t/*\n-\t * If there is no atom that wants to know about tagged\n-\t * object, we are done.\n-\t */\n-\tif (!need_tagged || (obj->type != OBJ_TAG))\n-\t\treturn;\n-\n-\t/*\n-\t * If it is a tag object, see if we use a value that derefs\n-\t * the object, and if we do grab the object it refers to.\n-\t */\n-\ttagged = &((struct tag *)obj)->tagged->oid;\n-\n-\t/*\n-\t * NEEDSWORK: This derefs tag only once, which\n-\t * is good to deal with chains of trust, but\n-\t * is not consistent with what deref_tag() does\n-\t * which peels the onion to the core.\n-\t */\n-\tbuf = get_obj(tagged, &obj, &size, &eaten);\n-\tif (!buf)\n-\t\tdie(_(\"missing object %s for %s\"),\n-\t\t oid_to_hex(tagged), ref->refname);\n-\tif (!obj)\n-\t\tdie(_(\"parse_object_buffer failed on %s for %s\"),\n-\t\t oid_to_hex(tagged), ref->refname);\n-\tgrab_values(ref->value, 1, obj, buf, size);\n-\tif (!eaten)\n-\t\tfree(buf);\n }\n \n /*\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336356","messageId":"01020160df6dc5d5-9b4c7836-9762-4055-a8a4-0b65fa0de9de-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 18/18] ref-filter: make cat_file_info independent","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:24Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Remove connection between expand_data variable\nin cat-file and in ref-filter.\nIt will help further to get rid of using expand_data in cat-file.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 2 +-\n ref-filter.c | 28 ++++++++++++++--------------\n ref-filter.h | 1 -\n 3 files changed, 15 insertions(+), 16 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 19cee0d22fabe..ffa8e61213e36 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -289,6 +289,7 @@ static void batch_object_write(const char *obj_name, struct batch_options *opt,\n \titem.start_of_request = obj_name;\n \n \tif (populate_value(&item)) return;\n+\tdata->type = item.type;\n \n \tstrbuf_expand(&buf, opt->format->format, expand_format, &item);\n \tstrbuf_addch(&buf, '\\n');\n@@ -392,7 +393,6 @@ static int batch_objects(struct batch_options *opt)\n \t * object.\n \t */\n \tmemset(&data, 0, sizeof(data));\n-\topt->format->cat_file_data = &data;\n \topt->format->is_cat = 1;\n \topt->format->split_on_whitespace = &data.split_on_whitespace;\n \topt->format->all_objects = opt->all_objects;\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 83bacdd8bdd78..aee6be32f53ef 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -100,7 +100,7 @@ static struct used_atom {\n \t} u;\n } *used_atom;\n static int used_atom_cnt, need_tagged, need_symref;\n-struct expand_data *cat_file_info;\n+struct expand_data cat_file_info;\n static int is_cat = 0;\n \n static void color_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *color_value)\n@@ -256,9 +256,9 @@ static void objectname_atom_parser(const struct ref_format *format, struct used_\n static void objectsize_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n {\n \tif (!arg)\n-\t\tcat_file_info->info.sizep = &cat_file_info->size;\n+\t\tcat_file_info.info.sizep = &cat_file_info.size;\n \telse if (!strcmp(arg, \"disk\"))\n-\t\tcat_file_info->info.disk_sizep = &cat_file_info->disk_size;\n+\t\tcat_file_info.info.disk_sizep = &cat_file_info.disk_size;\n \telse\n \t\tdie(_(\"urecognized %%(objectsize) argument: %s\"), arg);\n }\n@@ -266,7 +266,7 @@ static void objectsize_atom_parser(const struct ref_format *format, struct used_\n static void objecttype_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n {\n \tif (!arg)\n-\t\tcat_file_info->info.typep = &cat_file_info->type;\n+\t\tcat_file_info.info.typep = &cat_file_info.type;\n \telse\n \t\tdie(_(\"urecognized %%(objecttype) argument: %s\"), arg);\n }\n@@ -274,7 +274,7 @@ static void objecttype_atom_parser(const struct ref_format *format, struct used_\n static void deltabase_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n {\n \tif (!arg)\n-\t\tcat_file_info->info.delta_base_sha1 = cat_file_info->delta_base_oid.hash;\n+\t\tcat_file_info.info.delta_base_sha1 = cat_file_info.delta_base_oid.hash;\n \telse\n \t\tdie(_(\"urecognized %%(deltabase) argument: %s\"), arg);\n }\n@@ -739,7 +739,6 @@ int verify_ref_format(struct ref_format *format)\n {\n \tconst char *cp, *sp;\n \n-\tcat_file_info = format->cat_file_data;\n \tis_cat = format->is_cat;\n \tformat->need_color_reset_at_eol = 0;\n \tfor (cp = format->format; *cp && (sp = find_next(cp)); ) {\n@@ -766,8 +765,8 @@ int verify_ref_format(struct ref_format *format)\n \t\tformat->need_color_reset_at_eol = 0;\n \tif (is_cat && format->all_objects) {\n \t\tstruct object_info empty = OBJECT_INFO_INIT;\n-\t\tif (!memcmp(&cat_file_info->info, &empty, sizeof(empty)))\n-\t\t\tcat_file_info->skip_object_info = 1;\n+\t\tif (!memcmp(&cat_file_info.info, &empty, sizeof(empty)))\n+\t\t\tcat_file_info.skip_object_info = 1;\n \t}\n \treturn 0;\n }\n@@ -1472,18 +1471,19 @@ int populate_value(struct ref_array_item *ref)\n \t}\n \n \tif (is_cat) {\n-\t\tif (!cat_file_info->skip_object_info &&\n-\t\t sha1_object_info_extended(ref->objectname.hash, &cat_file_info->info,\n+\t\tif (!cat_file_info.info.typep) cat_file_info.info.typep = &cat_file_info.type;\n+\t\tif (!cat_file_info.skip_object_info &&\n+\t\t sha1_object_info_extended(ref->objectname.hash, &cat_file_info.info,\n \t\t\t\t\t OBJECT_INFO_LOOKUP_REPLACE) < 0) {\n \t\t\tconst char *e = ref->start_of_request;\n \t\t\tprintf(\"%s missing\\n\", e ? e : oid_to_hex(&ref->objectname));\n \t\t\tfflush(stdout);\n \t\t\treturn -1;\n \t\t}\n-\t\tref->type = cat_file_info->type;\n-\t\tref->size = cat_file_info->size;\n-\t\tref->disk_size = cat_file_info->disk_size;\n-\t\tref->delta_base_oid = cat_file_info->delta_base_oid;\n+\t\tref->type = cat_file_info.type;\n+\t\tref->size = cat_file_info.size;\n+\t\tref->disk_size = cat_file_info.disk_size;\n+\t\tref->delta_base_oid = cat_file_info.delta_base_oid;\n \t}\n \n \t/* Fill in specials first */\ndiff --git a/ref-filter.h b/ref-filter.h\nindex e588d1f50eef6..d3e0cbdd4ce6d 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -125,7 +125,6 @@ struct ref_format {\n \t * Helps to move all formatting logic from cat-file to ref-filter,\n \t * hopefully would be reduced later.\n \t */\n-\tstruct expand_data *cat_file_data;\n \tint is_cat;\n \tint *split_on_whitespace;\n \tint all_objects;\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336357","messageId":"01020160df6dc51d-7cd5fb1a-9798-49c1-bc82-480108e1a90b-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 02/18] cat-file: reuse struct ref_format","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:34Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Start using ref_format struct instead of simple char*.\nNeed that for further reusing of formatting logic from ref-filter.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 16 +++++++++-------\n 1 file changed, 9 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex f783b39b9bd5c..7655a9a726773 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -13,15 +13,16 @@\n #include \"tree-walk.h\"\n #include \"sha1-array.h\"\n #include \"packfile.h\"\n+#include \"ref-filter.h\"\n \n struct batch_options {\n+\tstruct ref_format *format;\n \tint enabled;\n \tint follow_symlinks;\n \tint print_contents;\n \tint buffer_output;\n \tint all_objects;\n \tint cmdmode; /* may be 'w' or 'c' for --filters or --textconv */\n-\tconst char *format;\n };\n \n static const char *force_path;\n@@ -353,7 +354,7 @@ static void batch_object_write(const char *obj_name, struct batch_options *opt,\n \t\treturn;\n \t}\n \n-\tstrbuf_expand(&buf, opt->format, expand_format, data);\n+\tstrbuf_expand(&buf, opt->format->format, expand_format, data);\n \tstrbuf_addch(&buf, '\\n');\n \tbatch_write(opt, buf.buf, buf.len);\n \tstrbuf_release(&buf);\n@@ -446,8 +447,8 @@ static int batch_objects(struct batch_options *opt)\n \tint save_warning;\n \tint retval = 0;\n \n-\tif (!opt->format)\n-\t\topt->format = \"%(objectname) %(objecttype) %(objectsize)\";\n+\tif (!opt->format->format)\n+\t\topt->format->format = \"%(objectname) %(objecttype) %(objectsize)\";\n \n \t/*\n \t * Expand once with our special mark_query flag, which will prime the\n@@ -456,7 +457,7 @@ static int batch_objects(struct batch_options *opt)\n \t */\n \tmemset(&data, 0, sizeof(data));\n \tdata.mark_query = 1;\n-\tstrbuf_expand(&buf, opt->format, expand_format, &data);\n+\tstrbuf_expand(&buf, opt->format->format, expand_format, &data);\n \tdata.mark_query = 0;\n \tif (opt->cmdmode)\n \t\tdata.split_on_whitespace = 1;\n@@ -548,7 +549,7 @@ static int batch_option_callback(const struct option *opt,\n \n \tbo->enabled = 1;\n \tbo->print_contents = !strcmp(opt->long_name, \"batch\");\n-\tbo->format = arg;\n+\tbo->format->format = arg;\n \n \treturn 0;\n }\n@@ -557,7 +558,8 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)\n {\n \tint opt = 0;\n \tconst char *exp_type = NULL, *obj_name = NULL;\n-\tstruct batch_options batch = {0};\n+\tstruct ref_format format = REF_FORMAT_INIT;\n+\tstruct batch_options batch = {&format};\n \tint unknown_type = 0;\n \n \tconst struct option options[] = {\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336358","messageId":"01020160df6dc54b-3776504b-c5b2-4139-8ade-e54b3213df19-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 07/18] cat-file: remove unused code","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:49Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"No further need in mark_query parameter.\nAll logic related to expand_atom_into_fields is not needed here also,\nwe are doing that in ref-filter.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 25 +------------------------\n ref-filter.h | 6 ------\n 2 files changed, 1 insertion(+), 30 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 0a3f4a47bf1ae..9055fa3a8b0ae 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -182,25 +182,6 @@ static int is_atom(const char *atom, const char *s, int slen)\n \treturn alen == slen && !memcmp(atom, s, alen);\n }\n \n-static void expand_atom_into_fields(struct strbuf *sb, const char *atom, int len,\n-\t\t\tstruct expand_data *data)\n-{\n-\tif (is_atom(\"objectname\", atom, len))\n-\t\t; /* do nothing */\n-\telse if (is_atom(\"objecttype\", atom, len))\n-\t\tdata->info.typep = &data->type;\n-\telse if (is_atom(\"objectsize\", atom, len))\n-\t\tdata->info.sizep = &data->size;\n-\telse if (is_atom(\"objectsize:disk\", atom, len))\n-\t\tdata->info.disk_sizep = &data->disk_size;\n-\telse if (is_atom(\"rest\", atom, len))\n-\t\tdata->split_on_whitespace = 1;\n-\telse if (is_atom(\"deltabase\", atom, len))\n-\t\tdata->info.delta_base_sha1 = data->delta_base_oid.hash;\n-\telse\n-\t\tdie(\"unknown format element: %.*s\", len, atom);\n-}\n-\n static void expand_atom(struct strbuf *sb, const char *atom, int len,\n \t\t\t struct expand_data *data)\n {\n@@ -232,11 +213,7 @@ static size_t expand_format(struct strbuf *sb, const char *start, void *vdata)\n \tif (!end)\n \t\tdie(\"format element '%s' does not end in ')'\", start);\n \n-\tif (data->mark_query)\n-\t\texpand_atom_into_fields(sb, start + 1, end - start - 1, data);\n-\telse\n-\t\texpand_atom(sb, start + 1, end - start - 1, data);\n-\n+\texpand_atom(sb, start + 1, end - start - 1, data);\n \treturn end - start + 1;\n }\n \ndiff --git a/ref-filter.h b/ref-filter.h\nindex 97169548939cd..590a60ffe034d 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -80,12 +80,6 @@ struct expand_data {\n \tconst char *rest;\n \tstruct object_id delta_base_oid;\n \n-\t/*\n-\t * If mark_query is true, we do not expand anything, but rather\n-\t * just mark the object_info with items we wish to query.\n-\t */\n-\tint mark_query;\n-\n \t/*\n \t * Whether to split the input on whitespace before feeding it to\n \t * get_sha1; this is decided during the mark_query phase based on\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336359","messageId":"01020160df6dc580-335fa6d5-a506-49b7-a326-d85cb87af75b-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 10/18] cat-file: get rid of duplicate checking","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:37:51Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"We could remove this because we have already checked that\nat verify_ref_format function in ref-filter.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 2 --\n 1 file changed, 2 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex dd43457c0ad7e..1f331559e55c7 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -197,8 +197,6 @@ static void expand_atom(struct strbuf *sb, const char *atom, int len,\n \t\tstrbuf_addstr(sb, data->rest);\n \telse if (is_atom(\"deltabase\", atom, len))\n \t\tstrbuf_addstr(sb, oid_to_hex(&data->delta_base_oid));\n-\telse\n-\t\tdie(\"unknown format element: %.*s\", len, atom);\n }\n \n static size_t expand_format(struct strbuf *sb, const char *start, void *vdata)\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336360","messageId":"01020160df6dc5cf-1aea868b-d09a-497a-904e-c282d89036f1-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 17/18] cat-file: move skip_object_info into ref-filter","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:01Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Move logic related to skip_object_info into ref-filter,\nso that cat-file does not use that field at all.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 7 +------\n ref-filter.c | 5 +++++\n ref-filter.h | 1 +\n 3 files changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 5aac10b9808ff..19cee0d22fabe 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -395,16 +395,11 @@ static int batch_objects(struct batch_options *opt)\n \topt->format->cat_file_data = &data;\n \topt->format->is_cat = 1;\n \topt->format->split_on_whitespace = &data.split_on_whitespace;\n+\topt->format->all_objects = opt->all_objects;\n \tverify_ref_format(opt->format);\n \tif (opt->cmdmode)\n \t\tdata.split_on_whitespace = 1;\n \n-\tif (opt->all_objects) {\n-\t\tstruct object_info empty = OBJECT_INFO_INIT;\n-\t\tif (!memcmp(&data.info, &empty, sizeof(empty)))\n-\t\t\tdata.skip_object_info = 1;\n-\t}\n-\n \t/*\n \t * If we are printing out the object, then always fill in the type,\n \t * since we will want to decide whether or not to stream.\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 0fb33198fb450..83bacdd8bdd78 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -764,6 +764,11 @@ int verify_ref_format(struct ref_format *format)\n \t}\n \tif (format->need_color_reset_at_eol && !want_color(format->use_color))\n \t\tformat->need_color_reset_at_eol = 0;\n+\tif (is_cat && format->all_objects) {\n+\t\tstruct object_info empty = OBJECT_INFO_INIT;\n+\t\tif (!memcmp(&cat_file_info->info, &empty, sizeof(empty)))\n+\t\t\tcat_file_info->skip_object_info = 1;\n+\t}\n \treturn 0;\n }\n \ndiff --git a/ref-filter.h b/ref-filter.h\nindex aaf1790e43e62..e588d1f50eef6 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -128,6 +128,7 @@ struct ref_format {\n \tstruct expand_data *cat_file_data;\n \tint is_cat;\n \tint *split_on_whitespace;\n+\tint all_objects;\n };\n \n #define REF_FORMAT_INIT { NULL, 0, -1 }\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336361","messageId":"01020160df6dc537-9512602f-61a7-408f-a78a-289be6a96b93-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 05/18] cat-file: start migrating to ref-filter","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:04Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Start moving all formatting stuff from cat-file to ref-filter.\nStart from simple moving, it would be integrated into\nall ref-filter processes further.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 5 ++---\n ref-filter.c | 41 ++++++++++++++++++++++++++++++++++++-----\n ref-filter.h | 6 ++++++\n 3 files changed, 44 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 7fd5b960ad698..0a3f4a47bf1ae 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -420,9 +420,8 @@ static int batch_objects(struct batch_options *opt)\n \t * object.\n \t */\n \tmemset(&data, 0, sizeof(data));\n-\tdata.mark_query = 1;\n-\tstrbuf_expand(&buf, opt->format->format, expand_format, &data);\n-\tdata.mark_query = 0;\n+\topt->format->cat_file_data = &data;\n+\tverify_ref_format(opt->format);\n \tif (opt->cmdmode)\n \t\tdata.split_on_whitespace = 1;\n \ndiff --git a/ref-filter.c b/ref-filter.c\nindex 32b7e918bca75..6ca4a671086ee 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -392,6 +392,31 @@ struct atom_value {\n \tstruct used_atom *atom;\n };\n \n+static int is_atom(const char *atom, const char *s, int slen)\n+{\n+\tint alen = strlen(atom);\n+\treturn alen == slen && !memcmp(atom, s, alen);\n+}\n+\n+static void expand_atom_into_fields(const char *atom, int len,\n+\t\t\t\t struct expand_data *data)\n+{\n+\tif (is_atom(\"objectname\", atom, len))\n+\t\t; /* do nothing */\n+\telse if (is_atom(\"objecttype\", atom, len))\n+\t\tdata->info.typep = &data->type;\n+\telse if (is_atom(\"objectsize\", atom, len))\n+\t\tdata->info.sizep = &data->size;\n+\telse if (is_atom(\"objectsize:disk\", atom, len))\n+\t\tdata->info.disk_sizep = &data->disk_size;\n+\telse if (is_atom(\"rest\", atom, len))\n+\t\tdata->split_on_whitespace = 1;\n+\telse if (is_atom(\"deltabase\", atom, len))\n+\t\tdata->info.delta_base_sha1 = data->delta_base_oid.hash;\n+\telse\n+\t\tdie(\"unknown format element: %.*s\", len, atom);\n+}\n+\n /*\n * Used to parse format string and sort specifiers\n */\n@@ -709,12 +734,18 @@ int verify_ref_format(struct ref_format *format)\n \t\tif (!ep)\n \t\t\treturn error(_(\"malformed format string %s\"), sp);\n \t\t/* sp points at \"%(\" and ep points at the closing \")\" */\n-\t\tat = parse_ref_filter_atom(format, valid_atom,\n-\t\t\t\t\t ARRAY_SIZE(valid_atom), sp + 2, ep);\n-\t\tcp = ep + 1;\n \n-\t\tif (skip_prefix(used_atom[at].name, \"color:\", &color))\n-\t\t\tformat->need_color_reset_at_eol = !!strcmp(color, \"reset\");\n+\t\tif (format->cat_file_data)\n+\t\t\texpand_atom_into_fields(sp + 2, ep - sp - 2,\n+\t\t\t\t\t\tformat->cat_file_data);\n+\t\telse {\n+\t\t\tat = parse_ref_filter_atom(format, valid_atom,\n+\t\t\t\t\t\t ARRAY_SIZE(valid_atom), sp + 2, ep);\n+\t\t\tif (skip_prefix(used_atom[at].name, \"color:\", &color))\n+\t\t\t\tformat->need_color_reset_at_eol = !!strcmp(color, \"reset\");\n+\t\t}\n+\n+\t\tcp = ep + 1;\n \t}\n \tif (format->need_color_reset_at_eol && !want_color(format->use_color))\n \t\tformat->need_color_reset_at_eol = 0;\ndiff --git a/ref-filter.h b/ref-filter.h\nindex 16d00e4b1bded..97169548939cd 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -119,6 +119,12 @@ struct ref_format {\n \n \t/* Internal state to ref-filter */\n \tint need_color_reset_at_eol;\n+\n+\t/*\n+\t * Helps to move all formatting logic from cat-file to ref-filter,\n+\t * hopefully would be reduced later.\n+\t */\n+\tstruct expand_data *cat_file_data;\n };\n \n #define REF_FORMAT_INIT { NULL, 0, -1 }\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336362","messageId":"01020160df6dc56f-955e97ff-4dc8-4471-8fb6-32dc9572781e-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 09/18] cat-file: simplify expand_atom function","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:39Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Not sure, but looks like there is no need in that checking.\nThere is a checking before whether it is null and we die in such case.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 7 +++----\n 1 file changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 9055fa3a8b0ae..dd43457c0ad7e 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -193,10 +193,9 @@ static void expand_atom(struct strbuf *sb, const char *atom, int len,\n \t\tstrbuf_addf(sb, \"%lu\", data->size);\n \telse if (is_atom(\"objectsize:disk\", atom, len))\n \t\tstrbuf_addf(sb, \"%\"PRIuMAX, (uintmax_t)data->disk_size);\n-\telse if (is_atom(\"rest\", atom, len)) {\n-\t\tif (data->rest)\n-\t\t\tstrbuf_addstr(sb, data->rest);\n-\t} else if (is_atom(\"deltabase\", atom, len))\n+\telse if (is_atom(\"rest\", atom, len))\n+\t\tstrbuf_addstr(sb, data->rest);\n+\telse if (is_atom(\"deltabase\", atom, len))\n \t\tstrbuf_addstr(sb, oid_to_hex(&data->delta_base_oid));\n \telse\n \t\tdie(\"unknown format element: %.*s\", len, atom);\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336363","messageId":"01020160df6dc58b-a6cf8e70-3bde-461d-98af-5e5129973960-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 13/18] cat-file: start reusing populate_value","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:42Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Move logic related to getting object info from cat-file to ref-filter.\nIt will help to reuse whole formatting logic from ref-filter further.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 16 +++-------------\n ref-filter.c | 15 +++++++++++++++\n ref-filter.h | 2 ++\n 3 files changed, 20 insertions(+), 13 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 1c92194faaede..e11dbf88e386c 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -284,21 +284,11 @@ static void batch_object_write(const char *obj_name, struct batch_options *opt,\n \tstruct strbuf buf = STRBUF_INIT;\n \tstruct ref_array_item item;\n \n-\tif (!data->skip_object_info &&\n-\t sha1_object_info_extended(data->oid.hash, &data->info,\n-\t\t\t\t OBJECT_INFO_LOOKUP_REPLACE) < 0) {\n-\t\tprintf(\"%s missing\\n\",\n-\t\t obj_name ? obj_name : oid_to_hex(&data->oid));\n-\t\tfflush(stdout);\n-\t\treturn;\n-\t}\n-\n \titem.objectname = data->oid;\n-\titem.type = data->type;\n-\titem.size = data->size;\n-\titem.disk_size = data->disk_size;\n \titem.rest = data->rest;\n-\titem.delta_base_oid = data->delta_base_oid;\n+\titem.start_of_request = obj_name;\n+\n+\tif (populate_value(&item)) return;\n \n \tstrbuf_expand(&buf, opt->format->format, expand_format, &item);\n \tstrbuf_addch(&buf, '\\n');\ndiff --git a/ref-filter.c b/ref-filter.c\nindex c15906cb091c7..35e16cec6d862 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -1467,6 +1467,21 @@ int populate_value(struct ref_array_item *ref)\n \t\t\tref->symref = \"\";\n \t}\n \n+\tif (cat_file_info) {\n+\t\tif (!cat_file_info->skip_object_info &&\n+\t\t sha1_object_info_extended(ref->objectname.hash, &cat_file_info->info,\n+\t\t\t\t\t OBJECT_INFO_LOOKUP_REPLACE) < 0) {\n+\t\t\tconst char *e = ref->start_of_request;\n+\t\t\tprintf(\"%s missing\\n\", e ? e : oid_to_hex(&ref->objectname));\n+\t\t\tfflush(stdout);\n+\t\t\treturn -1;\n+\t\t}\n+\t\tref->type = cat_file_info->type;\n+\t\tref->size = cat_file_info->size;\n+\t\tref->disk_size = cat_file_info->disk_size;\n+\t\tref->delta_base_oid = cat_file_info->delta_base_oid;\n+\t}\n+\n \t/* Fill in specials first */\n \tfor (i = 0; i < used_atom_cnt; i++) {\n \t\tstruct used_atom *atom = &used_atom[i];\ndiff --git a/ref-filter.h b/ref-filter.h\nindex 6df45c5bd9dcb..0c7253913735b 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -45,6 +45,8 @@ struct ref_array_item {\n \toff_t disk_size;\n \tconst char *rest;\n \tstruct object_id delta_base_oid;\n+\t/* Need it for better explanation in error log. */\n+\tconst char *start_of_request;\n \tchar refname[FLEX_ARRAY];\n };\n \n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336364","messageId":"01020160df6dc583-8c4e2489-bbba-43d5-b2b8-48794531acea-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 11/18] cat-file: start use ref_array_item struct","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:43Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Moving from using expand_data to ref_array_item structure.\nThat helps us to reuse functions from ref-filter easier.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 30 +++++++++++++++++++-----------\n ref-filter.h | 5 +++++\n 2 files changed, 24 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 1f331559e55c7..1c92194faaede 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -183,26 +183,26 @@ static int is_atom(const char *atom, const char *s, int slen)\n }\n \n static void expand_atom(struct strbuf *sb, const char *atom, int len,\n-\t\t\t struct expand_data *data)\n+\t\t\t struct ref_array_item *item)\n {\n \tif (is_atom(\"objectname\", atom, len))\n-\t\tstrbuf_addstr(sb, oid_to_hex(&data->oid));\n+\t\tstrbuf_addstr(sb, oid_to_hex(&item->objectname));\n \telse if (is_atom(\"objecttype\", atom, len))\n-\t\tstrbuf_addstr(sb, typename(data->type));\n+\t\tstrbuf_addstr(sb, typename(item->type));\n \telse if (is_atom(\"objectsize\", atom, len))\n-\t\tstrbuf_addf(sb, \"%lu\", data->size);\n+\t\tstrbuf_addf(sb, \"%lu\", item->size);\n \telse if (is_atom(\"objectsize:disk\", atom, len))\n-\t\tstrbuf_addf(sb, \"%\"PRIuMAX, (uintmax_t)data->disk_size);\n+\t\tstrbuf_addf(sb, \"%\"PRIuMAX, (uintmax_t)item->disk_size);\n \telse if (is_atom(\"rest\", atom, len))\n-\t\tstrbuf_addstr(sb, data->rest);\n+\t\tstrbuf_addstr(sb, item->rest);\n \telse if (is_atom(\"deltabase\", atom, len))\n-\t\tstrbuf_addstr(sb, oid_to_hex(&data->delta_base_oid));\n+\t\tstrbuf_addstr(sb, oid_to_hex(&item->delta_base_oid));\n }\n \n-static size_t expand_format(struct strbuf *sb, const char *start, void *vdata)\n+static size_t expand_format(struct strbuf *sb, const char *start, void *data)\n {\n \tconst char *end;\n-\tstruct expand_data *data = vdata;\n+\tstruct ref_array_item *item = data;\n \n \tif (*start != '(')\n \t\treturn 0;\n@@ -210,7 +210,7 @@ static size_t expand_format(struct strbuf *sb, const char *start, void *vdata)\n \tif (!end)\n \t\tdie(\"format element '%s' does not end in ')'\", start);\n \n-\texpand_atom(sb, start + 1, end - start - 1, data);\n+\texpand_atom(sb, start + 1, end - start - 1, item);\n \treturn end - start + 1;\n }\n \n@@ -282,6 +282,7 @@ static void batch_object_write(const char *obj_name, struct batch_options *opt,\n \t\t\t struct expand_data *data)\n {\n \tstruct strbuf buf = STRBUF_INIT;\n+\tstruct ref_array_item item;\n \n \tif (!data->skip_object_info &&\n \t sha1_object_info_extended(data->oid.hash, &data->info,\n@@ -292,7 +293,14 @@ static void batch_object_write(const char *obj_name, struct batch_options *opt,\n \t\treturn;\n \t}\n \n-\tstrbuf_expand(&buf, opt->format->format, expand_format, data);\n+\titem.objectname = data->oid;\n+\titem.type = data->type;\n+\titem.size = data->size;\n+\titem.disk_size = data->disk_size;\n+\titem.rest = data->rest;\n+\titem.delta_base_oid = data->delta_base_oid;\n+\n+\tstrbuf_expand(&buf, opt->format->format, expand_format, &item);\n \tstrbuf_addch(&buf, '\\n');\n \tbatch_write(opt, buf.buf, buf.len);\n \tstrbuf_release(&buf);\ndiff --git a/ref-filter.h b/ref-filter.h\nindex 590a60ffe034d..9bd36243481b4 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -40,6 +40,11 @@ struct ref_array_item {\n \tconst char *symref;\n \tstruct commit *commit;\n \tstruct atom_value *value;\n+\tenum object_type type;\n+\tunsigned long size;\n+\toff_t disk_size;\n+\tconst char *rest;\n+\tstruct object_id delta_base_oid;\n \tchar refname[FLEX_ARRAY];\n };\n \n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336365","messageId":"01020160df6dc548-3213651c-f87e-40f6-80b3-4fe2ee9131be-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 06/18] ref-filter: reuse parse_ref_filter_atom","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:47Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Continue migrating formatting logic from cat-file to ref-filter.\nReuse parse_ref_filter_atom for unifying all processes in ref-filter\nand further reducing of expand_atom_into_fields function.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n ref-filter.c | 38 +++++++++++++++++++++++++++-----------\n 1 file changed, 27 insertions(+), 11 deletions(-)\n\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 6ca4a671086ee..bb09875e2dbf4 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -100,6 +100,7 @@ static struct used_atom {\n \t} u;\n } *used_atom;\n static int used_atom_cnt, need_tagged, need_symref;\n+struct expand_data *cat_file_info;\n \n static void color_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *color_value)\n {\n@@ -251,6 +252,16 @@ static void objectname_atom_parser(const struct ref_format *format, struct used_\n \t\tdie(_(\"unrecognized %%(objectname) argument: %s\"), arg);\n }\n \n+static void objectsize_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n+{\n+\tif (!arg)\n+\t\t; /* default to normal object size */\n+\telse if (!strcmp(arg, \"disk\"))\n+\t\tcat_file_info->info.disk_sizep = &cat_file_info->disk_size;\n+\telse\n+\t\tdie(_(\"urecognized %%(objectsize) argument: %s\"), arg);\n+}\n+\n static void refname_atom_parser(const struct ref_format *format, struct used_atom *atom, const char *arg)\n {\n \trefname_atom_parser_internal(&atom->u.refname, arg, atom->name);\n@@ -371,6 +382,14 @@ static struct valid_atom {\n \t{ \"else\" },\n };\n \n+static struct valid_atom valid_cat_file_atom[] = {\n+\t{ \"objectname\" },\n+\t{ \"objecttype\" },\n+\t{ \"objectsize\", FIELD_ULONG, objectsize_atom_parser },\n+\t{ \"rest\" },\n+\t{ \"deltabase\" },\n+};\n+\n #define REF_FORMATTING_STATE_INIT { 0, NULL }\n \n struct ref_formatting_stack {\n@@ -401,20 +420,14 @@ static int is_atom(const char *atom, const char *s, int slen)\n static void expand_atom_into_fields(const char *atom, int len,\n \t\t\t\t struct expand_data *data)\n {\n-\tif (is_atom(\"objectname\", atom, len))\n-\t\t; /* do nothing */\n-\telse if (is_atom(\"objecttype\", atom, len))\n+\tif (is_atom(\"objecttype\", atom, len))\n \t\tdata->info.typep = &data->type;\n \telse if (is_atom(\"objectsize\", atom, len))\n \t\tdata->info.sizep = &data->size;\n-\telse if (is_atom(\"objectsize:disk\", atom, len))\n-\t\tdata->info.disk_sizep = &data->disk_size;\n \telse if (is_atom(\"rest\", atom, len))\n \t\tdata->split_on_whitespace = 1;\n \telse if (is_atom(\"deltabase\", atom, len))\n \t\tdata->info.delta_base_sha1 = data->delta_base_oid.hash;\n-\telse\n-\t\tdie(\"unknown format element: %.*s\", len, atom);\n }\n \n /*\n@@ -483,6 +496,8 @@ static int parse_ref_filter_atom(const struct ref_format *format,\n \t\tneed_tagged = 1;\n \tif (!strcmp(valid_atom[i].name, \"symref\"))\n \t\tneed_symref = 1;\n+\tif (cat_file_info)\n+\t\texpand_atom_into_fields(atom, atom_len, cat_file_info);\n \treturn at;\n }\n \n@@ -726,6 +741,7 @@ int verify_ref_format(struct ref_format *format)\n {\n \tconst char *cp, *sp;\n \n+\tcat_file_info = format->cat_file_data;\n \tformat->need_color_reset_at_eol = 0;\n \tfor (cp = format->format; *cp && (sp = find_next(cp)); ) {\n \t\tconst char *color, *ep = strchr(sp, ')');\n@@ -735,10 +751,10 @@ int verify_ref_format(struct ref_format *format)\n \t\t\treturn error(_(\"malformed format string %s\"), sp);\n \t\t/* sp points at \"%(\" and ep points at the closing \")\" */\n \n-\t\tif (format->cat_file_data)\n-\t\t\texpand_atom_into_fields(sp + 2, ep - sp - 2,\n-\t\t\t\t\t\tformat->cat_file_data);\n-\t\telse {\n+\t\tif (format->cat_file_data) {\n+\t\t\tat = parse_ref_filter_atom(format, valid_cat_file_atom,\n+\t\t\t\t\t\t ARRAY_SIZE(valid_cat_file_atom), sp + 2, ep);\n+\t\t} else {\n \t\t\tat = parse_ref_filter_atom(format, valid_atom,\n \t\t\t\t\t\t ARRAY_SIZE(valid_atom), sp + 2, ep);\n \t\t\tif (skip_prefix(used_atom[at].name, \"color:\", &color))\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336366","messageId":"01020160df6dc587-aae8f2f1-48a8-4fdd-9917-0e5f4e62cf03-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 12/18] ref-filter: make populate_value global","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:50Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Make function global for further using in cat-file.\nAlso added return value for handling errors.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n ref-filter.c | 4 ++--\n ref-filter.h | 3 +++\n 2 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 575c5351d0f79..c15906cb091c7 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -1454,7 +1454,7 @@ static void need_object(struct ref_array_item *ref) {\n /*\n * Parse the object referred by ref, and grab needed value.\n */\n-static void populate_value(struct ref_array_item *ref)\n+int populate_value(struct ref_array_item *ref)\n {\n \tint i;\n \n@@ -1575,7 +1575,7 @@ static void populate_value(struct ref_array_item *ref)\n \t\t\tbreak;\n \t\t}\n \t}\n-\treturn;\n+\treturn 0;\n }\n \n /*\ndiff --git a/ref-filter.h b/ref-filter.h\nindex 9bd36243481b4..6df45c5bd9dcb 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -176,4 +176,7 @@ void setup_ref_filter_porcelain_msg(void);\n void pretty_print_ref(const char *name, const unsigned char *sha1,\n \t\t const struct ref_format *format);\n \n+/* Fill the values of request and prepare all data for final string creation */\n+int populate_value(struct ref_array_item *ref);\n+\n #endif /* REF_FILTER_H */\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336367","messageId":"01020160df6dc532-75f3ef78-26cb-4751-9ded-eb0e8d23833b-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 04/18] cat-file: move struct expand_data into ref-filter","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:52Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Need that for further reusing of formatting logic in cat-file.\nHave plans to get rid of using expand_data in cat-file at all,\nand use it only in ref-filter for collecting, formatting and printing\nneeded data.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n builtin/cat-file.c | 36 ------------------------------------\n ref-filter.h | 36 ++++++++++++++++++++++++++++++++++++\n 2 files changed, 36 insertions(+), 36 deletions(-)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 7655a9a726773..7fd5b960ad698 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -176,42 +176,6 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name,\n \treturn 0;\n }\n \n-struct expand_data {\n-\tstruct object_id oid;\n-\tenum object_type type;\n-\tunsigned long size;\n-\toff_t disk_size;\n-\tconst char *rest;\n-\tstruct object_id delta_base_oid;\n-\n-\t/*\n-\t * If mark_query is true, we do not expand anything, but rather\n-\t * just mark the object_info with items we wish to query.\n-\t */\n-\tint mark_query;\n-\n-\t/*\n-\t * Whether to split the input on whitespace before feeding it to\n-\t * get_sha1; this is decided during the mark_query phase based on\n-\t * whether we have a %(rest) token in our format.\n-\t */\n-\tint split_on_whitespace;\n-\n-\t/*\n-\t * After a mark_query run, this object_info is set up to be\n-\t * passed to sha1_object_info_extended. It will point to the data\n-\t * elements above, so you can retrieve the response from there.\n-\t */\n-\tstruct object_info info;\n-\n-\t/*\n-\t * This flag will be true if the requested batch format and options\n-\t * don't require us to call sha1_object_info, which can then be\n-\t * optimized out.\n-\t */\n-\tunsigned skip_object_info : 1;\n-};\n-\n static int is_atom(const char *atom, const char *s, int slen)\n {\n \tint alen = strlen(atom);\ndiff --git a/ref-filter.h b/ref-filter.h\nindex 0d98342b34319..16d00e4b1bded 100644\n--- a/ref-filter.h\n+++ b/ref-filter.h\n@@ -72,6 +72,42 @@ struct ref_filter {\n \t\tverbose;\n };\n \n+struct expand_data {\n+\tstruct object_id oid;\n+\tenum object_type type;\n+\tunsigned long size;\n+\toff_t disk_size;\n+\tconst char *rest;\n+\tstruct object_id delta_base_oid;\n+\n+\t/*\n+\t * If mark_query is true, we do not expand anything, but rather\n+\t * just mark the object_info with items we wish to query.\n+\t */\n+\tint mark_query;\n+\n+\t/*\n+\t * Whether to split the input on whitespace before feeding it to\n+\t * get_sha1; this is decided during the mark_query phase based on\n+\t * whether we have a %(rest) token in our format.\n+\t */\n+\tint split_on_whitespace;\n+\n+\t/*\n+\t * After a mark_query run, this object_info is set up to be\n+\t * passed to sha1_object_info_extended. It will point to the data\n+\t * elements above, so you can retrieve the response from there.\n+\t */\n+\tstruct object_info info;\n+\n+\t/*\n+\t * This flag will be true if the requested batch format and options\n+\t * don't require us to call sha1_object_info, which can then be\n+\t * optimized out.\n+\t */\n+\tunsigned skip_object_info : 1;\n+};\n+\n struct ref_format {\n \t/*\n \t * Set these to define the format; make sure you call\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336368","messageId":"01020160df6dc529-fae54bd6-e595-44fa-9f9a-c44cb3a5a1a8-000000@eu-west-1.amazonses.com","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"[PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Olga Telezhnaya","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-10T09:36:41Z","receivedAt":"2018-01-10T09:38:56Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Make valid_atom as a function parameter,\nthere could be another variable further.\nNeed that for further reusing of formatting logic in cat-file.c.\n\nWe do not need to allow users to pass their own valid_atom variable in\nglobal functions like verify_ref_format because in the end we want to\nhave same set of valid atoms for all commands. But, as a first step\nof migrating, I create further another version of valid_atom\nfor cat-file.\n\nSigned-off-by: Olga Telezhnaia \nMentored-by: Christian Couder \nMentored by: Jeff King \n---\n ref-filter.c | 17 +++++++++++------\n 1 file changed, 11 insertions(+), 6 deletions(-)\n\ndiff --git a/ref-filter.c b/ref-filter.c\nindex 3f9161707e66b..32b7e918bca75 100644\n--- a/ref-filter.c\n+++ b/ref-filter.c\n@@ -325,7 +325,7 @@ static void head_atom_parser(const struct ref_format *format, struct used_atom *\n \tatom->u.head = resolve_refdup(\"HEAD\", RESOLVE_REF_READING, NULL, NULL);\n }\n \n-static struct {\n+static struct valid_atom {\n \tconst char *name;\n \tcmp_type cmp_type;\n \tvoid (*parser)(const struct ref_format *format, struct used_atom *atom, const char *arg);\n@@ -396,6 +396,7 @@ struct atom_value {\n * Used to parse format string and sort specifiers\n */\n static int parse_ref_filter_atom(const struct ref_format *format,\n+\t\t\t\t const struct valid_atom *valid_atom, int n_atoms,\n \t\t\t\t const char *atom, const char *ep)\n {\n \tconst char *sp;\n@@ -425,13 +426,13 @@ static int parse_ref_filter_atom(const struct ref_format *format,\n \tatom_len = (arg ? arg : ep) - sp;\n \n \t/* Is the atom a valid one? */\n-\tfor (i = 0; i < ARRAY_SIZE(valid_atom); i++) {\n+\tfor (i = 0; i < n_atoms; i++) {\n \t\tint len = strlen(valid_atom[i].name);\n \t\tif (len == atom_len && !memcmp(valid_atom[i].name, sp, len))\n \t\t\tbreak;\n \t}\n \n-\tif (ARRAY_SIZE(valid_atom) <= i)\n+\tif (n_atoms <= i)\n \t\tdie(_(\"unknown field name: %.*s\"), (int)(ep-atom), atom);\n \n \t/* Add it in, including the deref prefix */\n@@ -708,7 +709,8 @@ int verify_ref_format(struct ref_format *format)\n \t\tif (!ep)\n \t\t\treturn error(_(\"malformed format string %s\"), sp);\n \t\t/* sp points at \"%(\" and ep points at the closing \")\" */\n-\t\tat = parse_ref_filter_atom(format, sp + 2, ep);\n+\t\tat = parse_ref_filter_atom(format, valid_atom,\n+\t\t\t\t\t ARRAY_SIZE(valid_atom), sp + 2, ep);\n \t\tcp = ep + 1;\n \n \t\tif (skip_prefix(used_atom[at].name, \"color:\", &color))\n@@ -2139,7 +2141,9 @@ void format_ref_array_item(struct ref_array_item *info,\n \t\tif (cp < sp)\n \t\t\tappend_literal(cp, sp, &state);\n \t\tget_ref_atom_value(info,\n-\t\t\t\t parse_ref_filter_atom(format, sp + 2, ep),\n+\t\t\t\t parse_ref_filter_atom(format, valid_atom,\n+\t\t\t\t\t\t\t ARRAY_SIZE(valid_atom),\n+\t\t\t\t\t\t\t sp + 2, ep),\n \t\t\t\t &atomv);\n \t\tatomv->handler(atomv, &state);\n \t}\n@@ -2187,7 +2191,8 @@ static int parse_sorting_atom(const char *atom)\n \t */\n \tstruct ref_format dummy = REF_FORMAT_INIT;\n \tconst char *end = atom + strlen(atom);\n-\treturn parse_ref_filter_atom(&dummy, atom, end);\n+\treturn parse_ref_filter_atom(&dummy, valid_atom,\n+\t\t\t\t ARRAY_SIZE(valid_atom), atom, end);\n }\n \n /* If no sorting option is given, use refname to sort as default */\n\n--\nhttps://github.com/git/git/pull/450\n"},{"id":"336630","messageId":"20180115213335.GB4778@sigill.intra.peff.net","threadId":"47582","inReplyTo":"01020160df6dc499-0e6d11ec-1dcd-4a71-997b-ea231f33fae4-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-15T21:33:35Z","receivedAt":"2018-01-15T21:33:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n\n> Split expand_atom function into 2 different functions,\n> expand_atom_into_fields prepares variable for further filling,\n> (new) expand_atom creates resulting string.\n> Need that for further reusing of formatting logic from ref-filter.\n\nThis commit puzzled me, and I had to look ahead to try to figure out why\nwe want this split (because on its face, the split is bad, since it\nduplicates the list).\n\nLater, the preparation step goes away, but we still are left with\nexpand_atom(). That's because the preparation was all moved into\nref-filter.c, where we rely on populate_value() to fill in the values,\nand then we pick them out with our own formats.\n\nThat works, but I don't think it's where we want to end up in the long\nrun. Because:\n\n 1. We still have the set of formats duplicated between expand_atom()\n and the \"preparation\" step. It's just that the preparation is now\n in ref-filter.c. What happens if ref-filter.c learns new formatting\n placeholders (or options for those placeholders) that cat-file.c\n doesn't, or vice versa? The two have to be kept in sync.\n\n 2. We're missing out on all of the other placeholders that ref-filter\n knows about. Not all of them are meaningful (e.g., %(refname)\n wouldn't make sense here), but part of our goal is to support the\n same set of placeholders as much as possible. Some obvious ones\n that ought to work for cat-file: %(objectname:short), %(if), and\n things like %(subject) when the appropriate object type is used.\n\nIn other words, I think the endgame is that expand_atom() isn't there at\nall, and we're calling the equivalent of format_ref_item() for each\nobject (except that in a unified formatting world, it probably doesn't\nhave the word \"ref\" in it, since that's just one of the items a caller\nmight pass in).\n\n-Peff\n"},{"id":"336631","messageId":"20180115213702.GC4778@sigill.intra.peff.net","threadId":"47582","inReplyTo":"01020160df6dc51d-7cd5fb1a-9798-49c1-bc82-480108e1a90b-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH v2 02/18] cat-file: reuse struct ref_format","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-15T21:37:03Z","receivedAt":"2018-01-15T21:37:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n\n> Start using ref_format struct instead of simple char*.\n> Need that for further reusing of formatting logic from ref-filter.\n\nOK, this makes sense (though again, at some point we want this to stop\nbeing a \"ref_format\" and just be a \"format\").\n\n> struct batch_options {\n> +\tstruct ref_format *format;\n\nDoes this need to be a pointer? We can just store the ref_format inside\nthe struct, right? And then...\n\n> @@ -557,7 +558,8 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)\n> {\n> \tint opt = 0;\n> \tconst char *exp_type = NULL, *obj_name = NULL;\n> -\tstruct batch_options batch = {0};\n> +\tstruct ref_format format = REF_FORMAT_INIT;\n> +\tstruct batch_options batch = {&format};\n> \tint unknown_type = 0;\n\n...here you would not need the extra local variable. You can initialize\nit like:\n\n struct batch_options batch = { REF_FORMAT_INIT };\n\n-Peff\n"},{"id":"336632","messageId":"20180115214208.GD4778@sigill.intra.peff.net","threadId":"47582","inReplyTo":"01020160df6dc529-fae54bd6-e595-44fa-9f9a-c44cb3a5a1a8-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-15T21:42:08Z","receivedAt":"2018-01-15T21:42:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n\n> Make valid_atom as a function parameter,\n> there could be another variable further.\n> Need that for further reusing of formatting logic in cat-file.c.\n> \n> We do not need to allow users to pass their own valid_atom variable in\n> global functions like verify_ref_format because in the end we want to\n> have same set of valid atoms for all commands. But, as a first step\n> of migrating, I create further another version of valid_atom\n> for cat-file.\n\nI agree in the end we'd want a single valid_atom list. It doesn't look\nlike we hit that end state in this series, though.\n\nI guess I'm not quite clear on why we're not adding these new atoms to\nref-filter (and for-each-ref) right away, though. We already have the\nfirst three (name, type, and size), and we'd just need to support\n%(rest) and %(deltabase).\n\nI think %(rest) doesn't really make sense for for-each-ref (we're not\nreading any input), but it could expand to the empty string by default\n(or even throw an error if the caller asks us not to support it).\n\nIOW, the progression I'd expect in a series like this is:\n\n 1. Teach ref-filter.c to support everything that cat-file can do.\n\n 2. Convert cat-file to use ref-filter.c.\n\n-Peff\n"},{"id":"336634","messageId":"20180115214419.GE4778@sigill.intra.peff.net","threadId":"47582","inReplyTo":"01020160df6dc532-75f3ef78-26cb-4751-9ded-eb0e8d23833b-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH v2 04/18] cat-file: move struct expand_data into ref-filter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-15T21:44:19Z","receivedAt":"2018-01-15T21:44:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n\n> Need that for further reusing of formatting logic in cat-file.\n> Have plans to get rid of using expand_data in cat-file at all,\n> and use it only in ref-filter for collecting, formatting and printing\n> needed data.\n\nI think some of these will want to remain in cat-file.c. For instance,\nsplit_on_whitespace is not something that ref-filter.c itself would care\nabout. I'd expect in the endgame for cat-file to keep its own\nsplit_on_whitespace flag, and to set it based on the presence of the\n%(rest) flag, which it can check by seeing if the \"rest\" atom is in the\n\"used_atom\" list after parsing the format.\n\n-Peff\n"},{"id":"336635","messageId":"20180115220946.GF4778@sigill.intra.peff.net","threadId":"47582","inReplyTo":"20180115213335.GB4778@sigill.intra.peff.net","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-15T22:09:47Z","receivedAt":"2018-01-15T22:09:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 15, 2018 at 04:33:35PM -0500, Jeff King wrote:\n\n> That works, but I don't think it's where we want to end up in the long\n> run. Because:\n> \n> 1. We still have the set of formats duplicated between expand_atom()\n> and the \"preparation\" step. It's just that the preparation is now\n> in ref-filter.c. What happens if ref-filter.c learns new formatting\n> placeholders (or options for those placeholders) that cat-file.c\n> doesn't, or vice versa? The two have to be kept in sync.\n> \n> 2. We're missing out on all of the other placeholders that ref-filter\n> knows about. Not all of them are meaningful (e.g., %(refname)\n> wouldn't make sense here), but part of our goal is to support the\n> same set of placeholders as much as possible. Some obvious ones\n> that ought to work for cat-file: %(objectname:short), %(if), and\n> things like %(subject) when the appropriate object type is used.\n> \n> In other words, I think the endgame is that expand_atom() isn't there at\n> all, and we're calling the equivalent of format_ref_item() for each\n> object (except that in a unified formatting world, it probably doesn't\n> have the word \"ref\" in it, since that's just one of the items a caller\n> might pass in).\n\nI read carefully up through about patch 6, and then skimmed through the\nrest. I think we really want to push this in the direction of more\nunification, as above. I know that the patches here may be a step on the\nway, but I had a hard time evaluating each patch to see if it was\nleading us in the right direction.\n\nI think what would help for reviewing this is:\n\n 1. Start with a cover letter that makes it clear what the end state of\n the series is, and why that's the right place to end up.\n\n 2. Include a rough roadmap of the patches in the cover letter.\n Hopefully they should group into a few obvious steps (like \"in\n patches 1-5, we're teaching ref-filter to support everything that\n cat-file can do, then in 6-10 we're preparing cat-file for the\n conversion, and then in 11 we do the conversion\"). If it doesn't\n form a coherent narrative, then it may be worth stepping back and\n thinking about combining or reordering the patches in a different\n way, so that the progression becomes more plain.\n\n I think one of the things that makes the progression here hard to\n understand (for me, anyway) is that it's \"inside out\" of what I'd\n expect. There's a lot of code movement happening first, and then\n refactoring and simplifying after that. So between those two steps,\n there's a lot of interim ugliness (e.g., having to reach across\n module boundaries to look at expand_data). It's hard to tell when\n looking at each individual patch how necessary the ugliness is, and\n whether and when it's going to go away later in the series.\n\nThere's a lot of good work here, and you've figured out a lot about how\nthe two systems function. I think we just need to rearrange things a bit\nto make sure each step is moving in the right direction.\n\n-Peff\n"},{"id":"336644","messageId":"CAL21Bm=+uPrKECcCq2_rfJRuCpsOjZ41NfiyY3d1UA0b8YKj1w@mail.gmail.com","threadId":"47582","inReplyTo":"20180115214208.GD4778@sigill.intra.peff.net","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-16T06:55:22Z","receivedAt":"2018-01-16T06:55:30Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-16 0:42 GMT+03:00 Jeff King :\n> On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n>\n>> Make valid_atom as a function parameter,\n>> there could be another variable further.\n>> Need that for further reusing of formatting logic in cat-file.c.\n>>\n>> We do not need to allow users to pass their own valid_atom variable in\n>> global functions like verify_ref_format because in the end we want to\n>> have same set of valid atoms for all commands. But, as a first step\n>> of migrating, I create further another version of valid_atom\n>> for cat-file.\n>\n> I agree in the end we'd want a single valid_atom list. It doesn't look\n> like we hit that end state in this series, though.\n>\n> I guess I'm not quite clear on why we're not adding these new atoms to\n> ref-filter (and for-each-ref) right away, though. We already have the\n> first three (name, type, and size), and we'd just need to support\n> %(rest) and %(deltabase).\n>\n> I think %(rest) doesn't really make sense for for-each-ref (we're not\n> reading any input), but it could expand to the empty string by default\n> (or even throw an error if the caller asks us not to support it).\n>\n> IOW, the progression I'd expect in a series like this is:\n>\n> 1. Teach ref-filter.c to support everything that cat-file can do.\n>\n> 2. Convert cat-file to use ref-filter.c.\n>\n> -Peff\n\nI agree, I even made this and it's working fine:\nhttps://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\nBut I decided not to add that to patch because I expand the\nfunctionality of several commands (not only cat-file and\nfor-each-ref), and I need to support all new functionality in a proper\nway, make these error messages, test everything and - the hardest one\n- support many new commands for cat-file. As I understand, it is not\npossible unless we finally move to ref-filter and print results also\nthere. Oh, and I also need to rewrite docs in that case. And I decided\nto apply this in another patch. But, please, say your opinion, maybe\nwe could do that here in some way.\n\nOlga\n"},{"id":"336645","messageId":"CAL21Bmm0u4NgnPZMOh8PZqQ0is3inANKmCAr7MTaQHVyEOO7XQ@mail.gmail.com","threadId":"47582","inReplyTo":"20180115214419.GE4778@sigill.intra.peff.net","subject":"Re: [PATCH v2 04/18] cat-file: move struct expand_data into ref-filter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-16T07:00:42Z","receivedAt":"2018-01-16T07:00:51Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-16 0:44 GMT+03:00 Jeff King :\n> On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n>\n>> Need that for further reusing of formatting logic in cat-file.\n>> Have plans to get rid of using expand_data in cat-file at all,\n>> and use it only in ref-filter for collecting, formatting and printing\n>> needed data.\n>\n> I think some of these will want to remain in cat-file.c. For instance,\n> split_on_whitespace is not something that ref-filter.c itself would care\n> about. I'd expect in the endgame for cat-file to keep its own\n> split_on_whitespace flag, and to set it based on the presence of the\n> %(rest) flag, which it can check by seeing if the \"rest\" atom is in the\n> \"used_atom\" list after parsing the format.\n>\n> -Peff\n\nYes, maybe we will need to leave some part of expand_data variables.\nBut, if it would be only \"split_on_whitespace\", it's better to make\njust one flag without any other stuff. Actually, I thought about\nmoving related logic to ref-filter also. Anyway, it's hard to say\nexact things before we code everything. Do I need to fix commit\nmessage and make it more soft?\n\nOlga\n"},{"id":"336647","messageId":"CAL21BmmmX5-uisj+_=sDHwJO=fpXc41Wriw+uuxtR=gOio-HZQ@mail.gmail.com","threadId":"47582","inReplyTo":"20180115220946.GF4778@sigill.intra.peff.net","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-16T07:22:23Z","receivedAt":"2018-01-16T07:22:29Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-16 1:09 GMT+03:00 Jeff King :\n> On Mon, Jan 15, 2018 at 04:33:35PM -0500, Jeff King wrote:\n>\n>> That works, but I don't think it's where we want to end up in the long\n>> run.\n\nI absolutely agree, I want to merge current edits and then continue\nmigrating process. And hopefully second part of the function will also\nbe removed.\n\n>> Because:\n>>\n>> 1. We still have the set of formats duplicated between expand_atom()\n>> and the \"preparation\" step. It's just that the preparation is now\n>> in ref-filter.c. What happens if ref-filter.c learns new formatting\n>> placeholders (or options for those placeholders) that cat-file.c\n>> doesn't, or vice versa? The two have to be kept in sync.\n>>\n>> 2. We're missing out on all of the other placeholders that ref-filter\n>> knows about. Not all of them are meaningful (e.g., %(refname)\n>> wouldn't make sense here), but part of our goal is to support the\n>> same set of placeholders as much as possible. Some obvious ones\n>> that ought to work for cat-file: %(objectname:short), %(if), and\n>> things like %(subject) when the appropriate object type is used.\n>>\n>> In other words, I think the endgame is that expand_atom() isn't there at\n>> all, and we're calling the equivalent of format_ref_item() for each\n>> object (except that in a unified formatting world, it probably doesn't\n>> have the word \"ref\" in it, since that's just one of the items a caller\n>> might pass in).\n\nAgree! I want to merge current edits, then create format.h file and\nmake some renames, then finish migrating process to new format.h and\nsupport all new meaningful tags.\n\n>\n> I read carefully up through about patch 6, and then skimmed through the\n> rest. I think we really want to push this in the direction of more\n> unification, as above. I know that the patches here may be a step on the\n> way, but I had a hard time evaluating each patch to see if it was\n> leading us in the right direction.\n>\n> I think what would help for reviewing this is:\n>\n> 1. Start with a cover letter that makes it clear what the end state of\n> the series is, and why that's the right place to end up.\n>\n> 2. Include a rough roadmap of the patches in the cover letter.\n> Hopefully they should group into a few obvious steps (like \"in\n> patches 1-5, we're teaching ref-filter to support everything that\n> cat-file can do, then in 6-10 we're preparing cat-file for the\n> conversion, and then in 11 we do the conversion\"). If it doesn't\n> form a coherent narrative, then it may be worth stepping back and\n> thinking about combining or reordering the patches in a different\n> way, so that the progression becomes more plain.\n>\n> I think one of the things that makes the progression here hard to\n> understand (for me, anyway) is that it's \"inside out\" of what I'd\n> expect. There's a lot of code movement happening first, and then\n> refactoring and simplifying after that. So between those two steps,\n> there's a lot of interim ugliness (e.g., having to reach across\n> module boundaries to look at expand_data). It's hard to tell when\n> looking at each individual patch how necessary the ugliness is, and\n> whether and when it's going to go away later in the series.\n>\n> There's a lot of good work here, and you've figured out a lot about how\n> the two systems function. I think we just need to rearrange things a bit\n> to make sure each step is moving in the right direction.\n>\n> -Peff\n\nAs I said, I am sure that I will continue working on that, so this is\nnot the end state. So I am not sure that I am able to write finalizing\nmessages for now. But, if we merge current edits, it will be much\neasier for me to continue working on that (next patch would be about\ncreating format.h and I am afraid of some merge conflicts if I will\ndevelop absolutely all process from start to finish in my branch, it\ntakes time. It's not a big problem, but, if we find final goal\nworthwhile, so maybe we could go to it step-by-step).\n"},{"id":"336650","messageId":"CAL21Bm=WP3CN4OotC1pw3CY1anQALEcnnWMy6FJFaGwVJPARDg@mail.gmail.com","threadId":"47582","inReplyTo":"20180115213702.GC4778@sigill.intra.peff.net","subject":"Re: [PATCH v2 02/18] cat-file: reuse struct ref_format","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-16T09:45:23Z","receivedAt":"2018-01-16T09:45:28Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-16 0:37 GMT+03:00 Jeff King :\n> On Wed, Jan 10, 2018 at 09:36:41AM +0000, Olga Telezhnaya wrote:\n>\n>> Start using ref_format struct instead of simple char*.\n>> Need that for further reusing of formatting logic from ref-filter.\n>\n> OK, this makes sense (though again, at some point we want this to stop\n> being a \"ref_format\" and just be a \"format\").\n>\n>> struct batch_options {\n>> + struct ref_format *format;\n>\n> Does this need to be a pointer? We can just store the ref_format inside\n> the struct, right? And then...\n>\n>> @@ -557,7 +558,8 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)\n>> {\n>> int opt = 0;\n>> const char *exp_type = NULL, *obj_name = NULL;\n>> - struct batch_options batch = {0};\n>> + struct ref_format format = REF_FORMAT_INIT;\n>> + struct batch_options batch = {&format};\n>> int unknown_type = 0;\n>\n> ...here you would not need the extra local variable. You can initialize\n> it like:\n>\n> struct batch_options batch = { REF_FORMAT_INIT };\n>\n> -Peff\n\nThanks a lot!\nFixed, please check new version here: https://github.com/git/git/pull/450\nIf everything else is OK, I will send it to the mailing list.\nAs I said in other email threads, not sure that we need to include\nlast commit (\"make valid_atom general again\") into a new patch.\n\nThanks again,\nOlga\n"},{"id":"336724","messageId":"20180117214354.GA13128@sigill.intra.peff.net","threadId":"47582","inReplyTo":"CAL21Bm=+uPrKECcCq2_rfJRuCpsOjZ41NfiyY3d1UA0b8YKj1w@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-17T21:43:54Z","receivedAt":"2018-01-17T21:44:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 16, 2018 at 09:55:22AM +0300, Оля Тележная wrote:\n\n> > IOW, the progression I'd expect in a series like this is:\n> >\n> > 1. Teach ref-filter.c to support everything that cat-file can do.\n> >\n> > 2. Convert cat-file to use ref-filter.c.\n> \n> I agree, I even made this and it's working fine:\n> https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\n> But I decided not to add that to patch because I expand the\n> functionality of several commands (not only cat-file and\n> for-each-ref), and I need to support all new functionality in a proper\n> way, make these error messages, test everything and - the hardest one\n> - support many new commands for cat-file. As I understand, it is not\n> possible unless we finally move to ref-filter and print results also\n> there. Oh, and I also need to rewrite docs in that case. And I decided\n> to apply this in another patch. But, please, say your opinion, maybe\n> we could do that here in some way.\n\nYeah, I agree that it will cause changes to other users of ref-filter,\nand you'd need to deal with documentation and tests there. But I think\nwe're going to have to do those things eventually (since supporting\nthose extra fields everywhere is part of the point of the project). And\nby doing them now, I think it can make the transition for cat-file a lot\nsimpler, because we never have to puzzle over this intermediate state\nwhere only some of the atoms are valid for cat-file.\n\nI also agree that moving cat-file's printing over to ref-filter.c is\ngoing to introduce a lot of corner cases (like the behavior when\nsomebody does \"cat-file --batch-check=%(refname)\" with a bare sha1). But\nI think a progression of patches handling those cases would be pretty\neasy to follow. E.g., I'd expect to see a patch that teaches\nref-filter[1] how to handle callers that don't have a ref, but just a\nbare object name. And it would be easier to evaluate that on its own,\nbecause we know that's an end state we're going to have to handle, and\nnot some funny state created as part of the transition.\n\n-Peff\n\n[1] And here's where we might start to think about calling it something\n besides ref-filter, if we don't necessarily have a ref. :)\n"},{"id":"336727","messageId":"20180117214515.GB13128@sigill.intra.peff.net","threadId":"47582","inReplyTo":"CAL21Bmm0u4NgnPZMOh8PZqQ0is3inANKmCAr7MTaQHVyEOO7XQ@mail.gmail.com","subject":"Re: [PATCH v2 04/18] cat-file: move struct expand_data into ref-filter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-17T21:45:16Z","receivedAt":"2018-01-17T21:45:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 16, 2018 at 10:00:42AM +0300, Оля Тележная wrote:\n\n> > I think some of these will want to remain in cat-file.c. For instance,\n> > split_on_whitespace is not something that ref-filter.c itself would care\n> > about. I'd expect in the endgame for cat-file to keep its own\n> > split_on_whitespace flag, and to set it based on the presence of the\n> > %(rest) flag, which it can check by seeing if the \"rest\" atom is in the\n> > \"used_atom\" list after parsing the format.\n> \n> Yes, maybe we will need to leave some part of expand_data variables.\n> But, if it would be only \"split_on_whitespace\", it's better to make\n> just one flag without any other stuff. Actually, I thought about\n> moving related logic to ref-filter also. Anyway, it's hard to say\n> exact things before we code everything. Do I need to fix commit\n> message and make it more soft?\n\nYeah, I think it might just be split_on_whitespace, and that could live\non as a single variable in cat-file.c.\n\nI don't think it makes sense to move that part to ref-filter, since it's\nnot about formatting at all. It's about how cat-file parses its input,\nwhich is going to be unlike other ref-filter users (which don't\ngenerally parse input at all).\n\n-Peff\n"},{"id":"336728","messageId":"20180117214906.GC13128@sigill.intra.peff.net","threadId":"47582","inReplyTo":"CAL21BmmmX5-uisj+_=sDHwJO=fpXc41Wriw+uuxtR=gOio-HZQ@mail.gmail.com","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-17T21:49:06Z","receivedAt":"2018-01-17T21:49:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 16, 2018 at 10:22:23AM +0300, Оля Тележная wrote:\n\n> >> In other words, I think the endgame is that expand_atom() isn't there at\n> >> all, and we're calling the equivalent of format_ref_item() for each\n> >> object (except that in a unified formatting world, it probably doesn't\n> >> have the word \"ref\" in it, since that's just one of the items a caller\n> >> might pass in).\n> \n> Agree! I want to merge current edits, then create format.h file and\n> make some renames, then finish migrating process to new format.h and\n> support all new meaningful tags.\n\nI think we have a little bit of chicken and egg there, though. I'm\nhaving trouble reviewing the current work, because it's hard to evaluate\nwhether it's doing the right thing without seeing the end state. So what\nI was suggesting in my earlier mails was that we actually _not_ try to\nmerge this series, but use its components and ideas to build a new\nseries that does things in a bit different order.\n\nSome of the patches here would end up thrown out, and some would get\ncherry-picked into the new series. And some would have some conflicts\nand need to get parts rewritten to fit into the new order.\n\n-Peff\n"},{"id":"336737","messageId":"CAP8UFD0PtOqX5c4ovRbYDWejQ55iUwtnPv-zGXS2GFAajhXqtA@mail.gmail.com","threadId":"47582","inReplyTo":"20180117214354.GA13128@sigill.intra.peff.net","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-17T22:39:18Z","receivedAt":"2018-01-17T22:39:24Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Jan 17, 2018 at 10:43 PM, Jeff King wrote:\n> On Tue, Jan 16, 2018 at 09:55:22AM +0300, Оля Тележная wrote:\n>\n>> > IOW, the progression I'd expect in a series like this is:\n>> >\n>> > 1. Teach ref-filter.c to support everything that cat-file can do.\n>> >\n>> > 2. Convert cat-file to use ref-filter.c.\n>>\n>> I agree, I even made this and it's working fine:\n>> https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\n\n(Nit: it looks like the above link does not work any more, but it\nseems that you are talking about the last patch on the catfile\nbranch.)\n\n>> But I decided not to add that to patch because I expand the\n>> functionality of several commands (not only cat-file and\n>> for-each-ref), and I need to support all new functionality in a proper\n>> way, make these error messages, test everything and - the hardest one\n>> - support many new commands for cat-file. As I understand, it is not\n>> possible unless we finally move to ref-filter and print results also\n>> there. Oh, and I also need to rewrite docs in that case. And I decided\n>> to apply this in another patch. But, please, say your opinion, maybe\n>> we could do that here in some way.\n>\n> Yeah, I agree that it will cause changes to other users of ref-filter,\n> and you'd need to deal with documentation and tests there. But I think\n> we're going to have to do those things eventually (since supporting\n> those extra fields everywhere is part of the point of the project). And\n> by doing them now, I think it can make the transition for cat-file a lot\n> simpler, because we never have to puzzle over this intermediate state\n> where only some of the atoms are valid for cat-file.\n\nI agree that you will have to deal with documentation and tests at one\npoint and that it could be a good idea to do that now.\n\nI wonder if it is possible to add atoms one by one into ref-filter and\nto add tests and documentation at the same time, instead of merging\ncat-file atoms with ref-filter atoms in one big step.\n\nWhen all the cat-file atoms have been added to ref-filter's\nvalid_atom, maybe you could add ref-filter's atoms to cat-file's\nvalid_cat_file_atom one by one and add tests and documentation at the\nsame time.\n\nAnd then when ref-filter's valid_atom and cat-file's\nvalid_cat_file_atom are identical you can remove cat-file's\nvalid_cat_file_atom and maybe after that rename \"ref-filter\" to\n\"format\".\n"},{"id":"336739","messageId":"CAP8UFD1hnP3yab-qDKPkNcj5VadUD_HW5+V1e2nwPAB8r31zoQ@mail.gmail.com","threadId":"47582","inReplyTo":"20180117214906.GC13128@sigill.intra.peff.net","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-17T23:04:09Z","receivedAt":"2018-01-17T23:04:17Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Jan 17, 2018 at 10:49 PM, Jeff King wrote:\n> On Tue, Jan 16, 2018 at 10:22:23AM +0300, Оля Тележная wrote:\n>\n>> >> In other words, I think the endgame is that expand_atom() isn't there at\n>> >> all, and we're calling the equivalent of format_ref_item() for each\n>> >> object (except that in a unified formatting world, it probably doesn't\n>> >> have the word \"ref\" in it, since that's just one of the items a caller\n>> >> might pass in).\n>>\n>> Agree! I want to merge current edits, then create format.h file and\n>> make some renames, then finish migrating process to new format.h and\n>> support all new meaningful tags.\n>\n> I think we have a little bit of chicken and egg there, though. I'm\n> having trouble reviewing the current work, because it's hard to evaluate\n> whether it's doing the right thing without seeing the end state.\n\nYeah, to me it feels like you are at a middle point and there are many\nways to go forward.\n\nAs I wrote in another email though, I think it might be a good time to\nconsolidate new functionality by adding tests (and perhaps\ndocumentation at the same time) for each new atom that is added to\nref-filter or cat-file. It will help you refactor the code and your\npatch series later without breaking the new functionality.\n\n> So what\n> I was suggesting in my earlier mails was that we actually _not_ try to\n> merge this series, but use its components and ideas to build a new\n> series that does things in a bit different order.\n\nYeah, I think you will have to do that, but the tests that you can add\nnow for the new features will help you when you will build the new\nseries.\n\nAnd hopefully it will not be too much work to create this new series\nas you will perhaps be able to just use the interactive rebase to\nbuild it.\n\nI also don't think it's a big problem if the current patch series gets\nquite long before you start creating a new series.\n"},{"id":"336748","messageId":"CAL21BmmZ1aPFS-=ctXH3p40o6CAQR3hWS6AXRB8061kE4h22uA@mail.gmail.com","threadId":"47582","inReplyTo":"20180117214515.GB13128@sigill.intra.peff.net","subject":"Re: [PATCH v2 04/18] cat-file: move struct expand_data into ref-filter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-18T05:56:43Z","receivedAt":"2018-01-18T05:56:49Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-18 0:45 GMT+03:00 Jeff King :\n> On Tue, Jan 16, 2018 at 10:00:42AM +0300, Оля Тележная wrote:\n>\n>> > I think some of these will want to remain in cat-file.c. For instance,\n>> > split_on_whitespace is not something that ref-filter.c itself would care\n>> > about. I'd expect in the endgame for cat-file to keep its own\n>> > split_on_whitespace flag, and to set it based on the presence of the\n>> > %(rest) flag, which it can check by seeing if the \"rest\" atom is in the\n>> > \"used_atom\" list after parsing the format.\n>>\n>> Yes, maybe we will need to leave some part of expand_data variables.\n>> But, if it would be only \"split_on_whitespace\", it's better to make\n>> just one flag without any other stuff. Actually, I thought about\n>> moving related logic to ref-filter also. Anyway, it's hard to say\n>> exact things before we code everything. Do I need to fix commit\n>> message and make it more soft?\n>\n> Yeah, I think it might just be split_on_whitespace, and that could live\n> on as a single variable in cat-file.c.\n>\n> I don't think it makes sense to move that part to ref-filter, since it's\n> not about formatting at all. It's about how cat-file parses its input,\n> which is going to be unlike other ref-filter users (which don't\n> generally parse input at all).\n>\n> -Peff\n\nOK, I will leave split_on_whitespace in cat-file for now. :) There are\nso many places that are more important now, in my opinion, so I am\nplanning just to leave this variable and do other stuff, and I will\nreturn to this question later.\n"},{"id":"336750","messageId":"CAL21BmnKd0qamJWJbrAzg_ZX1GkhCTPO_5zOiFNMBeF-xjDTiQ@mail.gmail.com","threadId":"47582","inReplyTo":"CAP8UFD0PtOqX5c4ovRbYDWejQ55iUwtnPv-zGXS2GFAajhXqtA@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-18T06:20:14Z","receivedAt":"2018-01-18T06:20:21Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-18 1:39 GMT+03:00 Christian Couder :\n> On Wed, Jan 17, 2018 at 10:43 PM, Jeff King wrote:\n>> On Tue, Jan 16, 2018 at 09:55:22AM +0300, Оля Тележная wrote:\n>>\n>>> > IOW, the progression I'd expect in a series like this is:\n>>> >\n>>> > 1. Teach ref-filter.c to support everything that cat-file can do.\n>>> >\n>>> > 2. Convert cat-file to use ref-filter.c.\n>>>\n>>> I agree, I even made this and it's working fine:\n>>> https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\n>\n> (Nit: it looks like the above link does not work any more, but it\n> seems that you are talking about the last patch on the catfile\n> branch.)\n>\n>>> But I decided not to add that to patch because I expand the\n>>> functionality of several commands (not only cat-file and\n>>> for-each-ref), and I need to support all new functionality in a proper\n>>> way, make these error messages, test everything and - the hardest one\n>>> - support many new commands for cat-file. As I understand, it is not\n>>> possible unless we finally move to ref-filter and print results also\n>>> there. Oh, and I also need to rewrite docs in that case. And I decided\n>>> to apply this in another patch. But, please, say your opinion, maybe\n>>> we could do that here in some way.\n>>\n>> Yeah, I agree that it will cause changes to other users of ref-filter,\n>> and you'd need to deal with documentation and tests there. But I think\n>> we're going to have to do those things eventually (since supporting\n>> those extra fields everywhere is part of the point of the project). And\n>> by doing them now, I think it can make the transition for cat-file a lot\n>> simpler, because we never have to puzzle over this intermediate state\n>> where only some of the atoms are valid for cat-file.\n>\n> I agree that you will have to deal with documentation and tests at one\n> point and that it could be a good idea to do that now.\n>\n> I wonder if it is possible to add atoms one by one into ref-filter and\n> to add tests and documentation at the same time, instead of merging\n> cat-file atoms with ref-filter atoms in one big step.\n>\n> When all the cat-file atoms have been added to ref-filter's\n> valid_atom, maybe you could add ref-filter's atoms to cat-file's\n> valid_cat_file_atom one by one and add tests and documentation at the\n> same time.\n>\n> And then when ref-filter's valid_atom and cat-file's\n> valid_cat_file_atom are identical you can remove cat-file's\n> valid_cat_file_atom and maybe after that rename \"ref-filter\" to\n> \"format\".\n\nI think it's important to finish migrating process at first. I mean,\nnow we are preparing and collecting everything in ref-filter, but we\nmake resulting string and print still in cat-file. And I am not sure,\nbut maybe it will not be possible to start using new atoms in cat-file\nwhile some part of logic still differs.\nAnd another thoughts here - we were thinking about creating format.h\nbut decided not to move forward with it, and now we are suffering\nbecause of it. Can I create it right now or the history of commits\nwould be too dirty because of it? Also, do you mean just renaming of\nref-filter? I was thinking that I need to put formatting-related logic\nto another file and leave all other stuff in ref-filter.\n\nAnyway, your suggested steps looks good, and I am planning to\nimplement them later. Let's discuss, what behavior we are waiting for\nwhen atom seems useless for the command. Die or ignore? And, which\natoms are useless (as I understand, \"rest\" and \"deltabase\" from\ncat-file are useless for all ref-filter users, so the question is\nabout - am I right in it, and about ref-filter atoms for cat-file).\n\nI have never written any tests and docs for Git, I will try to explore\nby myself how to do that, but if you have any special links/materials\nabout it - please send them to me :)\n\nOlga\n"},{"id":"336751","messageId":"CAL21Bmm9P7p90GRRk4y9N5R6Gd3prEx53KyD3Cu1si6FHZAvkQ@mail.gmail.com","threadId":"47582","inReplyTo":"CAP8UFD1hnP3yab-qDKPkNcj5VadUD_HW5+V1e2nwPAB8r31zoQ@mail.gmail.com","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-18T06:22:57Z","receivedAt":"2018-01-18T06:23:03Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-18 2:04 GMT+03:00 Christian Couder :\n> On Wed, Jan 17, 2018 at 10:49 PM, Jeff King wrote:\n>> On Tue, Jan 16, 2018 at 10:22:23AM +0300, Оля Тележная wrote:\n>>\n>>> >> In other words, I think the endgame is that expand_atom() isn't there at\n>>> >> all, and we're calling the equivalent of format_ref_item() for each\n>>> >> object (except that in a unified formatting world, it probably doesn't\n>>> >> have the word \"ref\" in it, since that's just one of the items a caller\n>>> >> might pass in).\n>>>\n>>> Agree! I want to merge current edits, then create format.h file and\n>>> make some renames, then finish migrating process to new format.h and\n>>> support all new meaningful tags.\n>>\n>> I think we have a little bit of chicken and egg there, though. I'm\n>> having trouble reviewing the current work, because it's hard to evaluate\n>> whether it's doing the right thing without seeing the end state.\n>\n> Yeah, to me it feels like you are at a middle point and there are many\n> ways to go forward.\n\nOK. Maybe I misunderstood you and Jeff in our call, I thought that was\nyour idea to make a merge now, sorry. I will continue my work here.\n\n>\n> As I wrote in another email though, I think it might be a good time to\n> consolidate new functionality by adding tests (and perhaps\n> documentation at the same time) for each new atom that is added to\n> ref-filter or cat-file. It will help you refactor the code and your\n> patch series later without breaking the new functionality.\n>\n>> So what\n>> I was suggesting in my earlier mails was that we actually _not_ try to\n>> merge this series, but use its components and ideas to build a new\n>> series that does things in a bit different order.\n>\n> Yeah, I think you will have to do that, but the tests that you can add\n> now for the new features will help you when you will build the new\n> series.\n>\n> And hopefully it will not be too much work to create this new series\n> as you will perhaps be able to just use the interactive rebase to\n> build it.\n>\n> I also don't think it's a big problem if the current patch series gets\n> quite long before you start creating a new series.\n"},{"id":"336752","messageId":"CAP8UFD00caGRWZZ1jdmuwtBH92tbqHoebfT+Lkp1NctKrxwFAQ@mail.gmail.com","threadId":"47582","inReplyTo":"CAL21Bmm9P7p90GRRk4y9N5R6Gd3prEx53KyD3Cu1si6FHZAvkQ@mail.gmail.com","subject":"Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-18T08:45:06Z","receivedAt":"2018-01-18T08:45:33Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jan 18, 2018 at 7:22 AM, Оля Тележная wrote:\n> 2018-01-18 2:04 GMT+03:00 Christian Couder :\n>> On Wed, Jan 17, 2018 at 10:49 PM, Jeff King wrote:\n>>> On Tue, Jan 16, 2018 at 10:22:23AM +0300, Оля Тележная wrote:\n>>>\n>>>> >> In other words, I think the endgame is that expand_atom() isn't there at\n>>>> >> all, and we're calling the equivalent of format_ref_item() for each\n>>>> >> object (except that in a unified formatting world, it probably doesn't\n>>>> >> have the word \"ref\" in it, since that's just one of the items a caller\n>>>> >> might pass in).\n>>>>\n>>>> Agree! I want to merge current edits, then create format.h file and\n>>>> make some renames, then finish migrating process to new format.h and\n>>>> support all new meaningful tags.\n>>>\n>>> I think we have a little bit of chicken and egg there, though. I'm\n>>> having trouble reviewing the current work, because it's hard to evaluate\n>>> whether it's doing the right thing without seeing the end state.\n>>\n>> Yeah, to me it feels like you are at a middle point and there are many\n>> ways to go forward.\n>\n> OK. Maybe I misunderstood you and Jeff in our call, I thought that was\n> your idea to make a merge now, sorry. I will continue my work here.\n\nIf you think you can now prepare a patch series that looks like it is\ngoing in the right direction, then yes you can do that. But after\nlooking at the current patch series I agree with Peff that, as it\ndoesn't look finished, it's difficult to tell if all the steps are\ngood.\n\nIn general it is a good idea to try to merge things as soon possible,\nbut for that to be possible the state of the code that we want to be\nmerged should look quite stable, and it doesn't look very stable to\nme.\n"},{"id":"336770","messageId":"CAL21BmneJ4rgCtf8t8LOK=gVv0MR+xam9jFBp7kp33rqEG7f6Q@mail.gmail.com","threadId":"47582","inReplyTo":"CAL21BmnKd0qamJWJbrAzg_ZX1GkhCTPO_5zOiFNMBeF-xjDTiQ@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-18T11:49:28Z","receivedAt":"2018-01-18T11:49:37Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-18 9:20 GMT+03:00 Оля Тележная :\n> 2018-01-18 1:39 GMT+03:00 Christian Couder :\n>> On Wed, Jan 17, 2018 at 10:43 PM, Jeff King wrote:\n>>> On Tue, Jan 16, 2018 at 09:55:22AM +0300, Оля Тележная wrote:\n>>>\n>>>> > IOW, the progression I'd expect in a series like this is:\n>>>> >\n>>>> > 1. Teach ref-filter.c to support everything that cat-file can do.\n>>>> >\n>>>> > 2. Convert cat-file to use ref-filter.c.\n>>>>\n>>>> I agree, I even made this and it's working fine:\n>>>> https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\n>>\n>> (Nit: it looks like the above link does not work any more, but it\n>> seems that you are talking about the last patch on the catfile\n>> branch.)\n>>\n>>>> But I decided not to add that to patch because I expand the\n>>>> functionality of several commands (not only cat-file and\n>>>> for-each-ref), and I need to support all new functionality in a proper\n>>>> way, make these error messages, test everything and - the hardest one\n>>>> - support many new commands for cat-file. As I understand, it is not\n>>>> possible unless we finally move to ref-filter and print results also\n>>>> there. Oh, and I also need to rewrite docs in that case. And I decided\n>>>> to apply this in another patch. But, please, say your opinion, maybe\n>>>> we could do that here in some way.\n>>>\n>>> Yeah, I agree that it will cause changes to other users of ref-filter,\n>>> and you'd need to deal with documentation and tests there. But I think\n>>> we're going to have to do those things eventually (since supporting\n>>> those extra fields everywhere is part of the point of the project). And\n>>> by doing them now, I think it can make the transition for cat-file a lot\n>>> simpler, because we never have to puzzle over this intermediate state\n>>> where only some of the atoms are valid for cat-file.\n>>\n>> I agree that you will have to deal with documentation and tests at one\n>> point and that it could be a good idea to do that now.\n>>\n>> I wonder if it is possible to add atoms one by one into ref-filter and\n>> to add tests and documentation at the same time, instead of merging\n>> cat-file atoms with ref-filter atoms in one big step.\n>>\n>> When all the cat-file atoms have been added to ref-filter's\n>> valid_atom, maybe you could add ref-filter's atoms to cat-file's\n>> valid_cat_file_atom one by one and add tests and documentation at the\n>> same time.\n>>\n>> And then when ref-filter's valid_atom and cat-file's\n>> valid_cat_file_atom are identical you can remove cat-file's\n>> valid_cat_file_atom and maybe after that rename \"ref-filter\" to\n>> \"format\".\n>\n> I think it's important to finish migrating process at first. I mean,\n> now we are preparing and collecting everything in ref-filter, but we\n> make resulting string and print still in cat-file. And I am not sure,\n> but maybe it will not be possible to start using new atoms in cat-file\n> while some part of logic still differs.\n\nI tried to make that part here:\nhttps://github.com/telezhnaya/git/commit/19a148614f1d4db1f8e628eb4e6d7c819d2da875\nI know that the code is disgusting and there is a memory leak :) I\njust try to reuse ref-filter logic, I will cleanup everything later.\nAt first, I try to make it work.\nThe problem is that I have segfault, and if I use gdb, I get:\n\nProgram received signal SIGSEGV, Segmentation fault.\n0x0000000000000000 in ?? ()\n\nI tried to google it, it's my first time when I get that strange\nmessage, and unfortunately find nothing. So please explain me the\nreason, why I can't find a place of segfault that way.\nThanks!\n\n> And another thoughts here - we were thinking about creating format.h\n> but decided not to move forward with it, and now we are suffering\n> because of it. Can I create it right now or the history of commits\n> would be too dirty because of it? Also, do you mean just renaming of\n> ref-filter? I was thinking that I need to put formatting-related logic\n> to another file and leave all other stuff in ref-filter.\n\nBy the way, I can create format.h in absolutely another branch, we\ncould merge it, and I will deal with all merge conflicts with my\ncurrent work. It sounds tediously, but actually it's not such a big\nproblem, I can do that.\nBut I still need to fully understand, what do you find more proper -\njust rename ref-filter, or create new file and move formatting-related\nlogic.\n\n>\n> Anyway, your suggested steps looks good, and I am planning to\n> implement them later. Let's discuss, what behavior we are waiting for\n> when atom seems useless for the command. Die or ignore? And, which\n> atoms are useless (as I understand, \"rest\" and \"deltabase\" from\n> cat-file are useless for all ref-filter users, so the question is\n> about - am I right in it, and about ref-filter atoms for cat-file).\n>\n> I have never written any tests and docs for Git, I will try to explore\n> by myself how to do that, but if you have any special links/materials\n> about it - please send them to me :)\n>\n> Olga\n"},{"id":"336777","messageId":"CAP8UFD1qPTh_VX8ebazxoeEHRfNjmNwy-baat9Y+GVHrHWQqFA@mail.gmail.com","threadId":"47582","inReplyTo":"CAL21BmneJ4rgCtf8t8LOK=gVv0MR+xam9jFBp7kp33rqEG7f6Q@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-18T14:23:39Z","receivedAt":"2018-01-18T14:23:48Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jan 18, 2018 at 12:49 PM, Оля Тележная wrote:\n> 2018-01-18 9:20 GMT+03:00 Оля Тележная :\n>>\n>> I think it's important to finish migrating process at first. I mean,\n>> now we are preparing and collecting everything in ref-filter, but we\n>> make resulting string and print still in cat-file. And I am not sure,\n>> but maybe it will not be possible to start using new atoms in cat-file\n>> while some part of logic still differs.\n>\n> I tried to make that part here:\n> https://github.com/telezhnaya/git/commit/19a148614f1d4db1f8e628eb4e6d7c819d2da875\n> I know that the code is disgusting and there is a memory leak :) I\n> just try to reuse ref-filter logic, I will cleanup everything later.\n> At first, I try to make it work.\n> The problem is that I have segfault, and if I use gdb, I get:\n>\n> Program received signal SIGSEGV, Segmentation fault.\n> 0x0000000000000000 in ?? ()\n\nMake sure that you compile with debug options like -g3. For example I use:\n\n$ make -j 4 DEVELOPER=1 CFLAGS=\"-g3\"\n\n> I tried to google it, it's my first time when I get that strange\n> message, and unfortunately find nothing. So please explain me the\n> reason, why I can't find a place of segfault that way.\n\nI get the following:\n\n(gdb) run cat-file --batch < myarg.txt\nStarting program: /home/ubuntu/bin/git cat-file --batch < myarg.txt\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n\nProgram received signal SIGSEGV, Segmentation fault.\n0x00005555556ea7cf in format_ref_array_item (info=0x7fffffffd460,\nformat=0x7fffffffd6e0,\n final_buf=0x7fffffffd410) at ref-filter.c:2234\n2234 atomv->handler(atomv, &state);\n(gdb) bt\n#0 0x00005555556ea7cf in format_ref_array_item (info=0x7fffffffd460,\n format=0x7fffffffd6e0, final_buf=0x7fffffffd410) at ref-filter.c:2234\n#1 0x00005555556ea91c in show_ref_array_item (info=0x7fffffffd460,\nformat=0x7fffffffd6e0)\n at ref-filter.c:2256\n#2 0x0000555555577ef7 in batch_object_write (\n obj_name=0x555555a66770 \"5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689\",\n opt=0x7fffffffd6e0, data=0x7fffffffd5e0) at builtin/cat-file.c:298\n"},{"id":"336887","messageId":"CAL21Bmnv24tc7H5w4Nm=TfYjVEYB=ykZ3iv_0JtUMODCKCwQzw@mail.gmail.com","threadId":"47582","inReplyTo":"CAP8UFD1qPTh_VX8ebazxoeEHRfNjmNwy-baat9Y+GVHrHWQqFA@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-19T12:24:50Z","receivedAt":"2018-01-19T12:28:23Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-18 17:23 GMT+03:00 Christian Couder :\n> On Thu, Jan 18, 2018 at 12:49 PM, Оля Тележная wrote:\n>> 2018-01-18 9:20 GMT+03:00 Оля Тележная :\n>>>\n>>> I think it's important to finish migrating process at first. I mean,\n>>> now we are preparing and collecting everything in ref-filter, but we\n>>> make resulting string and print still in cat-file. And I am not sure,\n>>> but maybe it will not be possible to start using new atoms in cat-file\n>>> while some part of logic still differs.\n>>\n>> I tried to make that part here:\n>> https://github.com/telezhnaya/git/commit/19a148614f1d4db1f8e628eb4e6d7c819d2da875\n>> I know that the code is disgusting and there is a memory leak :) I\n>> just try to reuse ref-filter logic, I will cleanup everything later.\n>> At first, I try to make it work.\n>> The problem is that I have segfault, and if I use gdb, I get:\n>>\n>> Program received signal SIGSEGV, Segmentation fault.\n>> 0x0000000000000000 in ?? ()\n>\n> Make sure that you compile with debug options like -g3. For example I use:\n>\n> $ make -j 4 DEVELOPER=1 CFLAGS=\"-g3\"\n\nIs it OK that I get different test results with simple make and with\nmake with all that flags?\nHave a code: https://github.com/telezhnaya/git/commits/catfile\nI do:\n\nolya@ubuntu17-vm:~/git$ make install\nolya@ubuntu17-vm:~/git$ cd t\nolya@ubuntu17-vm:~/git/t$ ./t1006-cat-file.sh\n\nAnd I have 17 tests broken.\nThen, without any changes in code, I do:\n\nolya@ubuntu17-vm:~/git$ make -j 4 DEVELOPER=1 CFLAGS=\"-g3\" install\nolya@ubuntu17-vm:~/git$ cd t\nolya@ubuntu17-vm:~/git/t$ ./t1006-cat-file.sh\n\nAnd there is 42 tests broken.\nAnd it's really hard to search for errors in such situation.\n\n>\n>> I tried to google it, it's my first time when I get that strange\n>> message, and unfortunately find nothing. So please explain me the\n>> reason, why I can't find a place of segfault that way.\n>\n> I get the following:\n>\n> (gdb) run cat-file --batch < myarg.txt\n> Starting program: /home/ubuntu/bin/git cat-file --batch < myarg.txt\n> [Thread debugging using libthread_db enabled]\n> Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n>\n> Program received signal SIGSEGV, Segmentation fault.\n> 0x00005555556ea7cf in format_ref_array_item (info=0x7fffffffd460,\n> format=0x7fffffffd6e0,\n> final_buf=0x7fffffffd410) at ref-filter.c:2234\n> 2234 atomv->handler(atomv, &state);\n> (gdb) bt\n> #0 0x00005555556ea7cf in format_ref_array_item (info=0x7fffffffd460,\n> format=0x7fffffffd6e0, final_buf=0x7fffffffd410) at ref-filter.c:2234\n> #1 0x00005555556ea91c in show_ref_array_item (info=0x7fffffffd460,\n> format=0x7fffffffd6e0)\n> at ref-filter.c:2256\n> #2 0x0000555555577ef7 in batch_object_write (\n> obj_name=0x555555a66770 \"5e1c309dae7f45e0f39b1bf3ac3cd9db12e7d689\",\n> opt=0x7fffffffd6e0, data=0x7fffffffd5e0) at builtin/cat-file.c:298\n"},{"id":"336895","messageId":"CAP8UFD21JcERHDZz_TVX9nuw+vfE=ra19hC50fRKdMxL_5bxOg@mail.gmail.com","threadId":"47582","inReplyTo":"CAL21Bmnv24tc7H5w4Nm=TfYjVEYB=ykZ3iv_0JtUMODCKCwQzw@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-19T15:48:58Z","receivedAt":"2018-01-19T15:49:16Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jan 19, 2018 at 1:24 PM, Оля Тележная wrote:\n> 2018-01-18 17:23 GMT+03:00 Christian Couder :\n>> On Thu, Jan 18, 2018 at 12:49 PM, Оля Тележная wrote:\n>>> 2018-01-18 9:20 GMT+03:00 Оля Тележная :\n>>>>\n>>>> I think it's important to finish migrating process at first. I mean,\n>>>> now we are preparing and collecting everything in ref-filter, but we\n>>>> make resulting string and print still in cat-file. And I am not sure,\n>>>> but maybe it will not be possible to start using new atoms in cat-file\n>>>> while some part of logic still differs.\n>>>\n>>> I tried to make that part here:\n>>> https://github.com/telezhnaya/git/commit/19a148614f1d4db1f8e628eb4e6d7c819d2da875\n>>> I know that the code is disgusting and there is a memory leak :) I\n>>> just try to reuse ref-filter logic, I will cleanup everything later.\n>>> At first, I try to make it work.\n>>> The problem is that I have segfault, and if I use gdb, I get:\n>>>\n>>> Program received signal SIGSEGV, Segmentation fault.\n>>> 0x0000000000000000 in ?? ()\n>>\n>> Make sure that you compile with debug options like -g3. For example I use:\n>>\n>> $ make -j 4 DEVELOPER=1 CFLAGS=\"-g3\"\n>\n> Is it OK that I get different test results with simple make and with\n> make with all that flags?\n> Have a code: https://github.com/telezhnaya/git/commits/catfile\n> I do:\n>\n> olya@ubuntu17-vm:~/git$ make install\n> olya@ubuntu17-vm:~/git$ cd t\n> olya@ubuntu17-vm:~/git/t$ ./t1006-cat-file.sh\n>\n> And I have 17 tests broken.\n> Then, without any changes in code, I do:\n>\n> olya@ubuntu17-vm:~/git$ make -j 4 DEVELOPER=1 CFLAGS=\"-g3\" install\n> olya@ubuntu17-vm:~/git$ cd t\n> olya@ubuntu17-vm:~/git/t$ ./t1006-cat-file.sh\n>\n> And there is 42 tests broken.\n> And it's really hard to search for errors in such situation.\n\nSome segfaults and other memory issues might happen or not happen\ndepending on how the code has been compiled. I think that if you fix\nall the memory related issues, the behavior should be the same.\n"},{"id":"336897","messageId":"CAP8UFD1dcwEA9z+oQKFV=aFoKn73mtP4qkLGovW2XTu6N=N4dA@mail.gmail.com","threadId":"47582","inReplyTo":"CAL21BmnKd0qamJWJbrAzg_ZX1GkhCTPO_5zOiFNMBeF-xjDTiQ@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-19T17:14:56Z","receivedAt":"2018-01-19T17:15:06Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jan 18, 2018 at 7:20 AM, Оля Тележная wrote:\n> 2018-01-18 1:39 GMT+03:00 Christian Couder :\n>> On Wed, Jan 17, 2018 at 10:43 PM, Jeff King wrote:\n>>> On Tue, Jan 16, 2018 at 09:55:22AM +0300, Оля Тележная wrote:\n>>>\n>>>> > IOW, the progression I'd expect in a series like this is:\n>>>> >\n>>>> > 1. Teach ref-filter.c to support everything that cat-file can do.\n>>>> >\n>>>> > 2. Convert cat-file to use ref-filter.c.\n>>>>\n>>>> I agree, I even made this and it's working fine:\n>>>> https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\n>>\n>> (Nit: it looks like the above link does not work any more, but it\n>> seems that you are talking about the last patch on the catfile\n>> branch.)\n>>\n>>>> But I decided not to add that to patch because I expand the\n>>>> functionality of several commands (not only cat-file and\n>>>> for-each-ref), and I need to support all new functionality in a proper\n>>>> way, make these error messages, test everything and - the hardest one\n>>>> - support many new commands for cat-file. As I understand, it is not\n>>>> possible unless we finally move to ref-filter and print results also\n>>>> there. Oh, and I also need to rewrite docs in that case. And I decided\n>>>> to apply this in another patch. But, please, say your opinion, maybe\n>>>> we could do that here in some way.\n>>>\n>>> Yeah, I agree that it will cause changes to other users of ref-filter,\n>>> and you'd need to deal with documentation and tests there. But I think\n>>> we're going to have to do those things eventually (since supporting\n>>> those extra fields everywhere is part of the point of the project). And\n>>> by doing them now, I think it can make the transition for cat-file a lot\n>>> simpler, because we never have to puzzle over this intermediate state\n>>> where only some of the atoms are valid for cat-file.\n>>\n>> I agree that you will have to deal with documentation and tests at one\n>> point and that it could be a good idea to do that now.\n>>\n>> I wonder if it is possible to add atoms one by one into ref-filter and\n>> to add tests and documentation at the same time, instead of merging\n>> cat-file atoms with ref-filter atoms in one big step.\n>>\n>> When all the cat-file atoms have been added to ref-filter's\n>> valid_atom, maybe you could add ref-filter's atoms to cat-file's\n>> valid_cat_file_atom one by one and add tests and documentation at the\n>> same time.\n>>\n>> And then when ref-filter's valid_atom and cat-file's\n>> valid_cat_file_atom are identical you can remove cat-file's\n>> valid_cat_file_atom and maybe after that rename \"ref-filter\" to\n>> \"format\".\n>\n> I think it's important to finish migrating process at first. I mean,\n> now we are preparing and collecting everything in ref-filter, but we\n> make resulting string and print still in cat-file. And I am not sure,\n> but maybe it will not be possible to start using new atoms in cat-file\n> while some part of logic still differs.\n\nOk, you can finish the migration process then.\n\n> And another thoughts here - we were thinking about creating format.h\n> but decided not to move forward with it, and now we are suffering\n> because of it. Can I create it right now or the history of commits\n> would be too dirty because of it?\n\nIt would also make it difficult to refactor your patch series if there\nis a big move or renaming in the middle.\n\n> Also, do you mean just renaming of\n> ref-filter? I was thinking that I need to put formatting-related logic\n> to another file and leave all other stuff in ref-filter.\n\nYeah, you can do both a move and a renaming.\n\n> Anyway, your suggested steps looks good, and I am planning to\n> implement them later.\n\nOk.\n\n> Let's discuss, what behavior we are waiting for\n> when atom seems useless for the command. Die or ignore?\n\nWe could alternatively just emit a warning, but it looks like there\nare a lot of die() calls already in ref-filter.c, so I would suggest\ndie().\n\n> And, which\n> atoms are useless (as I understand, \"rest\" and \"deltabase\" from\n> cat-file are useless for all ref-filter users, so the question is\n> about - am I right in it, and about ref-filter atoms for cat-file).\n\nFor now and I think until the migration process is finished, you could\njust die() in case of any atom not already supported by the command.\n\n> I have never written any tests and docs for Git, I will try to explore\n> by myself how to do that, but if you have any special links/materials\n> about it - please send them to me :)\n\nI think that looking at the existing documentation and tests is\nprobably the best way to learn about it.\n"},{"id":"336898","messageId":"CAL21Bmn1yk_Cw11umpYf7X96JfmguZO48d8QHnx8tXwqT09aiw@mail.gmail.com","threadId":"47582","inReplyTo":"CAP8UFD1dcwEA9z+oQKFV=aFoKn73mtP4qkLGovW2XTu6N=N4dA@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2018-01-19T17:22:11Z","receivedAt":"2018-01-19T17:22:23Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"2018-01-19 20:14 GMT+03:00 Christian Couder :\n> On Thu, Jan 18, 2018 at 7:20 AM, Оля Тележная wrote:\n>> 2018-01-18 1:39 GMT+03:00 Christian Couder :\n>>> On Wed, Jan 17, 2018 at 10:43 PM, Jeff King wrote:\n>>>> On Tue, Jan 16, 2018 at 09:55:22AM +0300, Оля Тележная wrote:\n>>>>\n>>>>> > IOW, the progression I'd expect in a series like this is:\n>>>>> >\n>>>>> > 1. Teach ref-filter.c to support everything that cat-file can do.\n>>>>> >\n>>>>> > 2. Convert cat-file to use ref-filter.c.\n>>>>>\n>>>>> I agree, I even made this and it's working fine:\n>>>>> https://github.com/git/git/pull/450/commits/1b74f1047f07434dccb207534d1ad45a143e3f2b\n>>>\n>>> (Nit: it looks like the above link does not work any more, but it\n>>> seems that you are talking about the last patch on the catfile\n>>> branch.)\n>>>\n>>>>> But I decided not to add that to patch because I expand the\n>>>>> functionality of several commands (not only cat-file and\n>>>>> for-each-ref), and I need to support all new functionality in a proper\n>>>>> way, make these error messages, test everything and - the hardest one\n>>>>> - support many new commands for cat-file. As I understand, it is not\n>>>>> possible unless we finally move to ref-filter and print results also\n>>>>> there. Oh, and I also need to rewrite docs in that case. And I decided\n>>>>> to apply this in another patch. But, please, say your opinion, maybe\n>>>>> we could do that here in some way.\n>>>>\n>>>> Yeah, I agree that it will cause changes to other users of ref-filter,\n>>>> and you'd need to deal with documentation and tests there. But I think\n>>>> we're going to have to do those things eventually (since supporting\n>>>> those extra fields everywhere is part of the point of the project). And\n>>>> by doing them now, I think it can make the transition for cat-file a lot\n>>>> simpler, because we never have to puzzle over this intermediate state\n>>>> where only some of the atoms are valid for cat-file.\n>>>\n>>> I agree that you will have to deal with documentation and tests at one\n>>> point and that it could be a good idea to do that now.\n>>>\n>>> I wonder if it is possible to add atoms one by one into ref-filter and\n>>> to add tests and documentation at the same time, instead of merging\n>>> cat-file atoms with ref-filter atoms in one big step.\n>>>\n>>> When all the cat-file atoms have been added to ref-filter's\n>>> valid_atom, maybe you could add ref-filter's atoms to cat-file's\n>>> valid_cat_file_atom one by one and add tests and documentation at the\n>>> same time.\n>>>\n>>> And then when ref-filter's valid_atom and cat-file's\n>>> valid_cat_file_atom are identical you can remove cat-file's\n>>> valid_cat_file_atom and maybe after that rename \"ref-filter\" to\n>>> \"format\".\n>>\n>> I think it's important to finish migrating process at first. I mean,\n>> now we are preparing and collecting everything in ref-filter, but we\n>> make resulting string and print still in cat-file. And I am not sure,\n>> but maybe it will not be possible to start using new atoms in cat-file\n>> while some part of logic still differs.\n>\n> Ok, you can finish the migration process then.\n>\n>> And another thoughts here - we were thinking about creating format.h\n>> but decided not to move forward with it, and now we are suffering\n>> because of it. Can I create it right now or the history of commits\n>> would be too dirty because of it?\n>\n> It would also make it difficult to refactor your patch series if there\n> is a big move or renaming in the middle.\n>\n>> Also, do you mean just renaming of\n>> ref-filter? I was thinking that I need to put formatting-related logic\n>> to another file and leave all other stuff in ref-filter.\n>\n> Yeah, you can do both a move and a renaming.\n\nThanks for a response! That thought is not clear enough for me. Do you\nwant me to split ref-filter into 2 files (one is for formatting only\ncalled format and other one is for anything else still called\nref-filter) - here is a second question by the way, do I need to\ncreate only format.h (and leave all realizations in ref-filter.c), or\nI also need to create format.c. Or, just to rename ref-filter into\nformat and that's all.\n\n>\n>> Anyway, your suggested steps looks good, and I am planning to\n>> implement them later.\n>\n> Ok.\n>\n>> Let's discuss, what behavior we are waiting for\n>> when atom seems useless for the command. Die or ignore?\n>\n> We could alternatively just emit a warning, but it looks like there\n> are a lot of die() calls already in ref-filter.c, so I would suggest\n> die().\n>\n>> And, which\n>> atoms are useless (as I understand, \"rest\" and \"deltabase\" from\n>> cat-file are useless for all ref-filter users, so the question is\n>> about - am I right in it, and about ref-filter atoms for cat-file).\n>\n> For now and I think until the migration process is finished, you could\n> just die() in case of any atom not already supported by the command.\n>\n>> I have never written any tests and docs for Git, I will try to explore\n>> by myself how to do that, but if you have any special links/materials\n>> about it - please send them to me :)\n>\n> I think that looking at the existing documentation and tests is\n> probably the best way to learn about it.\n"},{"id":"336899","messageId":"20180119172353.GA5752@sigill.intra.peff.net","threadId":"47582","inReplyTo":"CAP8UFD1dcwEA9z+oQKFV=aFoKn73mtP4qkLGovW2XTu6N=N4dA@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-19T17:23:53Z","receivedAt":"2018-01-19T17:24:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 19, 2018 at 06:14:56PM +0100, Christian Couder wrote:\n\n> > Let's discuss, what behavior we are waiting for\n> > when atom seems useless for the command. Die or ignore?\n> \n> We could alternatively just emit a warning, but it looks like there\n> are a lot of die() calls already in ref-filter.c, so I would suggest\n> die().\n\nI actually think it makes sense to just expand nonsense into the empty\nstring, for two reasons:\n\n 1. That's what ref-filter already does for the existing cases. For\n example, try:\n\n git for-each-ref --format='%(objecttype) %(authordate)'\n\n and you will see that the annotated tags just get a blank author\n field.\n\n 2. I think we may end up with a case where we feed multiple objects\n via --batch-check, and the format is only nonsense for _some_ of\n them. E.g., I envision a world where you can do:\n\n git cat-file --batch-check='%(objecttype) %(refname)' <<-\\EOF\n master\n 12345abcde12345abcde12345abcde12345abcde\n EOF\n\n and get output like:\n\n commit refs/heads/master\n commit\n\n (i.e., if we would remember the refname discovered during the name\n resolution, we could still report it). It would be annoying if the\n second line caused us to die().\n\n> > And, which\n> > atoms are useless (as I understand, \"rest\" and \"deltabase\" from\n> > cat-file are useless for all ref-filter users, so the question is\n> > about - am I right in it, and about ref-filter atoms for cat-file).\n> \n> For now and I think until the migration process is finished, you could\n> just die() in case of any atom not already supported by the command.\n\nI'm OK with dying in the interim if it's easier, though I suspect it is\nnot much extra work to just expand to the empty string in such cases. If\nthat's where we want to end up eventually, it may be worth going\nstraight there.\n\nI also think %(deltabase) does make sense for anything that points to an\nobject. I suspect it's not all that _useful_ for for-each-ref, but that\ndoesn't mean we can't return the sensible thing if somebody asks for it.\n\nI agree that %(rest) probably doesn't make any sense for a caller which\nisn't parsing input.\n\n-Peff\n"},{"id":"336901","messageId":"CAP8UFD0to_jok2uw9WTTDSPxb_a_pa-u5qSjLscL1Yw2UuKNPw@mail.gmail.com","threadId":"47582","inReplyTo":"20180119172353.GA5752@sigill.intra.peff.net","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-19T17:31:52Z","receivedAt":"2018-01-19T17:32:02Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jan 19, 2018 at 6:23 PM, Jeff King wrote:\n> On Fri, Jan 19, 2018 at 06:14:56PM +0100, Christian Couder wrote:\n>\n>> > Let's discuss, what behavior we are waiting for\n>> > when atom seems useless for the command. Die or ignore?\n>>\n>> We could alternatively just emit a warning, but it looks like there\n>> are a lot of die() calls already in ref-filter.c, so I would suggest\n>> die().\n>\n> I actually think it makes sense to just expand nonsense into the empty\n> string, for two reasons:\n>\n> 1. That's what ref-filter already does for the existing cases. For\n> example, try:\n>\n> git for-each-ref --format='%(objecttype) %(authordate)'\n>\n> and you will see that the annotated tags just get a blank author\n> field.\n>\n> 2. I think we may end up with a case where we feed multiple objects\n> via --batch-check, and the format is only nonsense for _some_ of\n> them. E.g., I envision a world where you can do:\n>\n> git cat-file --batch-check='%(objecttype) %(refname)' <<-\\EOF\n> master\n> 12345abcde12345abcde12345abcde12345abcde\n> EOF\n>\n> and get output like:\n>\n> commit refs/heads/master\n> commit\n>\n> (i.e., if we would remember the refname discovered during the name\n> resolution, we could still report it). It would be annoying if the\n> second line caused us to die().\n\nYeah, ok, that makes sense.\n\n>> > And, which\n>> > atoms are useless (as I understand, \"rest\" and \"deltabase\" from\n>> > cat-file are useless for all ref-filter users, so the question is\n>> > about - am I right in it, and about ref-filter atoms for cat-file).\n>>\n>> For now and I think until the migration process is finished, you could\n>> just die() in case of any atom not already supported by the command.\n>\n> I'm OK with dying in the interim if it's easier, though I suspect it is\n> not much extra work to just expand to the empty string in such cases. If\n> that's where we want to end up eventually, it may be worth going\n> straight there.\n>\n> I also think %(deltabase) does make sense for anything that points to an\n> object. I suspect it's not all that _useful_ for for-each-ref, but that\n> doesn't mean we can't return the sensible thing if somebody asks for it.\n>\n> I agree that %(rest) probably doesn't make any sense for a caller which\n> isn't parsing input.\n\nYeah, ok.\n"},{"id":"336912","messageId":"CAP8UFD28TwpNgaVyyNuO4qZHnk8ajj53TnVCw9SxHrUAV03_HQ@mail.gmail.com","threadId":"47582","inReplyTo":"CAL21Bmn1yk_Cw11umpYf7X96JfmguZO48d8QHnx8tXwqT09aiw@mail.gmail.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-01-19T17:57:08Z","receivedAt":"2018-01-19T17:57:14Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jan 19, 2018 at 6:22 PM, Оля Тележная wrote:\n> 2018-01-19 20:14 GMT+03:00 Christian Couder :\n>> On Thu, Jan 18, 2018 at 7:20 AM, Оля Тележная wrote:\n\n>>> And another thoughts here - we were thinking about creating format.h\n>>> but decided not to move forward with it, and now we are suffering\n>>> because of it. Can I create it right now or the history of commits\n>>> would be too dirty because of it?\n>>\n>> It would also make it difficult to refactor your patch series if there\n>> is a big move or renaming in the middle.\n>>\n>>> Also, do you mean just renaming of\n>>> ref-filter? I was thinking that I need to put formatting-related logic\n>>> to another file and leave all other stuff in ref-filter.\n>>\n>> Yeah, you can do both a move and a renaming.\n>\n> Thanks for a response! That thought is not clear enough for me. Do you\n> want me to split ref-filter into 2 files (one is for formatting only\n> called format and other one is for anything else still called\n> ref-filter) - here is a second question by the way, do I need to\n> create only format.h (and leave all realizations in ref-filter.c), or\n> I also need to create format.c. Or, just to rename ref-filter into\n> format and that's all.\n\nJust renaming ref-filter into format (including the filenames) will\nprobably be enough, but it's also possible that it will make more\nsense to keep some code only relevant to ref filtering into\nref-filter.{c,h}. We will be in a better position to decide what we\nshould do when the migration is finished.\n"},{"id":"336921","messageId":"xmqq4lnhr8gy.fsf@gitster.mtv.corp.google.com","threadId":"47582","inReplyTo":"20180119172353.GA5752@sigill.intra.peff.net","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-01-19T18:47:57Z","receivedAt":"2018-01-19T18:48:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I also think %(deltabase) does make sense for anything that points to an\n> object. I suspect it's not all that _useful_ for for-each-ref, but that\n> doesn't mean we can't return the sensible thing if somebody asks for it.\n\nThis may not be a new issue (or any issue at all), but is the\nability to learn deltabase make any sense in the first place?\n\nWhat should the code do when an object has three copies in the\nrepo, i.e. one as a base object (or a loose one), another as a\ndelta against an object, and the third one as a delta against\na different object?\n"},{"id":"336930","messageId":"20180119201256.GB10197@sigill.intra.peff.net","threadId":"47582","inReplyTo":"xmqq4lnhr8gy.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 03/18] ref-filter: make valid_atom as function parameter","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-19T20:12:56Z","receivedAt":"2018-01-19T20:13:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 19, 2018 at 10:47:57AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I also think %(deltabase) does make sense for anything that points to an\n> > object. I suspect it's not all that _useful_ for for-each-ref, but that\n> > doesn't mean we can't return the sensible thing if somebody asks for it.\n> \n> This may not be a new issue (or any issue at all), but is the\n> ability to learn deltabase make any sense in the first place?\n> \n> What should the code do when an object has three copies in the\n> repo, i.e. one as a base object (or a loose one), another as a\n> delta against an object, and the third one as a delta against\n> a different object?\n\nThis was a known issue when I introduced %(deltabase). The documentation\nexplicitly calls this out and makes no promises about which copy we\ndescribe.\n\nThe %(objectsize:disk) atom has the same issue, too. See the CAVEATS\nsection of git-cat-file(1).\n\n-Peff\n"}]}