{"thread":{"id":"33919","subject":"[PATCH v2 0/3] Towards a useable git-branch","startedAt":"2013-05-24T14:19:34Z","lastAt":"2013-06-04T13:11:25Z","messageCount":31,"participants":["Ramkumar Ramachandra","Duy Nguyen","Junio C Hamano","Philip Oakley","Antoine Pelisse","David Aguilar","Eric Sunshine","John Keeping"],"isPatch":true,"patchVersion":2,"patchTotal":3},"messages":[{"id":"218369","messageId":"1369405177-7855-1-git-send-email-artagnon@gmail.com","threadId":"33919","inReplyTo":null,"subject":"[PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T14:19:34Z","receivedAt":"2013-05-24T14:19:34Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"So, while investigating alignment operators in pretty-formats, I found\nout that it's way too much effort and totally not worth it (atleast\nnot immediately; we can add it later if we want). What I want now is\na useable git-branch output. And I think I can say that I've achieved\nit.\n\nI currently have hot aliased to\n\nfor-each-ref --format='%C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)%(upstream:trackshort)' --count 10 --sort='-committerdate' refs/heads\n\nand it works beautifully for me. Sample output:\n\n% git hot\n* hot-branch<>\n pickaxe-doc>\n publish-rev=\n publish-rev-test\n upstream-error=\n push-current-head=\n master=\n prompt=\n autostash-stash=\n rebase.autostash=\n\nThe asterisk is red, the branch names are in green, and the tracking\nmarker is white.\n\nI'm very happy with the implementation too:\n\n1. color only kicks in at the parsing layer.\n2. HEAD is a new atom.\n3. :track[short] is a formatp like :short.\n\nThere is no need to use a hammer and coerce everything into an atom,\nor throw everything out the window and start from scratch to conform\nto pretty-formats perfectly. Let's extend the existing format to be\n_useful_ sensibly.\n\nThanks.\n\nRamkumar Ramachandra (3):\n for-each-ref: introduce %C(...) for color\n for-each-ref: introduce %(HEAD) marker\n for-each-ref: introduce %(upstream:track[short])\n\n builtin/for-each-ref.c | 81 +++++++++++++++++++++++++++++++++++++++++++++-----\n 1 file changed, 73 insertions(+), 8 deletions(-)\n\n-- \n1.8.3.rc3.2.g99b8f3f.dirty\n"},{"id":"218372","messageId":"1369405177-7855-2-git-send-email-artagnon@gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T14:19:35Z","receivedAt":"2013-05-24T14:19:35Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Since 'git branch' misses important options like --sort, --count, and\n--format that are present in 'git for-each-ref'. Until we are in a\nposition to fix 'git branch', let us enhance the 'git for-each-ref'\nformat so it can atleast colorize output.\n\nYou can use the following format in for-each-ref:\n\n %C(green)%(refname:short)%C(reset)\n\nTo display refs in green. Future patches will attempt to extend the\nformat even more to get useful output.\n\nSigned-off-by: Ramkumar Ramachandra \n---\n builtin/for-each-ref.c | 26 ++++++++++++++++++++++----\n 1 file changed, 22 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c\nindex 7f059c3..1563b25 100644\n--- a/builtin/for-each-ref.c\n+++ b/builtin/for-each-ref.c\n@@ -9,6 +9,7 @@\n #include \"quote.h\"\n #include \"parse-options.h\"\n #include \"remote.h\"\n+#include \"color.h\"\n \n /* Quoting styles */\n #define QUOTE_NONE 0\n@@ -155,10 +156,13 @@ static const char *find_next(const char *cp)\n \twhile (*cp) {\n \t\tif (*cp == '%') {\n \t\t\t/*\n+\t\t\t * %C( is the start of a color;\n \t\t\t * %( is the start of an atom;\n \t\t\t * %% is a quoted per-cent.\n \t\t\t */\n-\t\t\tif (cp[1] == '(')\n+\t\t\tif (cp[1] == 'C' && cp[2] == '(')\n+\t\t\t\treturn cp;\n+\t\t\telse if (cp[1] == '(')\n \t\t\t\treturn cp;\n \t\t\telse if (cp[1] == '%')\n \t\t\t\tcp++; /* skip over two % */\n@@ -180,8 +184,12 @@ static int verify_format(const char *format)\n \t\tconst char *ep = strchr(sp, ')');\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\tparse_atom(sp + 2, ep);\n+\t\t/*\n+\t\t * Ignore color specifications: %C(\n+\t\t * sp points at \"%(\" and ep points at the closing \")\"\n+\t\t */\n+\t\tif (prefixcmp(sp, \"%C(\"))\n+\t\t\tparse_atom(sp + 2, ep);\n \t\tcp = ep + 1;\n \t}\n \treturn 0;\n@@ -928,12 +936,22 @@ static void emit(const char *cp, const char *ep)\n static void show_ref(struct refinfo *info, const char *format, int quote_style)\n {\n \tconst char *cp, *sp, *ep;\n+\tchar color[COLOR_MAXLEN];\n \n \tfor (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) {\n \t\tep = strchr(sp, ')');\n \t\tif (cp < sp)\n \t\t\temit(cp, sp);\n-\t\tprint_value(info, parse_atom(sp + 2, ep), quote_style);\n+\n+\t\t/* Do we have a color specification? */\n+\t\tif (!prefixcmp(sp, \"%C(\"))\n+\t\t\tcolor_parse_mem(sp + 3,\n+\t\t\t\t\tep - sp - 3,\n+\t\t\t\t\t\"--format \", color);\n+\t\telse {\n+\t\t\tprintf(\"%s\", color);\n+\t\t\tprint_value(info, parse_atom(sp + 2, ep), quote_style);\n+\t\t}\n \t}\n \tif (*cp) {\n \t\tsp = cp + strlen(cp);\n-- \n1.8.3.rc3.2.g99b8f3f.dirty\n"},{"id":"218371","messageId":"1369405177-7855-3-git-send-email-artagnon@gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 2/3] for-each-ref: introduce %(HEAD) marker","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T14:19:36Z","receivedAt":"2013-05-24T14:19:36Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"'git branch' shows which branch you are currently on with an '*', but\n'git for-each-ref' misses this feature. So, extend the format with\n%(HEAD) to do exactly the same thing.\n\nNow you can use the following format in for-each-ref:\n\n %C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)\n\nto display a red asterisk next to the current ref.\n\nSigned-off-by: Ramkumar Ramachandra \n---\n builtin/for-each-ref.c | 13 +++++++++++--\n 1 file changed, 11 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c\nindex 1563b25..63d3a85 100644\n--- a/builtin/for-each-ref.c\n+++ b/builtin/for-each-ref.c\n@@ -76,6 +76,7 @@ static struct {\n \t{ \"upstream\" },\n \t{ \"symref\" },\n \t{ \"flag\" },\n+\t{ \"HEAD\" },\n };\n \n /*\n@@ -683,8 +684,16 @@ static void populate_value(struct refinfo *ref)\n \t\t\t\tv->s = xstrdup(buf + 1);\n \t\t\t}\n \t\t\tcontinue;\n-\t\t}\n-\t\telse\n+\t\t} else if (!strcmp(name, \"HEAD\")) {\n+\t\t\tconst char *head;\n+\t\t\tunsigned char sha1[20];\n+\t\t\thead = resolve_ref_unsafe(\"HEAD\", sha1, 1, NULL);\n+\t\t\tif (!strcmp(ref->refname, head))\n+\t\t\t\tv->s = \"*\";\n+\t\t\telse\n+\t\t\t\tv->s = \" \";\n+\t\t\tcontinue;\n+\t\t} else\n \t\t\tcontinue;\n \n \t\tformatp = strchr(name, ':');\n-- \n1.8.3.rc3.2.g99b8f3f.dirty\n"},{"id":"218370","messageId":"1369405177-7855-4-git-send-email-artagnon@gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 3/3] for-each-ref: introduce %(upstream:track[short])","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T14:19:37Z","receivedAt":"2013-05-24T14:19:37Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Introduce %(upstream:track) to display \"[ahead M, behind N]\" and\n%(upstream:trackshort) to display \"=\", \">\", \"<\", or \"<>\"\nappropriately (inspired by the contrib/completion/git-prompt.sh).\n\nNow you can use the following format in for-each-ref:\n\n %C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)%(upstream:trackshort)\n\nto display refs with terse tracking information.\n\nNote that :track and :trackshort only works with upstream, and errors\nout when used with anything else.\n\nSigned-off-by: Ramkumar Ramachandra \n---\n builtin/for-each-ref.c | 42 ++++++++++++++++++++++++++++++++++++++++--\n 1 file changed, 40 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c\nindex 63d3a85..838b125 100644\n--- a/builtin/for-each-ref.c\n+++ b/builtin/for-each-ref.c\n@@ -632,6 +632,7 @@ static void populate_value(struct refinfo *ref)\n \tint eaten, i;\n \tunsigned long size;\n \tconst unsigned char *tagged;\n+\tint upstream_present = 0;\n \n \tref->value = xcalloc(sizeof(struct atom_value), used_atom_cnt);\n \n@@ -649,6 +650,7 @@ static void populate_value(struct refinfo *ref)\n \t\tint deref = 0;\n \t\tconst char *refname;\n \t\tconst char *formatp;\n+\t\tstruct branch *branch;\n \n \t\tif (*name == '*') {\n \t\t\tderef = 1;\n@@ -660,7 +662,6 @@ static void populate_value(struct refinfo *ref)\n \t\telse if (!prefixcmp(name, \"symref\"))\n \t\t\trefname = ref->symref ? ref->symref : \"\";\n \t\telse if (!prefixcmp(name, \"upstream\")) {\n-\t\t\tstruct branch *branch;\n \t\t\t/* only local branches may have an upstream */\n \t\t\tif (prefixcmp(ref->refname, \"refs/heads/\"))\n \t\t\t\tcontinue;\n@@ -670,6 +671,7 @@ static void populate_value(struct refinfo *ref)\n \t\t\t !branch->merge[0]->dst)\n \t\t\t\tcontinue;\n \t\t\trefname = branch->merge[0]->dst;\n+\t\t\tupstream_present = 1;\n \t\t}\n \t\telse if (!strcmp(name, \"flag\")) {\n \t\t\tchar buf[256], *cp = buf;\n@@ -687,6 +689,7 @@ static void populate_value(struct refinfo *ref)\n \t\t} else if (!strcmp(name, \"HEAD\")) {\n \t\t\tconst char *head;\n \t\t\tunsigned char sha1[20];\n+\n \t\t\thead = resolve_ref_unsafe(\"HEAD\", sha1, 1, NULL);\n \t\t\tif (!strcmp(ref->refname, head))\n \t\t\t\tv->s = \"*\";\n@@ -699,11 +702,46 @@ static void populate_value(struct refinfo *ref)\n \t\tformatp = strchr(name, ':');\n \t\t/* look for \"short\" refname format */\n \t\tif (formatp) {\n+\t\t\tint num_ours, num_theirs;\n+\n \t\t\tformatp++;\n \t\t\tif (!strcmp(formatp, \"short\"))\n \t\t\t\trefname = shorten_unambiguous_ref(refname,\n \t\t\t\t\t\t warn_ambiguous_refs);\n-\t\t\telse\n+\t\t\telse if (!strcmp(formatp, \"track\") &&\n+\t\t\t\t!prefixcmp(name, \"upstream\")) {\n+\t\t\t\tchar buf[40];\n+\n+\t\t\t\tif (!upstream_present)\n+\t\t\t\t\tcontinue;\n+\t\t\t\tif (!stat_tracking_info(branch, &num_ours, &num_theirs))\n+\t\t\t\t\tv->s = \"\";\n+\t\t\t\telse if (!num_ours) {\n+\t\t\t\t\tsprintf(buf, \"[behind %d]\", num_theirs);\n+\t\t\t\t\tv->s = xstrdup(buf);\n+\t\t\t\t} else if (!num_theirs) {\n+\t\t\t\t\tsprintf(buf, \"[ahead %d]\", num_ours);\n+\t\t\t\t\tv->s = xstrdup(buf);\n+\t\t\t\t} else {\n+\t\t\t\t\tsprintf(buf, \"[ahead %d, behind %d]\",\n+\t\t\t\t\t\tnum_ours, num_theirs);\n+\t\t\t\t\tv->s = xstrdup(buf);\n+\t\t\t\t}\n+\t\t\t\tcontinue;\n+\t\t\t} else if (!strcmp(formatp, \"trackshort\") &&\n+\t\t\t\t!prefixcmp(name, \"upstream\")) {\n+\t\t\t\tif (!upstream_present)\n+\t\t\t\t\tcontinue;\n+\t\t\t\tif (!stat_tracking_info(branch, &num_ours, &num_theirs))\n+\t\t\t\t\tv->s = \"=\";\n+\t\t\t\telse if (!num_ours)\n+\t\t\t\t\tv->s = \"<\";\n+\t\t\t\telse if (!num_theirs)\n+\t\t\t\t\tv->s = \">\";\n+\t\t\t\telse\n+\t\t\t\t\tv->s = \"<>\";\n+\t\t\t\tcontinue;\n+\t\t\t} else\n \t\t\t\tdie(\"unknown %.*s format %s\",\n \t\t\t\t (int)(formatp - name), name, formatp);\n \t\t}\n-- \n1.8.3.rc3.2.g99b8f3f.dirty\n"},{"id":"218377","messageId":"CACsJy8CaCv4eO2YH_bUKKKZWTxSu9zd3qaDQ5kdZQaKg64ggyQ@mail.gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-1-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-24T15:27:19Z","receivedAt":"2013-05-24T15:27:19Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra\n wrote:\n> There is no need to use a hammer and coerce everything into an atom,\n> or throw everything out the window and start from scratch to conform\n> to pretty-formats perfectly. Let's extend the existing format to be\n> _useful_ sensibly.\n\nUsefulness is one thing. Another is maintenance and in that regard I\nstill think we should be able to remove -v and -vv code (not the\nfunctionality) with this topic.\n--\nDuy\n"},{"id":"218382","messageId":"CALkWK0nTGydbAQFajUtf30XWNW3TrWDiYUWFw1KPUoHpdkyw7Q@mail.gmail.com","threadId":"33919","inReplyTo":"CACsJy8CaCv4eO2YH_bUKKKZWTxSu9zd3qaDQ5kdZQaKg64ggyQ@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T15:58:00Z","receivedAt":"2013-05-24T15:58:00Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> Usefulness is one thing. Another is maintenance and in that regard I\n> still think we should be able to remove -v and -vv code (not the\n> functionality) with this topic.\n\nWhy? The topic adds good functionality, doesn't break anything,\ndoesn't paint us into any corner, and has users. Replacing -v and -vv\ncan be done eventually, after we get alignment.\n"},{"id":"218403","messageId":"7vobc09sf6.fsf@alter.siamese.dyndns.org","threadId":"33919","inReplyTo":"CACsJy8CaCv4eO2YH_bUKKKZWTxSu9zd3qaDQ5kdZQaKg64ggyQ@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-24T17:52:29Z","receivedAt":"2013-05-24T17:52:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra\n> wrote:\n>> There is no need to use a hammer and coerce everything into an atom,\n>> or throw everything out the window and start from scratch to conform\n>> to pretty-formats perfectly. Let's extend the existing format to be\n>> _useful_ sensibly.\n>\n> Usefulness is one thing. Another is maintenance and in that regard I\n> still think we should be able to remove -v and -vv code (not the\n> functionality) with this topic.\n\nYes, the aim of the topic should be to make the machinery flexible\nenough so that we can lose -v/-vv implementation and replace them\nwith calls to the new machinery with canned set of output format\ntemplates.\n\nBy the way, I do not think \"useable git-branch\" is a good title,\nthough. The expression has unnecessary venom in it, as if what it\ncurrently does is not usable. More flexible would be fine.\n\nI am having this feeling that we see more and more of this line of\nbad behaviours from some on the list recently to call something that\nis working in which they find itch using unnecessarily derogatory\nterms, and it makes people simply avoid any discussion that starts\nwith such an attitude.\n\nUnnecessary negativity is not productive and it has to stop.\n"},{"id":"218406","messageId":"CALkWK0kut8xVx1Q8dFrrjCSufJtJc=tvLKStf0tiWHzpfksG1g@mail.gmail.com","threadId":"33919","inReplyTo":"7vobc09sf6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T18:01:08Z","receivedAt":"2013-05-24T18:01:08Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> I am having this feeling that we see more and more of this line of\n> bad behaviours from some on the list recently to call something that\n> is working in which they find itch using unnecessarily derogatory\n> terms, and it makes people simply avoid any discussion that starts\n> with such an attitude.\n>\n> Unnecessary negativity is not productive and it has to stop.\n\nMy apologies. After all, we have all been using 'git branch' for so\nmany years without complaining. I only noticed the itch recently:\nit's a burning itch that I want it to be fixed very badly (hence the\nseries). If anything I intended to convey the importance of the patch\nto me personally, not about some \"general truth\" on the broken-ness of\ngit-branch.\n\nOfcourse I will take your suggestion and tone down, because I don't\nwant the git community to feel bad about the software they're\ndeveloping.\n"},{"id":"218407","messageId":"CALkWK0=QbDAmbRm+01FWc3Okhcgg8RdoRjwfkjrsZ8n=Zm007g@mail.gmail.com","threadId":"33919","inReplyTo":"7vobc09sf6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-24T18:08:27Z","receivedAt":"2013-05-24T18:08:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Yes, the aim of the topic should be to make the machinery flexible\n> enough so that we can lose -v/-vv implementation and replace them\n> with calls to the new machinery with canned set of output format\n> templates.\n\nDefinitely. I don't want to keep my ugly alias around forever, and I\ncertainly want more users to have easy access to this (configurable\ngit-branch output formats). However, the series is not the\ntheoretical exercise of prettifying the code underlying -v and -vv.\nSupporting -v and -vv is something we _have_ to do to preserve\nbackward compatibility, and I would consider it a side-effect of the\nseries rather than the \"aim of the topic\". The aim of the topic is to\nget more useful output from git-branch.\n\nAs long as the topic doesn't paint us into a corner after which it\nwill be impossible to implement -v and -vv on top of the format, I\nthink we're good.\n"},{"id":"218413","messageId":"2314A6D4A97C4D44AFEF62B9D089BDC3@PhilipOakley","threadId":"33919","inReplyTo":"1369405177-7855-3-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 2/3] for-each-ref: introduce %(HEAD) marker","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-24T20:28:46Z","receivedAt":"2013-05-24T20:28:46Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Ramkumar Ramachandra\" \nSent: Friday, May 24, 2013 3:19 PM\n> 'git branch' shows which branch you are currently on with an '*', but\n> 'git for-each-ref' misses this feature. So, extend the format with\n> %(HEAD) to do exactly the same thing.\n\nMaybe 'isHEAD' as a better name, or 'ifHEAD', or something to indicate \nits boolean nature.\n\n>\n> Now you can use the following format in for-each-ref:\n>\n> %C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)\n>\n> to display a red asterisk next to the current ref.\n>\n> Signed-off-by: Ramkumar Ramachandra \n> ---\n> builtin/for-each-ref.c | 13 +++++++++++--\n> 1 file changed, 11 insertions(+), 2 deletions(-)\n>\n> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c\n> index 1563b25..63d3a85 100644\n> --- a/builtin/for-each-ref.c\n> +++ b/builtin/for-each-ref.c\n> @@ -76,6 +76,7 @@ static struct {\n> { \"upstream\" },\n> { \"symref\" },\n> { \"flag\" },\n> + { \"HEAD\" },\n> };\n>\n> /*\n> @@ -683,8 +684,16 @@ static void populate_value(struct refinfo *ref)\n> v->s = xstrdup(buf + 1);\n> }\n> continue;\n> - }\n> - else\n> + } else if (!strcmp(name, \"HEAD\")) {\n> + const char *head;\n> + unsigned char sha1[20];\n> + head = resolve_ref_unsafe(\"HEAD\", sha1, 1, NULL);\n> + if (!strcmp(ref->refname, head))\n> + v->s = \"*\";\n> + else\n> + v->s = \" \";\n> + continue;\n> + } else\n> continue;\n>\n> formatp = strchr(name, ':');\n> -- \n> 1.8.3.rc3.2.g99b8f3f.dirty\n"},{"id":"218415","messageId":"CALWbr2yuEczF-G7uJ0r-teUJrZowrY8mYm+xwJmv4+CT6NgDPA@mail.gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-2-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-05-24T20:56:57Z","receivedAt":"2013-05-24T20:56:57Z","isPatch":true,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Fri, May 24, 2013 at 4:19 PM, Ramkumar Ramachandra\n wrote:\n> @@ -928,12 +936,22 @@ static void emit(const char *cp, const char *ep)\n> static void show_ref(struct refinfo *info, const char *format, int quote_style)\n> {\n> const char *cp, *sp, *ep;\n> + char color[COLOR_MAXLEN];\n>\n> for (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) {\n> ep = strchr(sp, ')');\n> if (cp < sp)\n> emit(cp, sp);\n> - print_value(info, parse_atom(sp + 2, ep), quote_style);\n> +\n> + /* Do we have a color specification? */\n> + if (!prefixcmp(sp, \"%C(\"))\n> + color_parse_mem(sp + 3,\n> + ep - sp - 3,\n> + \"--format \", color);\n> + else {\n> + printf(\"%s\", color);\n\nIs it not possible for \"color\" to be used uninitialized here ?\n\n> + print_value(info, parse_atom(sp + 2, ep), quote_style);\n> + }\n> }\n> if (*cp) {\n> sp = cp + strlen(cp);\n"},{"id":"218418","messageId":"CACsJy8AEkmiWP46tOBkXRkWDGO+k5YW+GJB-ak8HfTpghQP5eQ@mail.gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-1-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-24T22:51:48Z","receivedAt":"2013-05-24T22:51:48Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra\n wrote:\n> So, while investigating alignment operators in pretty-formats, I found\n> out that it's way too much effort and totally not worth it (atleast\n> not immediately; we can add it later if we want).\n\nI just had an idea that might bring pretty stuff to for-each-ref with\nprobably reasonable effort, making for-each-ref format a superset of\npretty. But I need to clean up my backlog first. Give me a few days, I\nwill show you something (or give up ;)\n--\nDuy\n"},{"id":"218419","messageId":"CAJDDKr5==LhBCWrPNv89w3T7dXueYfUpY-zykEXkt_VLDsQhww@mail.gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-2-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-05-24T23:41:29Z","receivedAt":"2013-05-24T23:41:29Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, May 24, 2013 at 7:19 AM, Ramkumar Ramachandra\n wrote:\n> Since 'git branch' misses important options like --sort, --count, and\n> --format that are present in 'git for-each-ref'. Until we are in a\n> position to fix 'git branch', let us enhance the 'git for-each-ref'\n> format so it can atleast colorize output.\n>\n> You can use the following format in for-each-ref:\n>\n> %C(green)%(refname:short)%C(reset)\n>\n> To display refs in green. Future patches will attempt to extend the\n> format even more to get useful output.\n>\n> Signed-off-by: Ramkumar Ramachandra \n> ---\n> builtin/for-each-ref.c | 26 ++++++++++++++++++++++----\n> 1 file changed, 22 insertions(+), 4 deletions(-)\n\nCan you please also update Documentation/?\n--\nDavid\n"},{"id":"218503","messageId":"CACsJy8Av8LmiefR5XFuFadZERmivZAAB9TbysFjeUSb2hzgWBw@mail.gmail.com","threadId":"33919","inReplyTo":"CACsJy8AEkmiWP46tOBkXRkWDGO+k5YW+GJB-ak8HfTpghQP5eQ@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-25T06:26:01Z","receivedAt":"2013-05-25T06:26:01Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 25, 2013 at 5:51 AM, Duy Nguyen wrote:\n> I just had an idea that might bring pretty stuff to for-each-ref with\n> probably reasonable effort, making for-each-ref format a superset of\n> pretty. But I need to clean up my backlog first. Give me a few days, I\n> will show you something (or give up ;)\n\nAnd I can't get it out of my head. Might as well write it down. Check out\n\nhttps://github.com/pclouds/git.git for-each-ref-pretty\n\nIt opens a hook in format_commit_message() to plug f-e-r's atom syntax\nin. I didn't do extensive test or anything, just t6300. The %xx syntax\nin for-each-ref might override some placeholders in pretty, I did not\ncheck. You can add extra %(xx) on top as you have done. I still need\none more hook to support %>(*) with automatic width detection. After\nthat I'm quite confident we can kill -v/-vv code.\n--\nDuy\n"},{"id":"218507","messageId":"CAPig+cTSKPS2ui0=xathnR=Xau3YoE+omw3GRmJq5QHDDgD_7Q@mail.gmail.com","threadId":"33919","inReplyTo":"1369405177-7855-2-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-05-25T06:29:05Z","receivedAt":"2013-05-25T06:29:05Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 24, 2013 at 10:19 AM, Ramkumar Ramachandra\n wrote:\n> Since 'git branch' misses important options like --sort, --count, and\n> --format that are present in 'git for-each-ref'. Until we are in a\n> position to fix 'git branch', let us enhance the 'git for-each-ref'\n> format so it can atleast colorize output.\n\ns/atleast/at least/\n\n> You can use the following format in for-each-ref:\n>\n> %C(green)%(refname:short)%C(reset)\n>\n> To display refs in green. Future patches will attempt to extend the\n> format even more to get useful output.\n>\n> Signed-off-by: Ramkumar Ramachandra \n"},{"id":"218534","messageId":"CACsJy8CW-xtXR15m80oaoex0QF5Vi2L2-kqEzOPxCY2UBmdhxw@mail.gmail.com","threadId":"33919","inReplyTo":"CACsJy8Av8LmiefR5XFuFadZERmivZAAB9TbysFjeUSb2hzgWBw@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-25T11:35:47Z","receivedAt":"2013-05-25T11:35:47Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 25, 2013 at 1:26 PM, Duy Nguyen wrote:\n> On Sat, May 25, 2013 at 5:51 AM, Duy Nguyen wrote:\n>> I just had an idea that might bring pretty stuff to for-each-ref with\n>> probably reasonable effort, making for-each-ref format a superset of\n>> pretty. But I need to clean up my backlog first. Give me a few days, I\n>> will show you something (or give up ;)\n>\n> And I can't get it out of my head. Might as well write it down. Check out\n>\n> https://github.com/pclouds/git.git for-each-ref-pretty\n\nRam, fetch the url above again. Its tip now is 5b4aa27 (for-each-ref:\nintroduce format specifier %>(*) and %<(*) - 2013-05-25). Those\nchanges make for-each-ref --format a superset of pretty. You can add\nnew %(xxx) on top and resend the whole thing to the list for review.\nYou can remove \"branch -v/-vv\" code as well or I'll add some patches\non top to do that later. I have some compatibility concerns about the\n\"superset\" thing. But let's wait until the series hits git@vger.\n--\nDuy\n"},{"id":"218536","messageId":"CALkWK0kb2D2nH_pDi0TihmFzuEAvWnGJeX0sOXD1TEWLZ7YWHw@mail.gmail.com","threadId":"33919","inReplyTo":"CACsJy8CW-xtXR15m80oaoex0QF5Vi2L2-kqEzOPxCY2UBmdhxw@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-25T11:48:33Z","receivedAt":"2013-05-25T11:48:33Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> Ram, fetch the url above again. Its tip now is 5b4aa27 (for-each-ref:\n> introduce format specifier %>(*) and %<(*) - 2013-05-25). Those\n> changes make for-each-ref --format a superset of pretty. You can add\n> new %(xxx) on top and resend the whole thing to the list for review.\n> You can remove \"branch -v/-vv\" code as well or I'll add some patches\n> on top to do that later. I have some compatibility concerns about the\n> \"superset\" thing. But let's wait until the series hits git@vger.\n\nGreat work Duy! I see that you've used format_commit_message(), but\nthere are some concerns about pretty-formats conflicting with f-e-r's\nformat. We'll iron it out slowly, but I like the overall approach.\n\nThanks.\n\n(Very sleep deprived at the moment; will review and collaborate after I wake up)\n"},{"id":"218537","messageId":"CALkWK0=16dmz548TQoj5YKp0dai7p1dpYAdXiWnnpiQdzyYHQg@mail.gmail.com","threadId":"33919","inReplyTo":"CALWbr2yuEczF-G7uJ0r-teUJrZowrY8mYm+xwJmv4+CT6NgDPA@mail.gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-25T11:50:29Z","receivedAt":"2013-05-25T11:50:29Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Antoine Pelisse wrote:\n> Is it not possible for \"color\" to be used uninitialized here ?\n\nMy compiler didn't complain; what am I missing? Doesn't the\ndeclaration char color[COLOR_MAXLEN]; initialize an empty string?\nMore importantly, aren't there numerous instances of this in the\ncodebase?\n"},{"id":"218538","messageId":"CALkWK0=X9Q-8ukD2PibMJzYURV1-6i0J8rQcD4iYZb2CtmPeCA@mail.gmail.com","threadId":"33919","inReplyTo":"CAJDDKr5==LhBCWrPNv89w3T7dXueYfUpY-zykEXkt_VLDsQhww@mail.gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-25T11:51:38Z","receivedAt":"2013-05-25T11:51:38Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"David Aguilar wrote:\n> Can you please also update Documentation/?\n\nYeah, will do in the re-roll. Duy is bringing in pretty-formats.\nWe'll probably need a separate document called pretty-ref-formats or\nsome such thing.\n"},{"id":"218540","messageId":"20130525122002.GI27005@serenity.lan","threadId":"33919","inReplyTo":"CALkWK0=16dmz548TQoj5YKp0dai7p1dpYAdXiWnnpiQdzyYHQg@mail.gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-25T12:20:02Z","receivedAt":"2013-05-25T12:20:02Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Sat, May 25, 2013 at 05:20:29PM +0530, Ramkumar Ramachandra wrote:\n> Antoine Pelisse wrote:\n> > Is it not possible for \"color\" to be used uninitialized here ?\n> \n> My compiler didn't complain; what am I missing? Doesn't the\n> declaration char color[COLOR_MAXLEN]; initialize an empty string?\n\nWhy would it? The variable's begin allocated on the stack and the C\nstandard only zero-initializes variables with static storage duration;\nSection 6.7.9 of the C11 standard says:\n\n If an object that has automatic storage duration is not initialized\n explicitly, its value is indeterminate.\n\n\nI suspect the compiler doesn't complain because there is a path through\nthe function that initializes color before reading it (if we hit the\n\"if\" branch in the loop before the \"else\" branch) and the compile\nassumes that there is something in the function's contract that\nguarantees that we follow this path. But I don't think that's correct\nso you do need to initialize color to the empty string.\n\n> More importantly, aren't there numerous instances of this in the\n> codebase?\n\nCare to point at one? I had a quick look and all places I inspected are\neither static or write to the array before reading it.\n"},{"id":"218541","messageId":"CALWbr2xmaaE3udrYPWULiHpfSMvCWPu597hPhkumaPC+D6Uxfg@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0=16dmz548TQoj5YKp0dai7p1dpYAdXiWnnpiQdzyYHQg@mail.gmail.com","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-05-25T12:35:50Z","receivedAt":"2013-05-25T12:35:50Z","isPatch":true,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Sat, May 25, 2013 at 1:50 PM, Ramkumar Ramachandra\n wrote:\n> Antoine Pelisse wrote:\n>> Is it not possible for \"color\" to be used uninitialized here ?\n>\n> My compiler didn't complain; what am I missing? Doesn't the\n> declaration char color[COLOR_MAXLEN]; initialize an empty string?\n\nAs John said, this is allocated on the stack.\nWhat do you want it to be initialized to ?\nFilled with zeros ? That's overkill because only the first char needs\nto be zeroed.\nThe compiler can't know what to do and it lets you to take the best action.\n\n> More importantly, aren't there numerous instances of this in the\n> codebase?\n\nI think Valgrind would be mad at us if there was many instances of\nthis. By the way Ramkumar, could you check if Valgrind complains with\nyour patch ?\n"},{"id":"218542","messageId":"CALkWK0mMq9osT6yuhQuPrK=J7b63xxA7r1QVXT4X5nXu+wDouA@mail.gmail.com","threadId":"33919","inReplyTo":"20130525122002.GI27005@serenity.lan","subject":"Re: [PATCH 1/3] for-each-ref: introduce %C(...) for color","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-25T12:54:57Z","receivedAt":"2013-05-25T12:54:57Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"John Keeping wrote:\n> Section 6.7.9 of the C11 standard says:\n>\n> If an object that has automatic storage duration is not initialized\n> explicitly, its value is indeterminate.\n\nAh, thanks. I'll initialize it to an empty string.\n\n>> More importantly, aren't there numerous instances of this in the\n>> codebase?\n>\n> Care to point at one? I had a quick look and all places I inspected are\n> either static or write to the array before reading it.\n\nI'll run some Valgrind tests to see what it yields.\n"},{"id":"218667","messageId":"CALkWK0k=2NZsbSnxS50w+bux8q9mZh7GZzpCqhTP=2jqyHnBSg@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0kb2D2nH_pDi0TihmFzuEAvWnGJeX0sOXD1TEWLZ7YWHw@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-28T14:01:47Z","receivedAt":"2013-05-28T14:01:47Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Duy,\n\nI just woke up and started looking at the series: it's rather well\ndone, and I'm confident that this is the way forward. To reciprocate,\nI've done some work at gh:artagnon/git for-each-ref-pretty. See:\n\nhttps://github.com/artagnon/git/commits/for-each-ref-pretty\n\nThere is one major problem though:\n\n%>(N) doesn't work properly with f-e-r, and I'm not sure why. I'm not\ntalking about your last patch where you compute * -- that works fine;\nit's just that %>(N) doesn't when N is a concrete number.\n\nAlso, a couple of minor annoyances:\n\n1. When f-e-r is invoked with refs/tags, we get stray output. Atleast\nit doesn't segfault, thanks to your ignore-commit patch. Maybe\nprinting stray output is the right thing to do, as opposed to erroring\nout.\n\n2. %>(*) only works with f-e-r atoms, not with pretty-format atoms.\nThis is ofcourse obvious from the implementation, but isn't it a\nlittle consistent?\n\nShould we start off a new pretty-ref-formats document, where we\nexplicitly exclude things like %ae (because of the hex overriding\nthing)? I don't think it's a problem if documented properly.\n"},{"id":"218668","messageId":"CALkWK0nFDdfGKeRqKKTTMSm4zqHDOt_iGc1aA7LgD9=y2DJO5A@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0k=2NZsbSnxS50w+bux8q9mZh7GZzpCqhTP=2jqyHnBSg@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-28T14:24:02Z","receivedAt":"2013-05-28T14:24:02Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Oh, and by the way:\n\nWe're pretty close we are to replacing branch -v and branch -vv.\n\nbrv = for-each-ref --format='%(HEAD)\n%C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)\n%(subject)' refs/heads\n\nbrvv = for-each-ref --format='%(HEAD)\n%C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)\n%C(blue)%(upstream:short)%C(reset) %(subject)' refs/heads\n\nThere are small differences:\n\n1. In branch -v, the green-color of the branch name is dependent on\n%(HEAD). Not worth ironing out, in my opinion.\n\n2. In branch -vv, there are dependent square braces that come on when\n%(refname:short) is set. We might want to introduce an undocumented\n%(refname:branchvv) for internal use by branch -vv, for backward\ncompatibility.\n\nWhat do you think?\n"},{"id":"218669","messageId":"CALkWK0kv-5vAMsrtpPffBaSZrHfm98KNDL8Jw6_pSLsL=8=8iA@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0k=2NZsbSnxS50w+bux8q9mZh7GZzpCqhTP=2jqyHnBSg@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-28T14:28:49Z","receivedAt":"2013-05-28T14:28:49Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> %>(N) doesn't work properly with f-e-r, and I'm not sure why. I'm not\n> talking about your last patch where you compute * -- that works fine;\n> it's just that %>(N) doesn't when N is a concrete number.\n\nTry this:\n\n%(refname:short)%>(30)%(upstream:short)\n\n(assuming that you have lots of branches). I'm noticing random\nalignment problems.\n\nHowever, %<(N) doesn't seem to have this problem:\n\n%<(30)%(refname:short)%(upstream:short)\n\nI'm not able to figure this out.\n"},{"id":"218720","messageId":"CACsJy8Dvpn0u1i8M7uxsB=t4NE5v78=gYiY=XFC=KK7f4D=N=w@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0kv-5vAMsrtpPffBaSZrHfm98KNDL8Jw6_pSLsL=8=8iA@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-29T03:04:37Z","receivedAt":"2013-05-29T03:04:37Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, May 28, 2013 at 9:28 PM, Ramkumar Ramachandra\n wrote:\n> Ramkumar Ramachandra wrote:\n>> %>(N) doesn't work properly with f-e-r, and I'm not sure why. I'm not\n>> talking about your last patch where you compute * -- that works fine;\n>> it's just that %>(N) doesn't when N is a concrete number.\n>\n> Try this:\n>\n> %(refname:short)%>(30)%(upstream:short)\n>\n> (assuming that you have lots of branches). I'm noticing random\n> alignment problems.\n\nIt's because you don't pad enough spaces after %(refname:short) so the\nstarting point of %(upstream:short) on each line is already unaligned,\nI think. Try this:\n\n%<(*)%(refname:short)%>(30)%(upstream:short)\n\nor if you prefer at specific column (e.g. align upstream close to the\n60th column, regardless of refname's length):\n\n%(refname:short)%>|(60)%(upstream:short)\n--\nDuy\n"},{"id":"218723","messageId":"CACsJy8CyocXvjqM5BYgdnhYJPB8wyZ2+qcM9_7EU-WDmw+F5Qw@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0k=2NZsbSnxS50w+bux8q9mZh7GZzpCqhTP=2jqyHnBSg@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-29T03:22:57Z","receivedAt":"2013-05-29T03:22:57Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, May 28, 2013 at 9:01 PM, Ramkumar Ramachandra\n wrote:\n> Also, a couple of minor annoyances:\n>\n> 1. When f-e-r is invoked with refs/tags, we get stray output. Atleast\n> it doesn't segfault, thanks to your ignore-commit patch. Maybe\n> printing stray output is the right thing to do, as opposed to erroring\n> out.\n\nWhat format did you use?\n\n> 2. %>(*) only works with f-e-r atoms, not with pretty-format atoms.\n> This is ofcourse obvious from the implementation, but isn't it a\n> little consistent?\n\nIt is not. I think it's documented as well as a known implementation\nlimitation. It's not hard to be fixed (we could call\nformat_commit_message again for all entries, this time with a single\nplaceholder, to collect the best width). If anybody does need %>(*)%H\nto work, we could do it. BTW, the way I implement get_atom_width() is\nnot really optimal. For n lines, we call print_value() in\nget_atom_width n^2 times. We could cache the calculated width instead\nand reduce that to n times.\n\n> Should we start off a new pretty-ref-formats document, where we\n> explicitly exclude things like %ae (because of the hex overriding\n> thing)? I don't think it's a problem if documented properly.\n\nAnd this one is doucmented as well, I think. I'd really like to\nintroduce a new --pretty option (or something) that does not accept\n%xx as a hex notion, so %ae and friends won't be hidden. It's also a\ngood thing for compatibility because currently %H in --format produces\n%H. After this, %H produces something else. It's unlikely that anybody\nhas done that. But it's even better if we avoid that possibility\nentirely with a new option.\n--\nDuy\n"},{"id":"218900","messageId":"CALkWK0nQvCJkf3nOEZqT3yy_m7jvCPxHSnY-9_QSUaPXDmJWjA@mail.gmail.com","threadId":"33919","inReplyTo":"CACsJy8Dvpn0u1i8M7uxsB=t4NE5v78=gYiY=XFC=KK7f4D=N=w@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T21:12:24Z","receivedAt":"2013-05-29T21:12:24Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> It's because you don't pad enough spaces after %(refname:short) so the\n> starting point of %(upstream:short) on each line is already unaligned,\n> I think.\n\nYeah, my stupidity. I really meant %>|(30), and that works fine.\n"},{"id":"218932","messageId":"CACsJy8DA4oCj3WPmJY6aA7Gq3Xx4xqZ2XxxiZUuR6TqgK=f6Ww@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0nFDdfGKeRqKKTTMSm4zqHDOt_iGc1aA7LgD9=y2DJO5A@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-30T04:19:41Z","receivedAt":"2013-05-30T04:19:41Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, May 28, 2013 at 9:24 PM, Ramkumar Ramachandra\n wrote:\n> Oh, and by the way:\n>\n> We're pretty close we are to replacing branch -v and branch -vv.\n>\n> brv = for-each-ref --format='%(HEAD)\n> %C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)\n> %(subject)' refs/heads\n>\n> brvv = for-each-ref --format='%(HEAD)\n> %C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)\n> %C(blue)%(upstream:short)%C(reset) %(subject)' refs/heads\n>\n> There are small differences:\n>\n> 1. In branch -v, the green-color of the branch name is dependent on\n> %(HEAD). Not worth ironing out, in my opinion.\n>\n> 2. In branch -vv, there are dependent square braces that come on when\n> %(refname:short) is set. We might want to introduce an undocumented\n> %(refname:branchvv) for internal use by branch -vv, for backward\n> compatibility.\n>\n> What do you think?\n\nI think we can change -v and -vv format slightly as long as the\ninformation remains the same. Nobody should ever parse these output\nwith scripts. The color can be generated from color.branch.*. A bigger\nproblem is show_detached(), --[no-]merged, --with and --contains. We\nneed to move some of those code over to for-each-ref. Another problem\nis the new \"branch -v\" seems to less responsive than old \"branch -v\"\nbecause (I think) of sorting, even if we don't need it. I checked out\nyour branch, made some more updates and pushed out to my\nfor-each-ref-pretty again. Changes are:\n\n - fix segfault with \"for-each-ref --format=%something refs/tags/'\n - add --pretty for new format syntax and keep --format unchanged\n - add --[no-]column to for-each-ref (for \"git branch\" with no arguments)\n - remove branch listing code and use for-each-ref instead (41\ninserts, 378 deletes, beautiful).\n - add --sort and --count to git-branch\n--\nDuy\n"},{"id":"219366","messageId":"CALkWK0kGrCDhDFL5THBTTVARTnfY2xucbJaGJGKj8OYv3Q1pBA@mail.gmail.com","threadId":"33919","inReplyTo":"CACsJy8DA4oCj3WPmJY6aA7Gq3Xx4xqZ2XxxiZUuR6TqgK=f6Ww@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-04T12:52:15Z","receivedAt":"2013-06-04T12:52:15Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> Nobody should ever parse these output\n> with scripts. The color can be generated from color.branch.*.\n\nHow do we implement color.branch.(current|local|remote|plain)? In the\ncurrent code, we take a crude approach by hand-constructing argc, argv\nstrings and passing it to cmd_for_each_ref(). There are no\nconditionals in the format syntax (and introducing one is probably not\na good idea either): so, I'm guessing these configuration variables\nhave to be read by for-each-ref?\n\n> A bigger\n> problem is show_detached(), --[no-]merged, --with and --contains. We\n> need to move some of those code over to for-each-ref.\n\nI saw that you fixed this.\n\n> Another problem\n> is the new \"branch -v\" seems to less responsive than old \"branch -v\"\n> because (I think) of sorting, even if we don't need it.\n\nDoes your track-responsiveness patch fix this?\n\n> I checked out\n> your branch, made some more updates and pushed out to my\n> for-each-ref-pretty again. Changes are:\n\n*pants* Sorry, I'm finding it hard to keep up.\n"},{"id":"219369","messageId":"CACsJy8BpeP0y+wFbNJioR-TwyV1P77moz0x2ZDXzqz2ZKWTahg@mail.gmail.com","threadId":"33919","inReplyTo":"CALkWK0kGrCDhDFL5THBTTVARTnfY2xucbJaGJGKj8OYv3Q1pBA@mail.gmail.com","subject":"Re: [PATCH v2 0/3] Towards a useable git-branch","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-04T13:11:25Z","receivedAt":"2013-06-04T13:11:25Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jun 4, 2013 at 7:52 PM, Ramkumar Ramachandra wrote:\n> Duy Nguyen wrote:\n>> Nobody should ever parse these output\n>> with scripts. The color can be generated from color.branch.*.\n>\n> How do we implement color.branch.(current|local|remote|plain)? In the\n> current code, we take a crude approach by hand-constructing argc, argv\n> strings and passing it to cmd_for_each_ref(). There are no\n> conditionals in the format syntax (and introducing one is probably not\n> a good idea either): so, I'm guessing these configuration variables\n> have to be read by for-each-ref?\n\nMaybe. I don't really like the idea that for-each-ref reads _branch_\nconfig. We could introduce the same set of keys but in\ncolor.for-each-ref namespace. %C(auto) will take care of the logic and\nchoose the correct color key. When we replace branch's listing code\nwith for-each-ref, I think we could somehow override for-each-ref keys\nwith branch ones in-core. Too hacky?\n\n>> A bigger\n>> problem is show_detached(), --[no-]merged, --with and --contains. We\n>> need to move some of those code over to for-each-ref.\n>\n> I saw that you fixed this.\n\nNope. --[no-]merged and --contains seem easy. show_detached is still\nWIP, mostly because detached HEAD may or may not show when you provide\na pattern to git-branch (e.g. git branch --list 'foo*') and because\nHEAD is always the first item, regardless of sorting order.\nget_head_description also seems more porcelain-ish than a plumbing\nfeature..\n\n>> Another problem\n>> is the new \"branch -v\" seems to less responsive than old \"branch -v\"\n>> because (I think) of sorting, even if we don't need it.\n>\n> Does your track-responsiveness patch fix this?\n\nYes.\n\n>> I checked out\n>> your branch, made some more updates and pushed out to my\n>> for-each-ref-pretty again. Changes are:\n>\n> *pants* Sorry, I'm finding it hard to keep up.\n\nSorry that branch was in a better shape the day I sent my previous\nemail. Then I kind of used it as a playground with --[no-]merged,\n--contains and stuff :-P\n--\nDuy\n"}]}