{"thread":{"id":"33835","subject":"[PATCH] branch: add show-tracking option","startedAt":"2013-05-16T07:48:52Z","lastAt":"2013-05-16T16:33:23Z","messageCount":14,"participants":["Felipe Contreras","Duy Nguyen","Michael J Gruber","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"217517","messageId":"1368690532-12093-1-git-send-email-felipe.contreras@gmail.com","threadId":"33835","inReplyTo":null,"subject":"[PATCH] branch: add show-tracking option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:48:52Z","receivedAt":"2013-05-16T07:48:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Showing the tracking information for all the branches takes significant\namount of time. The user might not want that. The --no-show-tracking\noption allows that.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n Documentation/git-branch.txt | 5 ++++-\n builtin/branch.c             | 4 +++-\n 2 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex b7cb625..1db04cd 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -9,7 +9,7 @@ SYNOPSIS\n --------\n [verse]\n 'git branch' [--color[=<when>] | --no-color] [-r | -a]\n-\t[--list] [-v [--abbrev=<length> | --no-abbrev]]\n+\t[--list] [-v [--abbrev=<length> | --no-abbrev] --show-tracking]\n \t[--column[=<options>] | --no-column]\n \t[(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]\n 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n@@ -154,6 +154,9 @@ This option is only applicable in non-verbose mode.\n --no-abbrev::\n \tDisplay the full sha1s in the output listing rather than abbreviating them.\n \n+--show-tracking::\n+\tDisplay the tracking information when using --verbose, or not.\n+\n -t::\n --track::\n \tWhen creating a new branch, set up configuration to mark the\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 0836890..2b586ea 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -33,6 +33,7 @@ static const char * const builtin_branch_usage[] = {\n \n static const char *head;\n static unsigned char head_sha1[20];\n+static int show_tracking = 1;\n \n static int branch_use_color = -1;\n static char branch_colors[][COLOR_MAXLEN] = {\n@@ -424,7 +425,7 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,\n \tstruct branch *branch = branch_get(branch_name);\n \tstruct strbuf fancy = STRBUF_INIT;\n \n-\tif (!stat_tracking_info(branch, &ours, &theirs)) {\n+\tif (!(show_tracking && stat_tracking_info(branch, &ours, &theirs))) {\n \t\tif (branch && branch->merge && branch->merge[0]->dst &&\n \t\t    show_upstream_ref) {\n \t\t\tref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n@@ -840,6 +841,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\topt_parse_merge_filter, (intptr_t) \"HEAD\",\n \t\t},\n \t\tOPT_COLUMN(0, \"column\", &colopts, N_(\"list branches in columns\")),\n+\t\tOPT_BOOL(0, \"show-tracking\", &show_tracking, N_(\"show tracking information\")),\n \t\tOPT_END(),\n \t};\n \n-- \n1.8.3.rc1.579.g184e698\n"},{"id":"217518","messageId":"CAMP44s3_3JRz0vYpm5uvnAOgt=hH=DTTiB1xn9dQiK9swaANVQ@mail.gmail.com","threadId":"33835","inReplyTo":"1368690532-12093-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:51:46Z","receivedAt":"2013-05-16T07:51:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 2:48 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> Showing the tracking information for all the branches takes significant\n> amount of time. The user might not want that. The --no-show-tracking\n> option allows that.\n\nBTW. I ideally I would switch around so -v has upstream, and --vv has\nthe tracking information. But that is changing the behavior.\n\n-- \nFelipe Contreras\n"},{"id":"217519","messageId":"CACsJy8BnwFXsXYXPe7driH9q9e4otMuMvr4sJdLQWxhf0owCDA@mail.gmail.com","threadId":"33835","inReplyTo":"1368690532-12093-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-16T07:54:46Z","receivedAt":"2013-05-16T07:54:46Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> Showing the tracking information for all the branches takes significant\n> amount of time. The user might not want that. The --no-show-tracking\n> option allows that.\n\nOr we could cache the information somewhere in .git. If a ref still\npoints to <SHA-1> as recorded in the cache, use the cached tracking\ninformation, otherwise go the slow way.\n--\nDuy\n"},{"id":"217520","messageId":"CAMP44s2ht8nv9qJY-sbnHzScJkqNTkkB1ePSp++9rLBL-JrvEg@mail.gmail.com","threadId":"33835","inReplyTo":"CACsJy8BnwFXsXYXPe7driH9q9e4otMuMvr4sJdLQWxhf0owCDA@mail.gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:57:48Z","receivedAt":"2013-05-16T07:57:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 2:54 AM, Duy Nguyen <pclouds@gmail.com> wrote:\n> On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n>> Showing the tracking information for all the branches takes significant\n>> amount of time. The user might not want that. The --no-show-tracking\n>> option allows that.\n>\n> Or we could cache the information somewhere in .git. If a ref still\n> points to <SHA-1> as recorded in the cache, use the cached tracking\n> information, otherwise go the slow way.\n\nThat might be nice, but even if that was fast, I personally never use\nthat information, so I still would want this option.\n\n-- \nFelipe Contreras\n"},{"id":"217521","messageId":"5194921F.4080103@drmicha.warpmail.net","threadId":"33835","inReplyTo":"1368690532-12093-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-05-16T08:00:31Z","receivedAt":"2013-05-16T08:00:31Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:\n> Showing the tracking information for all the branches takes significant\n> amount of time. The user might not want that. The --no-show-tracking\n> option allows that.\n\nI really like the idea of allowing that - not just because I've\nsuggested so myself in the past ;)\n\nI feel, though, that we're really exploding our option and config realm.\nFor \"git branch\" in list mode, we are already able to stack \"-v\", i.e.\n\"-v\" and \"-vv\" do different things. How about maybe adding \"-vvv\" and\narranging things so that the verbosity and the run time increases with\nthe number of v's?\n\n-v list with sha1 + subject of last commit\n-vv add upstream branch name\n-vvv add ahead/behind info (the only costly mode)\n-vvvv same with \"--cherry\" (ahead/behind/same)\n\nOr maybe combine the middle two cases into \"-vv\", which means it would\nbe the same as \"-vv\", with only \"-v\" changing what it does now.\n\nYes, this changes current behavior (at least fpr -v), which sucks\nanyways because of the costly lookup. And those scripting around \"branch\n-v\" should get what they deserve. (I may sound annoyed by our\ncompatibility brakes, but here's a case where breaking it should be OK.)\n\n> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> ---\n>  Documentation/git-branch.txt | 5 ++++-\n>  builtin/branch.c             | 4 +++-\n>  2 files changed, 7 insertions(+), 2 deletions(-)\n> \n> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n> index b7cb625..1db04cd 100644\n> --- a/Documentation/git-branch.txt\n> +++ b/Documentation/git-branch.txt\n> @@ -9,7 +9,7 @@ SYNOPSIS\n>  --------\n>  [verse]\n>  'git branch' [--color[=<when>] | --no-color] [-r | -a]\n> -\t[--list] [-v [--abbrev=<length> | --no-abbrev]]\n> +\t[--list] [-v [--abbrev=<length> | --no-abbrev] --show-tracking]\n>  \t[--column[=<options>] | --no-column]\n>  \t[(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]\n>  'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n> @@ -154,6 +154,9 @@ This option is only applicable in non-verbose mode.\n>  --no-abbrev::\n>  \tDisplay the full sha1s in the output listing rather than abbreviating them.\n>  \n> +--show-tracking::\n> +\tDisplay the tracking information when using --verbose, or not.\n> +\n>  -t::\n>  --track::\n>  \tWhen creating a new branch, set up configuration to mark the\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 0836890..2b586ea 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -33,6 +33,7 @@ static const char * const builtin_branch_usage[] = {\n>  \n>  static const char *head;\n>  static unsigned char head_sha1[20];\n> +static int show_tracking = 1;\n>  \n>  static int branch_use_color = -1;\n>  static char branch_colors[][COLOR_MAXLEN] = {\n> @@ -424,7 +425,7 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,\n>  \tstruct branch *branch = branch_get(branch_name);\n>  \tstruct strbuf fancy = STRBUF_INIT;\n>  \n> -\tif (!stat_tracking_info(branch, &ours, &theirs)) {\n> +\tif (!(show_tracking && stat_tracking_info(branch, &ours, &theirs))) {\n>  \t\tif (branch && branch->merge && branch->merge[0]->dst &&\n>  \t\t    show_upstream_ref) {\n>  \t\t\tref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n> @@ -840,6 +841,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \t\t\topt_parse_merge_filter, (intptr_t) \"HEAD\",\n>  \t\t},\n>  \t\tOPT_COLUMN(0, \"column\", &colopts, N_(\"list branches in columns\")),\n> +\t\tOPT_BOOL(0, \"show-tracking\", &show_tracking, N_(\"show tracking information\")),\n>  \t\tOPT_END(),\n>  \t};\n>  \n> \n"},{"id":"217522","messageId":"CAMP44s3s_Tg=FX8emOC1Gs_LqPU-i-mWNswoOT82MkNBUUsjUA@mail.gmail.com","threadId":"33835","inReplyTo":"5194921F.4080103@drmicha.warpmail.net","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T08:09:34Z","receivedAt":"2013-05-16T08:09:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:\n>> Showing the tracking information for all the branches takes significant\n>> amount of time. The user might not want that. The --no-show-tracking\n>> option allows that.\n>\n> I really like the idea of allowing that - not just because I've\n> suggested so myself in the past ;)\n>\n> I feel, though, that we're really exploding our option and config realm.\n> For \"git branch\" in list mode, we are already able to stack \"-v\", i.e.\n> \"-v\" and \"-vv\" do different things. How about maybe adding \"-vvv\" and\n> arranging things so that the verbosity and the run time increases with\n> the number of v's?\n>\n> -v list with sha1 + subject of last commit\n> -vv add upstream branch name\n> -vvv add ahead/behind info (the only costly mode)\n> -vvvv same with \"--cherry\" (ahead/behind/same)\n\nYeah, I thought about that too.\n\n> Or maybe combine the middle two cases into \"-vv\", which means it would\n> be the same as \"-vv\", with only \"-v\" changing what it does now.\n\nPlease no, I would like to see 'upstream', but not ahead/behind info.\nIn fact, that's my whole motivation behind this patch.\n\n> Yes, this changes current behavior (at least fpr -v), which sucks\n> anyways because of the costly lookup. And those scripting around \"branch\n> -v\" should get what they deserve. (I may sound annoyed by our\n> compatibility brakes, but here's a case where breaking it should be OK.)\n\nI also agree that it would be OK to break this.\n\nAlternatively, I've been thinking that we should have a v2.0 mode, or\na v2.0 branch, where all the compatibility breakage things go. We have\nbeen so careful at not breaking things, that we have been too good at\nstacking hacks and configurations all over the place, and in my\nexperience it's not unusual that right after an incompatibility\nrelease, someone realizes that we forgot some compat breakage things,\nand oh, well, maybe for v3.0.\n\nThe ones I have in mind are:\n\ncolor.ui=true\nmerge.defaulttoupstream=true\nformat.coverletter=auto\nbranch.autosetupmerge=always\nmergetool.prompt=false\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"217524","messageId":"51949768.5020305@drmicha.warpmail.net","threadId":"33835","inReplyTo":"CAMP44s3s_Tg=FX8emOC1Gs_LqPU-i-mWNswoOT82MkNBUUsjUA@mail.gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-05-16T08:23:04Z","receivedAt":"2013-05-16T08:23:04Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Felipe Contreras venit, vidit, dixit 16.05.2013 10:09:\n> On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:\n>>> Showing the tracking information for all the branches takes significant\n>>> amount of time. The user might not want that. The --no-show-tracking\n>>> option allows that.\n>>\n>> I really like the idea of allowing that - not just because I've\n>> suggested so myself in the past ;)\n>>\n>> I feel, though, that we're really exploding our option and config realm.\n>> For \"git branch\" in list mode, we are already able to stack \"-v\", i.e.\n>> \"-v\" and \"-vv\" do different things. How about maybe adding \"-vvv\" and\n>> arranging things so that the verbosity and the run time increases with\n>> the number of v's?\n>>\n>> -v list with sha1 + subject of last commit\n>> -vv add upstream branch name\n>> -vvv add ahead/behind info (the only costly mode)\n>> -vvvv same with \"--cherry\" (ahead/behind/same)\n> \n> Yeah, I thought about that too.\n> \n>> Or maybe combine the middle two cases into \"-vv\", which means it would\n>> be the same as \"-vv\", with only \"-v\" changing what it does now.\n> \n> Please no, I would like to see 'upstream', but not ahead/behind info.\n> In fact, that's my whole motivation behind this patch.\n\nI'd be fine with combining the first two also.\n\n>> Yes, this changes current behavior (at least fpr -v), which sucks\n>> anyways because of the costly lookup. And those scripting around \"branch\n>> -v\" should get what they deserve. (I may sound annoyed by our\n>> compatibility brakes, but here's a case where breaking it should be OK.)\n> \n> I also agree that it would be OK to break this.\n> \n> Alternatively, I've been thinking that we should have a v2.0 mode, or\n> a v2.0 branch, where all the compatibility breakage things go. We have\n> been so careful at not breaking things, that we have been too good at\n> stacking hacks and configurations all over the place, and in my\n> experience it's not unusual that right after an incompatibility\n> release, someone realizes that we forgot some compat breakage things,\n> and oh, well, maybe for v3.0.\n> \n> The ones I have in mind are:\n> \n> color.ui=true\n> merge.defaulttoupstream=true\n> format.coverletter=auto\n> branch.autosetupmerge=always\n> mergetool.prompt=false\n> \n> Cheers.\n\nYes. Additionally, there are things which we can break during normal\nreleases, but somehow the compatibility discussions have kept us from\ndoing so. Maybe we need a clearer separation of porcellain and plumbing\nagain? Or a clearer definition of x, y, z in x.y.z releases? We haven't\neven used y increases for incompatible ui changes that much.\n\nMichael\n"},{"id":"217525","messageId":"CACsJy8CrGTa2XdfFkkKDQQjF8gM3011RiUE6roe9L7yZZq5J2g@mail.gmail.com","threadId":"33835","inReplyTo":"5194921F.4080103@drmicha.warpmail.net","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-16T08:23:18Z","receivedAt":"2013-05-16T08:23:18Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> I feel, though, that we're really exploding our option and config realm.\n> For \"git branch\" in list mode, we are already able to stack \"-v\", i.e.\n> \"-v\" and \"-vv\" do different things. How about maybe adding \"-vvv\" and\n> arranging things so that the verbosity and the run time increases with\n> the number of v's?\n>\n> -v list with sha1 + subject of last commit\n> -vv add upstream branch name\n> -vvv add ahead/behind info (the only costly mode)\n> -vvvv same with \"--cherry\" (ahead/behind/same)\n>\n> Or maybe combine the middle two cases into \"-vv\", which means it would\n> be the same as \"-vv\", with only \"-v\" changing what it does now.\n\nWhat if I want something in -vvvv except some in -vv? I think to avoid\noption explosion, maybe we can adopt --pretty=format:xxx from \"git\nlog\" and let the user decideswhat (and how) to display. \"pretty\" code\nlearns about alignment already, which may be useful here.\n--\nDuy\n"},{"id":"217537","messageId":"51949B85.40600@drmicha.warpmail.net","threadId":"33835","inReplyTo":"CACsJy8CrGTa2XdfFkkKDQQjF8gM3011RiUE6roe9L7yZZq5J2g@mail.gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-05-16T08:40:37Z","receivedAt":"2013-05-16T08:40:37Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Duy Nguyen venit, vidit, dixit 16.05.2013 10:23:\n> On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> I feel, though, that we're really exploding our option and config realm.\n>> For \"git branch\" in list mode, we are already able to stack \"-v\", i.e.\n>> \"-v\" and \"-vv\" do different things. How about maybe adding \"-vvv\" and\n>> arranging things so that the verbosity and the run time increases with\n>> the number of v's?\n>>\n>> -v list with sha1 + subject of last commit\n>> -vv add upstream branch name\n>> -vvv add ahead/behind info (the only costly mode)\n>> -vvvv same with \"--cherry\" (ahead/behind/same)\n>>\n>> Or maybe combine the middle two cases into \"-vv\", which means it would\n>> be the same as \"-vv\", with only \"-v\" changing what it does now.\n> \n> What if I want something in -vvvv except some in -vv? I think to avoid\n> option explosion, maybe we can adopt --pretty=format:xxx from \"git\n> log\" and let the user decideswhat (and how) to display. \"pretty\" code\n> learns about alignment already, which may be useful here.\n> --\n> Duy\n\nSure, that is the big solution we've been talking about. Unify\nfor-each-ref formats and log formats and use that. After all, \"git\nbranch\" in list mode really is for-each-ref, and should be transparently\nso; same goes for \"git tag\". Think \"git rev-list\" and \"git ref-list\"!\n\nBut I guess we'll be compabeaten ;)\n\nMichael\n"},{"id":"217541","messageId":"CACsJy8D_5YE3w4WNvCA8-fA-y5DV2WqHULqcMYqd7X_SSh_aHw@mail.gmail.com","threadId":"33835","inReplyTo":"51949B85.40600@drmicha.warpmail.net","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-16T08:56:33Z","receivedAt":"2013-05-16T08:56:33Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 16, 2013 at 3:40 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n>> What if I want something in -vvvv except some in -vv? I think to avoid\n>> option explosion, maybe we can adopt --pretty=format:xxx from \"git\n>> log\" and let the user decideswhat (and how) to display. \"pretty\" code\n>> learns about alignment already, which may be useful here.\n>> --\n>> Duy\n>\n> Sure, that is the big solution we've been talking about. Unify\n> for-each-ref formats and log formats and use that. After all, \"git\n> branch\" in list mode really is for-each-ref, and should be transparently\n> so; same goes for \"git tag\". Think \"git rev-list\" and \"git ref-list\"!\n\nAgain I forgot about for-each-ref. Sounds like sharing code between\nfor-each-ref and branch is a good thing to do. Then just add more\ncandy placeholders from git-log like %C(xx). Sounds like a fun topic.\n\n> But I guess we'll be compabeaten ;)\n\nNo idea what that last word means :(\n--\nDuy\n"},{"id":"217616","messageId":"7v1u9699x7.fsf@alter.siamese.dyndns.org","threadId":"33835","inReplyTo":"CACsJy8D_5YE3w4WNvCA8-fA-y5DV2WqHULqcMYqd7X_SSh_aHw@mail.gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T16:17:08Z","receivedAt":"2013-05-16T16:17:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n> On Thu, May 16, 2013 at 3:40 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>>> What if I want something in -vvvv except some in -vv? I think to avoid\n>>> option explosion, maybe we can adopt --pretty=format:xxx from \"git\n>>> log\" and let the user decideswhat (and how) to display. \"pretty\" code\n>>> learns about alignment already, which may be useful here.\n>>> --\n>>> Duy\n>>\n>> Sure, that is the big solution we've been talking about. Unify\n>> for-each-ref formats and log formats and use that. After all, \"git\n>> branch\" in list mode really is for-each-ref, and should be transparently\n>> so; same goes for \"git tag\". Think \"git rev-list\" and \"git ref-list\"!\n>\n> Again I forgot about for-each-ref. Sounds like sharing code between\n> for-each-ref and branch is a good thing to do. Then just add more\n> candy placeholders from git-log like %C(xx). Sounds like a fun topic.\n>\n>> But I guess we'll be compabeaten ;)\n>\n> No idea what that last word means :(\n\nMe either, but I agree that \"verbosity level\" is a bad match for\nthis kind of thing.\n\nYou need to be able to pick and choose what are shown, and the user\npreferences are not a linear progression that can be expressed with\na simple number of 'v's.\n\nYou may not need the level of flexibility the format string gives\nyou to choose not just what are shown but how they are shown, but if\nwe can teach the internal machinery of for-each-ref to compute the\nkind of information it does not currently know, reusing the mechanism\nwill give us the output for free.\n\nWhat are the current repertoire that we can pick from?\n\n * HEADness\n * branch name\n * abbreviated object name of the tip commit\n * name of @{u}\n   * ahead/behind [*1*]\n * title of the tip commit\n\nSo the current \"-v -v\" format may look something like this:\n\n    %(headness)%(refname:short)%(objectname:short)%(upstream)%(subject)\n\nwhere\n\n    %(headness) expands to either \"  \" or \"* \"\n    %(upstream) expands to \"[remotes/origin/master: ahead 2, behind 47] \"\n\nThe more expensive \": ahead 2, behind 47\" can be omitted by spelling\n%(upstream:short), for example.\n\n\n[Footnote]\n\n*1* indented because this is dependent of @{u}; showing ahead/behind\n    without showing @{u} would not make any sense.\n"},{"id":"217619","messageId":"CAMP44s3cjO4ETd+_oQB=afxDuWZb+HBDEOA2sdHfFQ10+y9foQ@mail.gmail.com","threadId":"33835","inReplyTo":"7v1u9699x7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T16:28:45Z","receivedAt":"2013-05-16T16:28:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> *1* indented because this is dependent of @{u}; showing ahead/behind\n>     without showing @{u} would not make any sense.\n\nThat's what 'git branch -v' does.\n\n-- \nFelipe Contreras\n"},{"id":"217621","messageId":"7vhai27uol.fsf@alter.siamese.dyndns.org","threadId":"33835","inReplyTo":"CAMP44s3cjO4ETd+_oQB=afxDuWZb+HBDEOA2sdHfFQ10+y9foQ@mail.gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T16:31:38Z","receivedAt":"2013-05-16T16:31:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> *1* indented because this is dependent of @{u}; showing ahead/behind\n>>     without showing @{u} would not make any sense.\n>\n> That's what 'git branch -v' does.\n\nYes.  I thought you wanted \"just @{u} without ahead/behind\", no?\n"},{"id":"217623","messageId":"7vd2sq7ulo.fsf@alter.siamese.dyndns.org","threadId":"33835","inReplyTo":"CAMP44s3cjO4ETd+_oQB=afxDuWZb+HBDEOA2sdHfFQ10+y9foQ@mail.gmail.com","subject":"Re: [PATCH] branch: add show-tracking option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T16:33:23Z","receivedAt":"2013-05-16T16:33:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> *1* indented because this is dependent of @{u}; showing ahead/behind\n>>     without showing @{u} would not make any sense.\n>\n> That's what 'git branch -v' does.\n\nOK, perhaps people know (or do not have to know) what @{u} is and\nfind ahead/behind still useful?  In any case, this need to be\nseparate and independent item, as we would want to be able to\nexpress what we currently show in the updated system.\n\nThanks for a sanity check.\n"}]}