{"thread":{"id":"23667","subject":"[PATCH] Show branch information in short output of git status","startedAt":"2010-05-02T09:13:41Z","lastAt":"2010-05-25T09:47:14Z","messageCount":13,"participants":["Knittl","Jeff King","Michael J Gruber","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"140745","messageId":"AANLkTikM3B-9wFBuUzwpP2j9FpT34p9yysX-oLg5hZRj@mail.gmail.com","threadId":"23667","inReplyTo":null,"subject":"[PATCH] Show branch information in short output of git status","fromName":"Knittl","fromEmail":"knittl89@googlemail.com","sentAt":"2010-05-02T09:13:41Z","receivedAt":"2010-05-02T09:13:41Z","isPatch":true,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"This patch adds a first line in the output of `git status -s`, showing\nwhich branch the user is currently on, and in case of tracking branches\nthe number of commits on each branch.\n\nSigned-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>\n---\n wt-status.c |   45 +++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 45 insertions(+), 0 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 8ca59a2..2e6c56e 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -9,6 +9,7 @@\n #include \"quote.h\"\n #include \"run-command.h\"\n #include \"remote.h\"\n+#include \"refs.h\"\n\n static char default_wt_status_colors[][COLOR_MAXLEN] = {\n \tGIT_COLOR_NORMAL, /* WT_STATUS_HEADER */\n@@ -721,9 +722,53 @@ static void wt_shortstatus_untracked(int\nnull_termination, struct string_list_it\n \t}\n }\n\n+static void wt_shortstatus_print_tracking(struct wt_status *s)\n+{\n+\tstruct branch *branch;\n+\tconst char *branch_color = color(WT_STATUS_HEADER, s);\n+\n+\tconst char *base;\n+\tconst char *branch_name;\n+\tint num_ours, num_theirs;\n+\n+\tcolor_fprintf(s->fp, color(WT_STATUS_HEADER, s), \"## \");\n+\n+\tif(!s->branch) return;\n+\tbranch_name = s->branch;\n+\n+\tif (!prefixcmp(branch_name, \"refs/heads/\"))\n+\t\tbranch_name += 11;\n+\telse if (!strcmp(branch_name, \"HEAD\")) {\n+\t\tbranch_color = color(WT_STATUS_NOBRANCH, s);\n+\t}\n+\n+\tbranch = branch_get(s->branch + 11);\n+\tif (!stat_tracking_info(branch, &num_ours, &num_theirs)) {\n+\n+\t\tif(s->is_initial) {\n+\t\t\tcolor_fprintf(s->fp,\n+\t\t\t\tcolor(WT_STATUS_HEADER, s),\n+\t\t\t\t\"Initial commit ... \");\n+\t\t}\n+\t\tcolor_fprintf_ln(s->fp, branch_color,\n+\t\t\t\"%s\", branch_name);\n+\t\treturn;\n+\t}\n+\n+\tbase = branch->merge[0]->dst;\n+\tbase = shorten_unambiguous_ref(base, 0);\n+\tcolor_fprintf_ln(s->fp, branch_color,\n+\t\t\t\"%s (%d) ... %s (%d)\",\n+\t\t\tbranch_name, num_ours,\n+\t\t\tbase, num_theirs);\n+}\n+\n void wt_shortstatus_print(struct wt_status *s, int null_termination)\n {\n \tint i;\n+\n+\twt_shortstatus_print_tracking(s);\n+\n \tfor (i = 0; i < s->change.nr; i++) {\n \t\tstruct wt_status_change_data *d;\n \t\tstruct string_list_item *it;\n-- \n1.7.1.rc2.6.g1015.dirty\n\n\n-- \ntyped with http://neo-layout.org\nmyFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!\n"},{"id":"140962","messageId":"20100505050640.GC8779@coredump.intra.peff.net","threadId":"23667","inReplyTo":"AANLkTikM3B-9wFBuUzwpP2j9FpT34p9yysX-oLg5hZRj@mail.gmail.com","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-05T05:06:40Z","receivedAt":"2010-05-05T05:06:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, May 02, 2010 at 11:13:41AM +0200, Knittl wrote:\n\n> This patch adds a first line in the output of `git status -s`, showing\n> which branch the user is currently on, and in case of tracking branches\n> the number of commits on each branch.\n\nI don't generally use \"git status -s\", so I don't have a strong opinion,\nbut should this perhaps be optional?  I imagine people using it fall\ninto one of two categories:\n\n  1. They want to waste less vertical screen real estate than \"git\n     status\" does.\n\n  2. They prefer to see files in a single list with status marked,\n     rather than in separate lists based on status.\n\nYour patch will probably annoy people in group (1) unless they have some\nway to turn it off.\n\nA few other comments on the patch itself:\n\n> +\tcolor_fprintf(s->fp, color(WT_STATUS_HEADER, s), \"## \");\n\nI thought the doubled '##' looked funny at first, but the more I look at\nit, I think lining it up with the filenames looks good.\n\n> +\tif(!s->branch) return;\n\nStyle nits. This should be:\n\n  if (!s->branch)\n          return;\n\n> +\tbranch = branch_get(s->branch + 11);\n> +\tif (!stat_tracking_info(branch, &num_ours, &num_theirs)) {\n> +\n> +\t\tif(s->is_initial) {\n> +\t\t\tcolor_fprintf(s->fp,\n> +\t\t\t\tcolor(WT_STATUS_HEADER, s),\n> +\t\t\t\t\"Initial commit ... \");\n> +\t\t}\n> +\t\tcolor_fprintf_ln(s->fp, branch_color,\n> +\t\t\t\"%s\", branch_name);\n> +\t\treturn;\n> +\t}\n\nWhy do we only mention it as an initial commit if there is no tracking?\nWe get if it is an initial commit and no tracking:\n\n  ## Initial commit ... master\n\nbut if there is a tracking branch setup, we get no \"Initial commit\" at\nall. And the use of \"...\" is confusing, as it usually implies symmetric\ndifference, which doesn't really make sense here.\n\n> +\tbase = branch->merge[0]->dst;\n> +\tbase = shorten_unambiguous_ref(base, 0);\n> +\tcolor_fprintf_ln(s->fp, branch_color,\n> +\t\t\t\"%s (%d) ... %s (%d)\",\n> +\t\t\tbranch_name, num_ours,\n> +\t\t\tbase, num_theirs);\n> +}\n\nHere we get:\n\n  ## master (1) ... origin/master (1)\n\nwhich kind of makes sense. The \"...\" implies symmetric difference. But\nin other spots, like \"git fetch\" and \"git push\" output, we usually try\nto make it cut-and-pastable in case one wants to view the actual\nhistory. So maybe something like:\n\n  ## master...origin/master [ahead 1, behind 1]\n\nThe latter matches how \"git branch -v\" prints it. I dunno. I guess this\nis just bikeshedding really, so maybe others will chime in with\nsuggestions and you can pick the one you like best.\n\n-Peff\n"},{"id":"141067","messageId":"AANLkTikDkrNrzPmIhmcBRKtLKV70f4Kp8wTw6I6ctB4O@mail.gmail.com","threadId":"23667","inReplyTo":"20100505050640.GC8779@coredump.intra.peff.net","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Knittl","fromEmail":"knittl89@googlemail.com","sentAt":"2010-05-06T12:24:41Z","receivedAt":"2010-05-06T12:24:41Z","isPatch":true,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"Hi jeff,\n\nthank you for your response and your comments.\n\nOn Wed, May 5, 2010 at 7:06 AM, Jeff King <peff@peff.net> wrote:\n> On Sun, May 02, 2010 at 11:13:41AM +0200, Knittl wrote:\n>\n>> This patch adds a first line in the output of `git status -s`, showing\n>> which branch the user is currently on, and in case of tracking branches\n>> the number of commits on each branch.\n>\n> I don't generally use \"git status -s\", so I don't have a strong opinion,\n> but should this perhaps be optional?  I imagine people using it fall\n> into one of two categories:\n>\n>  1. They want to waste less vertical screen real estate than \"git\n>     status\" does.\n\nit's one line ;) but i can understand your concern. would `git status\n-s -v` or `git status -s --show-branch` make sense?\n\n>  2. They prefer to see files in a single list with status marked,\n>     rather than in separate lists based on status.\n>\n> Your patch will probably annoy people in group (1) unless they have some\n> way to turn it off.\n>\n> A few other comments on the patch itself:\n>\n>> +     color_fprintf(s->fp, color(WT_STATUS_HEADER, s), \"## \");\n>\n> I thought the doubled '##' looked funny at first, but the more I look at\n> it, I think lining it up with the filenames looks good.\n\ni had one hash and two spaces at first, but as you said, two hashes\nlook more lined up.\n\n>> +     if(!s->branch) return;\n>\n> Style nits. This should be:\n>\n>  if (!s->branch)\n>          return;\n\ndone …\n\n>> +     branch = branch_get(s->branch + 11);\n>> +     if (!stat_tracking_info(branch, &num_ours, &num_theirs)) {\n>> +\n>> +             if(s->is_initial) {\n>> +                     color_fprintf(s->fp,\n>> +                             color(WT_STATUS_HEADER, s),\n>> +                             \"Initial commit ... \");\n>> +             }\n>> +             color_fprintf_ln(s->fp, branch_color,\n>> +                     \"%s\", branch_name);\n>> +             return;\n>> +     }\n>\n> Why do we only mention it as an initial commit if there is no tracking?\n> We get if it is an initial commit and no tracking:\n\ni don't think it's (easily, without messing around with the .git\ndirectory) possible to create a branch without commits that tracks\nanother branch (without commits). or is it?\n\n>  ## Initial commit ... master\n>\n> but if there is a tracking branch setup, we get no \"Initial commit\" at\n> all. And the use of \"...\" is confusing, as it usually implies symmetric\n> difference, which doesn't really make sense here.\n\ni used ... to make it look consistent with normal branch output, but i\nguess you are right. i changed it to `Initial commit on <branchname>\n\n>> +     base = branch->merge[0]->dst;\n>> +     base = shorten_unambiguous_ref(base, 0);\n>> +     color_fprintf_ln(s->fp, branch_color,\n>> +                     \"%s (%d) ... %s (%d)\",\n>> +                     branch_name, num_ours,\n>> +                     base, num_theirs);\n>> +}\n>\n> Here we get:\n>\n>  ## master (1) ... origin/master (1)\n>\n> which kind of makes sense. The \"...\" implies symmetric difference. But\n> in other spots, like \"git fetch\" and \"git push\" output, we usually try\n> to make it cut-and-pastable in case one wants to view the actual\n> history. So maybe something like:\n>\n>  ## master...origin/master [ahead 1, behind 1]\n>\n> The latter matches how \"git branch -v\" prints it. I dunno. I guess this\n> is just bikeshedding really, so maybe others will chime in with\n> suggestions and you can pick the one you like best.\n\noh, i didn't know `git branch -v`. the cut&paste argument is really\nstrong, so i totally agree with you and changed my code.\n\nbranch names and ahead/behind numbers appear now in green and red to\nmatch the output of `git branch -l`\n\nhere is the updated patch:\n\n - initial commit is also printed when there is tracking information\n(i still haven't managed to create a situation like that. `git branch\noldmaster; rm .git/refs/heads/master; git branch master --set-upstream\noldmaster` will reset branch master to oldmaster (a bug?))\n - colors to match output of `git branch` (green: current, red: remote)\n - output format is copy-pasteable, ahead/behind information is in the\nsame format as in `git branch -v`\n - branch information is still printed by default, i have to look into\ncommandline option parsing first. i was thinking of `git status -v -b`\n(as in `git checkout -b` to mean branch)\n\ncheers, daniel\n\n(i forgot to send my reply to the mailing list too …)\n\n---------8<----------------\nFrom 82b4481d38ae0cd62030aeea67160656b7c763e2 Mon Sep 17 00:00:00 2001\nFrom: Daniel Knittl-Frank <knittl89+git@googlemail.com>\nDate: Tue, 20 Apr 2010 22:40:54 +0200\nSubject: [PATCH] Show branch information in short output of git status\n\nThis patch adds a first line in the output of `git status -s`, showing\nwhich branch the user is currently on, and in case of tracking branches\nthe number of commits on each branch.\n\nSigned-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>\n---\n wt-status.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n wt-status.h |    4 ++-\n 2 files changed, 66 insertions(+), 1 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 8ca59a2..f7f1269 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -9,6 +9,7 @@\n #include \"quote.h\"\n #include \"run-command.h\"\n #include \"remote.h\"\n+#include \"refs.h\"\n\n static char default_wt_status_colors[][COLOR_MAXLEN] = {\n \tGIT_COLOR_NORMAL, /* WT_STATUS_HEADER */\n@@ -17,6 +18,8 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {\n \tGIT_COLOR_RED,    /* WT_STATUS_UNTRACKED */\n \tGIT_COLOR_RED,    /* WT_STATUS_NOBRANCH */\n \tGIT_COLOR_RED,    /* WT_STATUS_UNMERGED */\n+\tGIT_COLOR_GREEN,  /* WT_STATUS_LOCAL_BRANCH */\n+\tGIT_COLOR_RED,    /* WT_STATUS_REMOTE_BRANCH */\n };\n\n static const char *color(int slot, struct wt_status *s)\n@@ -721,9 +724,69 @@ static void wt_shortstatus_untracked(int\nnull_termination, struct string_list_it\n \t}\n }\n\n+static void wt_shortstatus_print_tracking(struct wt_status *s)\n+{\n+\tstruct branch *branch;\n+\tconst char *header_color = color(WT_STATUS_HEADER, s);\n+\tconst char *branch_color_local = color(WT_STATUS_LOCAL_BRANCH, s);\n+\tconst char *branch_color_remote = color(WT_STATUS_REMOTE_BRANCH, s);\n+\n+\tconst char *base;\n+\tconst char *branch_name;\n+\tint num_ours, num_theirs;\n+\n+\tcolor_fprintf(s->fp, color(WT_STATUS_HEADER, s), \"## \");\n+\n+\tif(!s->branch)\n+\t\treturn;\n+\tbranch_name = s->branch;\n+\n+\tif (!prefixcmp(branch_name, \"refs/heads/\"))\n+\t\tbranch_name += 11;\n+\telse if (!strcmp(branch_name, \"HEAD\")) {\n+\t\tbranch_name = \"HEAD (no branch)\";\n+\t\tbranch_color_local = color(WT_STATUS_NOBRANCH, s);\n+\t}\n+\n+\tbranch = branch_get(s->branch + 11);\n+\tif(s->is_initial) {\n+\t\tcolor_fprintf(s->fp, header_color, \"Initial commit on \");\n+\t}\n+\tif (!stat_tracking_info(branch, &num_ours, &num_theirs)) {\n+\t\tcolor_fprintf_ln(s->fp, branch_color_local,\n+\t\t\t\"%s\", branch_name);\n+\t\treturn;\n+\t}\n+\n+\tbase = branch->merge[0]->dst;\n+\tbase = shorten_unambiguous_ref(base, 0);\n+\tcolor_fprintf(s->fp, branch_color_local, \"%s\", branch_name);\n+\tcolor_fprintf(s->fp, header_color, \"...\");\n+\tcolor_fprintf(s->fp, branch_color_remote, \"%s\", base);\n+\n+\tcolor_fprintf(s->fp, header_color, \" [\");\n+\tif (!num_ours) {\n+\t\tcolor_fprintf(s->fp, header_color, \"behind \");\n+\t\tcolor_fprintf(s->fp, branch_color_remote, \"%d\", num_theirs);\n+\t} else if (!num_theirs) {\n+\t\tcolor_fprintf(s->fp, header_color, \"ahead \");\n+\t\tcolor_fprintf(s->fp, branch_color_local, \"%d\", num_ours);\n+\t} else {\n+\t\tcolor_fprintf(s->fp, header_color, \"ahead \");\n+\t\tcolor_fprintf(s->fp, branch_color_local, \"%d\", num_ours);\n+\t\tcolor_fprintf(s->fp, header_color, \", behind \");\n+\t\tcolor_fprintf(s->fp, branch_color_remote, \"%d\", num_theirs);\n+\t}\n+\n+\tcolor_fprintf_ln(s->fp, header_color, \"]\");\n+}\n+\n void wt_shortstatus_print(struct wt_status *s, int null_termination)\n {\n \tint i;\n+\n+\twt_shortstatus_print_tracking(s);\n+\n \tfor (i = 0; i < s->change.nr; i++) {\n \t\tstruct wt_status_change_data *d;\n \t\tstruct string_list_item *it;\ndiff --git a/wt-status.h b/wt-status.h\nindex 9120673..ca5db99 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -12,6 +12,8 @@ enum color_wt_status {\n \tWT_STATUS_UNTRACKED,\n \tWT_STATUS_NOBRANCH,\n \tWT_STATUS_UNMERGED,\n+\tWT_STATUS_LOCAL_BRANCH,\n+\tWT_STATUS_REMOTE_BRANCH,\n };\n\n enum untracked_status_type {\n@@ -42,7 +44,7 @@ struct wt_status {\n \tint relative_paths;\n \tint submodule_summary;\n \tenum untracked_status_type show_untracked_files;\n-\tchar color_palette[WT_STATUS_UNMERGED+1][COLOR_MAXLEN];\n+\tchar color_palette[WT_STATUS_REMOTE_BRANCH+1][COLOR_MAXLEN];\n\n \t/* These are computed during processing of the individual sections */\n \tint commitable;\n-- \n1.7.1.13.g5cd87\n\n-- \ntyped with http://neo-layout.org\nmyFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!\n"},{"id":"141125","messageId":"AANLkTilQZQzijU_xMz34eajpD05ogK01GRByDddoGGmI@mail.gmail.com","threadId":"23667","inReplyTo":"AANLkTikDkrNrzPmIhmcBRKtLKV70f4Kp8wTw6I6ctB4O@mail.gmail.com","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Knittl","fromEmail":"knittl89@googlemail.com","sentAt":"2010-05-07T16:05:51Z","receivedAt":"2010-05-07T16:05:51Z","isPatch":true,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"hi all,\n\nhere's the second part of the branch, so it will only show branch\ninformation in `git status -s` if the additional option `-b` is given.\n\nopen for suggestions,\ndaniel\n\n----------8<-------------\nFrom 00d7aa6872a8aaf98c7e5550ba64ec6e093ca897 Mon Sep 17 00:00:00 2001\nFrom: Daniel Knittl-Frank <knittl89+git@googlemail.com>\nDate: Tue, 20 Apr 2010 22:40:54 +0200\nSubject: [PATCH 2/2] Hide branch information per default in short\noutput of status\n\nBranch information remains hidden, unless the command line option `-b`\nis given to `git status -s`. This way the command does not change from\nolder versions.\n\nAlso hide branch information in `--porcelain` output\n\nSigned-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>\n---\n builtin/commit.c |    8 ++++++--\n wt-status.c      |    7 ++++---\n wt-status.h      |    2 +-\n 3 files changed, 11 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex c5ab683..b058e66 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -92,6 +92,7 @@ static enum {\n \tSTATUS_FORMAT_SHORT,\n \tSTATUS_FORMAT_PORCELAIN,\n } status_format = STATUS_FORMAT_LONG;\n+static int status_show_branch;\n\n static int opt_parse_m(const struct option *opt, const char *arg, int unset)\n {\n@@ -133,6 +134,7 @@ static struct option builtin_commit_options[] = {\n \tOPT_BOOLEAN(0, \"dry-run\", &dry_run, \"show what would be committed\"),\n \tOPT_SET_INT(0, \"short\", &status_format, \"show status concisely\",\n \t\t    STATUS_FORMAT_SHORT),\n+\tOPT_BOOLEAN(0, \"branch\", &status_show_branch, \"show branch information\"),\n \tOPT_SET_INT(0, \"porcelain\", &status_format,\n \t\t    \"show porcelain output format\", STATUS_FORMAT_PORCELAIN),\n \tOPT_BOOLEAN('z', \"null\", &null_termination,\n@@ -417,7 +419,7 @@ static int run_status(FILE *fp, const char\n*index_file, const char *prefix, int\n\n \tswitch (status_format) {\n \tcase STATUS_FORMAT_SHORT:\n-\t\twt_shortstatus_print(s, null_termination);\n+\t\twt_shortstatus_print(s, null_termination, status_show_branch);\n \t\tbreak;\n \tcase STATUS_FORMAT_PORCELAIN:\n \t\twt_porcelain_print(s, null_termination);\n@@ -1022,6 +1024,8 @@ int cmd_status(int argc, const char **argv,\nconst char *prefix)\n \t\tOPT__VERBOSE(&verbose),\n \t\tOPT_SET_INT('s', \"short\", &status_format,\n \t\t\t    \"show status concisely\", STATUS_FORMAT_SHORT),\n+\t\tOPT_BOOLEAN('b', \"branch\", &status_show_branch,\n+\t\t            \"show branch information\"),\n \t\tOPT_SET_INT(0, \"porcelain\", &status_format,\n \t\t\t    \"show porcelain output format\",\n \t\t\t    STATUS_FORMAT_PORCELAIN),\n@@ -1063,7 +1067,7 @@ int cmd_status(int argc, const char **argv,\nconst char *prefix)\n\n \tswitch (status_format) {\n \tcase STATUS_FORMAT_SHORT:\n-\t\twt_shortstatus_print(&s, null_termination);\n+\t\twt_shortstatus_print(&s, null_termination, status_show_branch);\n \t\tbreak;\n \tcase STATUS_FORMAT_PORCELAIN:\n \t\twt_porcelain_print(&s, null_termination);\ndiff --git a/wt-status.c b/wt-status.c\nindex f7f1269..e1b8188 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -781,11 +781,12 @@ static void wt_shortstatus_print_tracking(struct\nwt_status *s)\n \tcolor_fprintf_ln(s->fp, header_color, \"]\");\n }\n\n-void wt_shortstatus_print(struct wt_status *s, int null_termination)\n+void wt_shortstatus_print(struct wt_status *s, int null_termination,\nint show_branch)\n {\n \tint i;\n\n-\twt_shortstatus_print_tracking(s);\n+\tif(show_branch)\n+\t\twt_shortstatus_print_tracking(s);\n\n \tfor (i = 0; i < s->change.nr; i++) {\n \t\tstruct wt_status_change_data *d;\n@@ -811,5 +812,5 @@ void wt_porcelain_print(struct wt_status *s, int\nnull_termination)\n \ts->use_color = 0;\n \ts->relative_paths = 0;\n \ts->prefix = NULL;\n-\twt_shortstatus_print(s, null_termination);\n+\twt_shortstatus_print(s, null_termination, 0);\n }\ndiff --git a/wt-status.h b/wt-status.h\nindex ca5db99..4272539 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -61,7 +61,7 @@ void wt_status_prepare(struct wt_status *s);\n void wt_status_print(struct wt_status *s);\n void wt_status_collect(struct wt_status *s);\n\n-void wt_shortstatus_print(struct wt_status *s, int null_termination);\n+void wt_shortstatus_print(struct wt_status *s, int null_termination,\nint show_branch);\n void wt_porcelain_print(struct wt_status *s, int null_termination);\n\n #endif /* STATUS_H */\n-- \n1.7.1.12.g82b44.dirty\n"},{"id":"141532","messageId":"20100512133537.GA28956@coredump.intra.peff.net","threadId":"23667","inReplyTo":"AANLkTikDkrNrzPmIhmcBRKtLKV70f4Kp8wTw6I6ctB4O@mail.gmail.com","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-12T13:35:38Z","receivedAt":"2010-05-12T13:35:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 06, 2010 at 02:24:41PM +0200, Knittl wrote:\n\n>  - initial commit is also printed when there is tracking information\n> (i still haven't managed to create a situation like that. `git branch\n> oldmaster; rm .git/refs/heads/master; git branch master --set-upstream\n> oldmaster` will reset branch master to oldmaster (a bug?))\n\nTry:\n\n  git branch oldmaster\n  rm .git/refs/heads/master\n  git config branch.master.remote .\n  git config branch.master.merge refs/heads/oldmaster\n\nThat being said, I still get \"Initial commit on master\". I think that\nstat_tracking_branch just gives up if the branch doesn't exist (which\ndoes make some sense). So in practice, I think your original and this\none actually behave the same (sorry, I know that changing it was my\nsuggestion).\n\nAnd no, the \"--set-upstream\" behavior is not a bug. At least not\naccording to the documentation. ;)\n\n>  - colors to match output of `git branch` (green: current, red: remote)\n>  - output format is copy-pasteable, ahead/behind information is in the\n> same format as in `git branch -v`\n\nI think it's much nicer, though the colors are a bit much for my liking.\nStill, it's configurable, so I don't have to care. :)\n\n>  - branch information is still printed by default, i have to look into\n> commandline option parsing first. i was thinking of `git status -v -b`\n> (as in `git checkout -b` to mean branch)\n\nYou may also want to have a configuration option if it is the output you\nprefer all the time (similarly, if you are using \"git status -s\" all the\ntime, you might want a config option to make \"git status\" do what you\nwant).\n\n> ---------8<----------------\n> From 82b4481d38ae0cd62030aeea67160656b7c763e2 Mon Sep 17 00:00:00 2001\n> From: Daniel Knittl-Frank <knittl89+git@googlemail.com>\n> Date: Tue, 20 Apr 2010 22:40:54 +0200\n> Subject: [PATCH] Show branch information in short output of git status\n\nThis patch looks OK, but:\n\n  1. I think for the final version you can just squash in part 2/2.\n\n  2. Your patch has wrapped lines which make it impossible to apply\n     without fixing up manually. This is a common gmail problem.  See\n     the \"gmail\" section of SubmittingPatches.\n\n-Peff\n"},{"id":"141637","messageId":"AANLkTilkFHK1UIvSLEstXFIOJTsit02EZe1Wsoj_zRRX@mail.gmail.com","threadId":"23667","inReplyTo":"20100512133537.GA28956@coredump.intra.peff.net","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Knittl","fromEmail":"knittl89@googlemail.com","sentAt":"2010-05-14T06:54:07Z","receivedAt":"2010-05-14T06:54:07Z","isPatch":true,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"On Wed, May 12, 2010 at 3:35 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, May 06, 2010 at 02:24:41PM +0200, Knittl wrote:\n>\n>>  - initial commit is also printed when there is tracking information\n>> (i still haven't managed to create a situation like that. `git branch\n>> oldmaster; rm .git/refs/heads/master; git branch master --set-upstream\n>> oldmaster` will reset branch master to oldmaster (a bug?))\n>\n> Try:\n>\n>  git branch oldmaster\n>  rm .git/refs/heads/master\n>  git config branch.master.remote .\n>  git config branch.master.merge refs/heads/oldmaster\n>\n> That being said, I still get \"Initial commit on master\". I think that\n> stat_tracking_branch just gives up if the branch doesn't exist (which\n> does make some sense). So in practice, I think your original and this\n> one actually behave the same (sorry, I know that changing it was my\n> suggestion).\n>\n> And no, the \"--set-upstream\" behavior is not a bug. At least not\n> according to the documentation. ;)\n\nyep, that's what i discovered too—but i don't care if this condition\nis 3 lines up or down. if stat_tracking_branch decides it will work\nfor initial commits, then this code will do the expected thing\n\n>>  - colors to match output of `git branch` (green: current, red: remote)\n>>  - output format is copy-pasteable, ahead/behind information is in the\n>> same format as in `git branch -v`\n>\n> I think it's much nicer, though the colors are a bit much for my liking.\n> Still, it's configurable, so I don't have to care. :)\n\ni find the numbers quicker to spot when they are a different color\nfrom normal text, but if the majority objects i can remove them of\ncourse.\n\n>>  - branch information is still printed by default, i have to look into\n>> commandline option parsing first. i was thinking of `git status -v -b`\n>> (as in `git checkout -b` to mean branch)\n>\n> You may also want to have a configuration option if it is the output you\n> prefer all the time (similarly, if you are using \"git status -s\" all the\n> time, you might want a config option to make \"git status\" do what you\n> want).\n\non my local system i have `alias.st = git status -sb`, so i don't\nreally find a need to make a config option. actually i fall into both\ngroups you described in your first answer: having a quick glance what\nfiles were changed and grouping files based on status. so i write both\n`git st` and `git status` quite often (also with `git stat` my alias\nfor `git diff --stat` to see what changed content-wise)\n\n>> ---------8<----------------\n>> From 82b4481d38ae0cd62030aeea67160656b7c763e2 Mon Sep 17 00:00:00 2001\n>> From: Daniel Knittl-Frank <knittl89+git@googlemail.com>\n>> Date: Tue, 20 Apr 2010 22:40:54 +0200\n>> Subject: [PATCH] Show branch information in short output of git status\n>\n> This patch looks OK, but:\n>\n>  1. I think for the final version you can just squash in part 2/2.\n\nshould be no problem. the second patch changed quite a bit, so i\nthought it is easier to review when i send it as a separate patch. the\nfinal patch can be squashed of course\n\n>  2. Your patch has wrapped lines which make it impossible to apply\n>     without fixing up manually. This is a common gmail problem.  See\n>     the \"gmail\" section of SubmittingPatches.\n\nok, browsed through that. i think i will just put my branch into a\npasteservice or on a fileserver, unless the email way is *really*\npreferred—what about email attachments?\n\ncheers, daniel\n\n-- \ntyped with http://neo-layout.org\nmyFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!\n"},{"id":"142138","messageId":"20100523092348.GA16811@coredump.intra.peff.net","threadId":"23667","inReplyTo":"AANLkTilkFHK1UIvSLEstXFIOJTsit02EZe1Wsoj_zRRX@mail.gmail.com","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-23T09:23:48Z","receivedAt":"2010-05-23T09:23:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 14, 2010 at 08:54:07AM +0200, Knittl wrote:\n\n> > That being said, I still get \"Initial commit on master\". I think that\n> > stat_tracking_branch just gives up if the branch doesn't exist (which\n> > does make some sense). So in practice, I think your original and this\n> > one actually behave the same (sorry, I know that changing it was my\n> > suggestion).\n> \n> yep, that's what i discovered too—but i don't care if this condition\n> is 3 lines up or down. if stat_tracking_branch decides it will work\n> for initial commits, then this code will do the expected thing\n\nAgreed.\n\n> should be no problem. the second patch changed quite a bit, so i\n> thought it is easier to review when i send it as a separate patch. the\n> final patch can be squashed of course\n\nOK.  Nobody else seems to be commenting, so I would go ahead and put\ntogether your final patch, cc-ing the maintainer.\n\n> >  2. Your patch has wrapped lines which make it impossible to apply\n> >     without fixing up manually. This is a common gmail problem.  See\n> >     the \"gmail\" section of SubmittingPatches.\n> \n> ok, browsed through that. i think i will just put my branch into a\n> pasteservice or on a fileserver, unless the email way is *really*\n> preferred—what about email attachments?\n\nInline email is best, but I think an email attachment would be preferred\nto putting it on some out-of-band service (it's nice for the mailing\nlist archive to have a record of everything).\n\n-Peff\n"},{"id":"142244","messageId":"4BFB79F6.5070501@drmicha.warpmail.net","threadId":"23667","inReplyTo":"20100523092348.GA16811@coredump.intra.peff.net","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-25T07:19:18Z","receivedAt":"2010-05-25T07:19:18Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 23.05.2010 11:23:\n> On Fri, May 14, 2010 at 08:54:07AM +0200, Knittl wrote:\n> \n>>> That being said, I still get \"Initial commit on master\". I think that\n>>> stat_tracking_branch just gives up if the branch doesn't exist (which\n>>> does make some sense). So in practice, I think your original and this\n>>> one actually behave the same (sorry, I know that changing it was my\n>>> suggestion).\n>>\n>> yep, that's what i discovered too—but i don't care if this condition\n>> is 3 lines up or down. if stat_tracking_branch decides it will work\n>> for initial commits, then this code will do the expected thing\n> \n> Agreed.\n> \n>> should be no problem. the second patch changed quite a bit, so i\n>> thought it is easier to review when i send it as a separate patch. the\n>> final patch can be squashed of course\n> \n> OK.  Nobody else seems to be commenting, so I would go ahead and put\n> together your final patch, cc-ing the maintainer.\n\nBeen following silently :)\n\nI'm a regular shortstatus user and find myself calling ordinary status\njust to get that part of info you're adding to shortstatus. I agree the\ndefault should stay as is and use aliases anyways. (I also think we need\nto clean up our option/config mess at one point and make at least long\noptions the same as config variables.)\n\nI even wanted to try out the patch but was stopped by:\n\n> \n>>>  2. Your patch has wrapped lines which make it impossible to apply\n>>>     without fixing up manually. This is a common gmail problem.  See\n>>>     the \"gmail\" section of SubmittingPatches.\n>>\n>> ok, browsed through that. i think i will just put my branch into a\n>> pasteservice or on a fileserver, unless the email way is *really*\n>> preferred—what about email attachments?\n> \n> Inline email is best, but I think an email attachment would be preferred\n> to putting it on some out-of-band service (it's nice for the mailing\n> list archive to have a record of everything).\n\nI'm really wondering what the problem is with git-send-email + GMail's\nsmtp. I'm not saying there is none: I'm just observing that we seem to\nattract a lot of new contributors lately and that the email-inline-patch\nrequirement seems to be a hurdle to quite a few. I've created a mob\nbranch at\n\nhttp://repo.or.cz/w/git/mjg.git\n\nbased off current master to which you can push, Daniel.\n\nI'm wondering whether we should have a mob branch+receive hook solution\nwhere people can push to mob-{maint,master,next} (whose tip coincides\nwith the resp. main branches), maybe allowing fast-forwards only, and\nwhere a post-receive-hook hook sends the patch to the list and resets\nthe mob-... branch.\n\nThat would require push/pull expertise only, no MUA tweaking necessary.\n\nCheers,\nMichael\n"},{"id":"142245","messageId":"20100525072240.GA20408@coredump.intra.peff.net","threadId":"23667","inReplyTo":"4BFB79F6.5070501@drmicha.warpmail.net","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-25T07:22:41Z","receivedAt":"2010-05-25T07:22:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 25, 2010 at 09:19:18AM +0200, Michael J Gruber wrote:\n\n> I'm really wondering what the problem is with git-send-email + GMail's\n> smtp. I'm not saying there is none: I'm just observing that we seem to\n> attract a lot of new contributors lately and that the email-inline-patch\n> requirement seems to be a hurdle to quite a few. I've created a mob\n> branch at\n\nI don't use gmail, but my impression was that the problem is one of:\n\n  1. pushing to gmail's drafts folder via imap, and then using the web\n     interface to send the email\n\n  2. cutting and pasting into the web interface\n\nI would hope that sending directly via SMTP with git-send-email would\nnot get munged. That is pretty broken otherwise.\n\n-Peff\n"},{"id":"142251","messageId":"4BFB860E.1070006@drmicha.warpmail.net","threadId":"23667","inReplyTo":"20100525072240.GA20408@coredump.intra.peff.net","subject":"Re: [PATCH] Show branch information in short output of git status","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-25T08:10:54Z","receivedAt":"2010-05-25T08:10:54Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 25.05.2010 09:22:\n> On Tue, May 25, 2010 at 09:19:18AM +0200, Michael J Gruber wrote:\n> \n>> I'm really wondering what the problem is with git-send-email + GMail's\n>> smtp. I'm not saying there is none: I'm just observing that we seem to\n>> attract a lot of new contributors lately and that the email-inline-patch\n>> requirement seems to be a hurdle to quite a few. I've created a mob\n>> branch at\n> \n> I don't use gmail, but my impression was that the problem is one of:\n> \n>   1. pushing to gmail's drafts folder via imap, and then using the web\n>      interface to send the email\n> \n>   2. cutting and pasting into the web interface\n> \n> I would hope that sending directly via SMTP with git-send-email would\n> not get munged. That is pretty broken otherwise.\n\nWell, I know what the problem is with GMail's IMAP and web, but it's\ngood to have it summed up this concisely ;)\n\nI'm wondering what the problem is with GMail's SMTP: Technically there\nis none, but people shy away from using it (together with\ngit-send-email). It does not even require setting up an MTA like\nsendmail or msmtp. But, apparently, this is a hurdle, which is why I\nbrought up the mob-auto-send.\n\nMichael\n"},{"id":"142253","messageId":"40abcf5e5337f974e70a7b0bd6279a630b35ce19.1274776132.git.git@drmicha.warpmail.net","threadId":"23667","inReplyTo":"20100525072240.GA20408@coredump.intra.peff.net","subject":"[PATCH] Documentation/SubmittingPatches: clarify GMail section and SMTP","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-25T08:30:13Z","receivedAt":"2010-05-25T08:30:13Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"We keep getting mangled submissions from GMail's web interface. Try to\nbe more proactive in SubmittingPatches by\n\n- pointing to MUA specific instructions early on,\n- structuring the GMail section more clearly,\n- putting send-email/SMTP before imap-send/IMAP.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/SubmittingPatches |   40 ++++++++++++++++++++------------------\n 1 files changed, 21 insertions(+), 19 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 8db22ef..b9204c7 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -41,6 +41,7 @@ Checklist (and a short version for the impatient):\n \t  maintainer (gitster@pobox.com) if (and only if) the patch\n \t  is ready for inclusion. If you use git-send-email(1),\n \t  please test it first by sending email to yourself.\n+\t- see below for instructions specific to your mailer\n \n Long version:\n \n@@ -546,9 +547,27 @@ Gmail\n \n GMail does not appear to have any way to turn off line wrapping in the web\n interface, so this will mangle any emails that you send.  You can however\n-use any IMAP email client to connect to the google imap server, and forward\n+use \"git send e-mail\" and send your patches through the GMail SMTP server, or\n+use any IMAP email client to connect to the google IMAP server and forward\n the emails through that.\n \n+To use \"git send-email\" and send your patches through the GMail SMTP server,\n+edit ~/.gitconfig to specify your account settings:\n+\n+[sendemail]\n+\tsmtpencryption = tls\n+\tsmtpserver = smtp.gmail.com\n+\tsmtpuser = user@gmail.com\n+\tsmtppass = p4ssw0rd\n+\tsmtpserverport = 587\n+\n+Once your commits are ready to be sent to the mailing list, run the\n+following commands:\n+\n+  $ git format-patch --cover-letter -M origin/master -o outgoing/\n+  $ edit outgoing/0000-*\n+  $ git send-email outgoing/*\n+\n To submit using the IMAP interface, first, edit your ~/.gitconfig to specify your\n account settings:\n \n@@ -564,8 +583,7 @@ You might need to instead use: folder = \"[Google Mail]/Drafts\" if you get an err\n that the \"Folder doesn't exist\".\n \n Once your commits are ready to be sent to the mailing list, run the\n-following command to send the patch emails to your Gmail Drafts\n-folder.\n+following commands:\n \n   $ git format-patch --cover-letter -M --stdout origin/master | git imap-send\n \n@@ -573,19 +591,3 @@ Just make sure to disable line wrapping in the email client (GMail web\n interface will line wrap no matter what, so you need to use a real\n IMAP client).\n \n-Alternatively, you can use \"git send-email\" and send your patches\n-through the GMail SMTP server.  edit ~/.gitconfig to specify your\n-account settings:\n-\n-[sendemail]\n-\tsmtpencryption = tls\n-\tsmtpserver = smtp.gmail.com\n-\tsmtpuser = user@gmail.com\n-\tsmtppass = p4ssw0rd\n-\tsmtpserverport = 587\n-\n-Once your commits are ready to be sent to the mailing list, run the\n-following commands:\n-\n-  $ git format-patch --cover-letter -M origin/master -o outgoing/\n-  $ git send-email outgoing/*\n-- \n1.7.1.342.g1c280\n"},{"id":"142269","messageId":"20100525092548.GA32288@coredump.intra.peff.net","threadId":"23667","inReplyTo":"40abcf5e5337f974e70a7b0bd6279a630b35ce19.1274776132.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] Documentation/SubmittingPatches: clarify GMail section and SMTP","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-25T09:25:48Z","receivedAt":"2010-05-25T09:25:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 25, 2010 at 10:30:13AM +0200, Michael J Gruber wrote:\n\n> We keep getting mangled submissions from GMail's web interface. Try to\n> be more proactive in SubmittingPatches by\n> \n> - pointing to MUA specific instructions early on,\n> - structuring the GMail section more clearly,\n> - putting send-email/SMTP before imap-send/IMAP.\n\nLike I said elsewhere in the thread, I do not use gmail, but from our\nprior discussion and what I have seen on the list, these seem like good\nchanges to me.\n\n-Peff\n"},{"id":"142275","messageId":"AANLkTin3loPRUroTO6wIF4iCqqmrR7BDxAeJXtNcU_as@mail.gmail.com","threadId":"23667","inReplyTo":"20100525092548.GA32288@coredump.intra.peff.net","subject":"Re: [PATCH] Documentation/SubmittingPatches: clarify GMail section and SMTP","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-25T09:47:14Z","receivedAt":"2010-05-25T09:47:14Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, May 25, 2010 at 09:25, Jeff King <peff@peff.net> wrote:\n> On Tue, May 25, 2010 at 10:30:13AM +0200, Michael J Gruber wrote:\n>\n>> We keep getting mangled submissions from GMail's web interface. Try to\n>> be more proactive in SubmittingPatches by\n>>\n>> - pointing to MUA specific instructions early on,\n>> - structuring the GMail section more clearly,\n>> - putting send-email/SMTP before imap-send/IMAP.\n>\n> Like I said elsewhere in the thread, I do not use gmail, but from our\n> prior discussion and what I have seen on the list, these seem like good\n> changes to me.\n\nI use GMail, and I think the SMTP instructions should come first,\nthese changes look good.\n"}]}