{"thread":{"id":"55697","subject":"[QUESTION] ref-filter: how to support atom like %an","startedAt":"2021-05-15T14:53:11Z","lastAt":"2021-05-17T02:13:42Z","messageCount":3,"participants":["ZheNing Hu","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"424659","messageId":"CAOLTT8QBOgcz+Q_ODnbGq5r5CzrSdX+=DMT0pJS6iPTcP0VRjA@mail.gmail.com","threadId":"55697","inReplyTo":null,"subject":"[QUESTION] ref-filter: how to support atom like %an","fromName":"ZheNing Hu","fromEmail":"adlternative@gmail.com","sentAt":"2021-05-15T14:52:49Z","receivedAt":"2021-05-15T14:53:11Z","isPatch":false,"sender":{"key":"adlternative@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58138461?v=4"},"body":"My current thinking is this:\n\nFirst add a new member `short_name` in `struct valid_atom`,\nThen we can share a valid_atom item for the long name of\nan atom such as `%(authoremail)` and the short name of\nthe atom `%ae` (%aE is not considered at the time).\nSomething like:\n\n[ATOM_AUTHOREMAIL] = { \"ae\", \"authoremail\", SOURCE_OBJ, FIELD_STR,\nperson_email_atom_parser },\n\nThen we need to do some work on atoms parsing:\nIn the original design of `parse_ref_filter_atom()`, it relied on\nsearching for `%(` and `)` to find an atom. Now we have to\nchange the way of finding atoms: Currently I just replace\n`find_next()` to find a single `%`. If there is `(` after `%`,\nwe can keep the original long name atoms parsing method,\notherwise we are dealing with the short name atom,\nwe need to pass the interval between the current `%`\nand the next single `%` to `parse_ref_filter_atom()`.\nThen we are in `parse_ref_filter_atom()`, we need to\nconsider these situations:\n\n1. %(authoremail:trim)\n2. %(authoremail)\n3. %ae\n4. %ae:trim\n5. %aeabc:trim\n6. %ae:trimabcd...\n\nAs we can see, the situation is starting to get complicated.\nThe more critical point is as in case 6: We cannot determine\nthe end of a short name atom because it does not have an\nexplicit `)` end.\nIn this way, many of the `*_atom_parser` functions in\n`ref-filter.c` will not work, because most of them use `strcmp()`\nto check the attribute of an atom. If we want to support the\nshort name `%ae`, that would require a large-scale rewrite.\n\nAny good ideas, friends?\n\n--\nZheNing Hu\n"},{"id":"424671","messageId":"xmqqk0nz72on.fsf@gitster.g","threadId":"55697","inReplyTo":"CAOLTT8QBOgcz+Q_ODnbGq5r5CzrSdX+=DMT0pJS6iPTcP0VRjA@mail.gmail.com","subject":"Re: [QUESTION] ref-filter: how to support atom like %an","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-16T03:55:20Z","receivedAt":"2021-05-16T03:55:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ZheNing Hu writes:\n\n> My current thinking is this:\n>\n> First add a new member `short_name` in `struct valid_atom`,\n> Then we can share a valid_atom item for the long name of\n> an atom such as `%(authoremail)` and the short name of\n> the atom `%ae` (%aE is not considered at the time).\n> Something like:\n>\n> [ATOM_AUTHOREMAIL] = { \"ae\", \"authoremail\", SOURCE_OBJ, FIELD_STR,\n> person_email_atom_parser },\n\nMy assumption has always been that when enriching \"--format\" of the\n\"log\" family (e.g. \"status\", \"show\") with ingredients from the\n\"for-each-ref\" family (e.g. \"branch\", \"tag\"), we would adopt the\nnotation the latter uses, i.e. \"git log --format='%s %(notes)'\",\nwith the full intention that eventually users would choose between\nthe synonyms to make it \"git log --format='%(subject) %(notes)'\" for\nconsistency, without wasting brain cycles to come up with and to\nremember two-letter shorthands that will not scale.\n\n"},{"id":"424696","messageId":"CAOLTT8SKF2whzSgqMO9pYPfehbnU=E4SDYR6B+aMV=fC2qihOQ@mail.gmail.com","threadId":"55697","inReplyTo":"xmqqk0nz72on.fsf@gitster.g","subject":"Re: [QUESTION] ref-filter: how to support atom like %an","fromName":"ZheNing Hu","fromEmail":"adlternative@gmail.com","sentAt":"2021-05-17T02:13:27Z","receivedAt":"2021-05-17T02:13:42Z","isPatch":false,"sender":{"key":"adlternative@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58138461?v=4"},"body":"Junio C Hamano 于2021年5月16日周日 上午11:55写道：\n>\n> ZheNing Hu writes:\n>\n> > My current thinking is this:\n> >\n> > First add a new member `short_name` in `struct valid_atom`,\n> > Then we can share a valid_atom item for the long name of\n> > an atom such as `%(authoremail)` and the short name of\n> > the atom `%ae` (%aE is not considered at the time).\n> > Something like:\n> >\n> > [ATOM_AUTHOREMAIL] = { \"ae\", \"authoremail\", SOURCE_OBJ, FIELD_STR,\n> > person_email_atom_parser },\n>\n> My assumption has always been that when enriching \"--format\" of the\n> \"log\" family (e.g. \"status\", \"show\") with ingredients from the\n> \"for-each-ref\" family (e.g. \"branch\", \"tag\"), we would adopt the\n> notation the latter uses, i.e. \"git log --format='%s %(notes)'\",\n> with the full intention that eventually users would choose between\n> the synonyms to make it \"git log --format='%(subject) %(notes)'\" for\n> consistency, without wasting brain cycles to come up with and to\n> remember two-letter shorthands that will not scale.\n>\n\nWell, it’s truly more useful to provide long name atoms for the \"log\" family,\nBut if we need to establish a unified interface for --format, shouldn't\nwe extend it base on `ref-filter`?\n\nAt present, the scalability of the implementation in `ref-filter` is better,\nbut it does not support two-letter shorthands atoms...\n\n--\nZheNing Hu\n"}]}