threads / patch / 23667

patchShow branch information in short output of git status

Subject: [PATCH] Show branch information in short output of git status

## tl;dr

13 messages between May 2, 2010 and May 25, 2010. Diffs are folded; open one to read it.

replies: 12people: 4as markdown or json

Knittl· May 2, 2010, 09:13 UTC · lore

This patch adds a first line in the output of `git status -s`, showing which branch the user is currently on, and in case of tracking branches the number of commits on each branch.

Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
---
 wt-status.c |   45 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 45 insertions(+), 0 deletions(-)
Show changes to wt-status.c +45 −0
diff --git a/wt-status.c b/wt-status.c
index 8ca59a2..2e6c56e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -9,6 +9,7 @@
 #include "quote.h"
 #include "run-command.h"
 #include "remote.h"
+#include "refs.h"

 static char default_wt_status_colors[][COLOR_MAXLEN] = {
 	GIT_COLOR_NORMAL, /* WT_STATUS_HEADER */
@@ -721,9 +722,53 @@ static void wt_shortstatus_untracked(int
null_termination, struct string_list_it
 	}
 }

+static void wt_shortstatus_print_tracking(struct wt_status *s)
+{
+	struct branch *branch;
+	const char *branch_color = color(WT_STATUS_HEADER, s);
+
+	const char *base;
+	const char *branch_name;
+	int num_ours, num_theirs;
+
+	color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "## ");
+
+	if(!s->branch) return;
+	branch_name = s->branch;
+
+	if (!prefixcmp(branch_name, "refs/heads/"))
+		branch_name += 11;
+	else if (!strcmp(branch_name, "HEAD")) {
+		branch_color = color(WT_STATUS_NOBRANCH, s);
+	}
+
+	branch = branch_get(s->branch + 11);
+	if (!stat_tracking_info(branch, &num_ours, &num_theirs)) {
+
+		if(s->is_initial) {
+			color_fprintf(s->fp,
+				color(WT_STATUS_HEADER, s),
+				"Initial commit ... ");
+		}
+		color_fprintf_ln(s->fp, branch_color,
+			"%s", branch_name);
+		return;
+	}
+
+	base = branch->merge[0]->dst;
+	base = shorten_unambiguous_ref(base, 0);
+	color_fprintf_ln(s->fp, branch_color,
+			"%s (%d) ... %s (%d)",
+			branch_name, num_ours,
+			base, num_theirs);
+}
+
 void wt_shortstatus_print(struct wt_status *s, int null_termination)
 {
 	int i;
+
+	wt_shortstatus_print_tracking(s);
+
 	for (i = 0; i < s->change.nr; i++) {
 		struct wt_status_change_data *d;
 		struct string_list_item *it;
-- 
1.7.1.rc2.6.g1015.dirty


-- 
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
Jeff King· May 5, 2010, 05:06 UTC · re: Knittl · lore

Re: [PATCH] Show branch information in short output of git status

On Sun, May 02, 2010 at 11:13:41AM +0200, Knittl wrote:
> This patch adds a first line in the output of `git status -s`, showing
> which branch the user is currently on, and in case of tracking branches
> the number of commits on each branch.

I don't generally use "git status -s", so I don't have a strong opinion, but should this perhaps be optional? I imagine people using it fall into one of two categories:

  1. They want to waste less vertical screen real estate than "git
     status" does.
  2. They prefer to see files in a single list with status marked,
     rather than in separate lists based on status.

Your patch will probably annoy people in group (1) unless they have some way to turn it off.

A few other comments on the patch itself:
> +	color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "## ");

I thought the doubled '##' looked funny at first, but the more I look at it, I think lining it up with the filenames looks good.

> +	if(!s->branch) return;
Style nits. This should be:
  if (!s->branch)
          return;
Show 12 quoted lines
> +	branch = branch_get(s->branch + 11);
> +	if (!stat_tracking_info(branch, &num_ours, &num_theirs)) {
> +
> +		if(s->is_initial) {
> +			color_fprintf(s->fp,
> +				color(WT_STATUS_HEADER, s),
> +				"Initial commit ... ");
> +		}
> +		color_fprintf_ln(s->fp, branch_color,
> +			"%s", branch_name);
> +		return;
> +	}

Why do we only mention it as an initial commit if there is no tracking? We get if it is an initial commit and no tracking:

  ## Initial commit ... master

but if there is a tracking branch setup, we get no "Initial commit" at all. And the use of "..." is confusing, as it usually implies symmetric difference, which doesn't really make sense here.

Show 7 quoted lines
> +	base = branch->merge[0]->dst;
> +	base = shorten_unambiguous_ref(base, 0);
> +	color_fprintf_ln(s->fp, branch_color,
> +			"%s (%d) ... %s (%d)",
> +			branch_name, num_ours,
> +			base, num_theirs);
> +}
Here we get:
  ## master (1) ... origin/master (1)

which kind of makes sense. The "..." implies symmetric difference. But in other spots, like "git fetch" and "git push" output, we usually try to make it cut-and-pastable in case one wants to view the actual history. So maybe something like:

  ## master...origin/master [ahead 1, behind 1]

The latter matches how "git branch -v" prints it. I dunno. I guess this is just bikeshedding really, so maybe others will chime in with suggestions and you can pick the one you like best.

-Peff
Knittl· May 6, 2010, 12:24 UTC · re: Jeff King · lore

Re: [PATCH] Show branch information in short output of git status

Hi jeff,
thank you for your response and your comments.
On Wed, May 5, 2010 at 7:06 AM, Jeff King <peff@peff.net> wrote:
Show 12 quoted lines
> On Sun, May 02, 2010 at 11:13:41AM +0200, Knittl wrote:
>
>> This patch adds a first line in the output of `git status -s`, showing
>> which branch the user is currently on, and in case of tracking branches
>> the number of commits on each branch.
>
> I don't generally use "git status -s", so I don't have a strong opinion,
> but should this perhaps be optional?  I imagine people using it fall
> into one of two categories:
>
>  1. They want to waste less vertical screen real estate than "git
>     status" does.

it's one line ;) but i can understand your concern. would `git status -s -v` or `git status -s --show-branch` make sense?

Show 12 quoted lines
>  2. They prefer to see files in a single list with status marked,
>     rather than in separate lists based on status.
>
> Your patch will probably annoy people in group (1) unless they have some
> way to turn it off.
>
> A few other comments on the patch itself:
>
>> +     color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "## ");
>
> I thought the doubled '##' looked funny at first, but the more I look at
> it, I think lining it up with the filenames looks good.

i had one hash and two spaces at first, but as you said, two hashes look more lined up.

Show 6 quoted lines
>> +     if(!s->branch) return;
>
> Style nits. This should be:
>
>  if (!s->branch)
>          return;
done …
Show 15 quoted lines
>> +     branch = branch_get(s->branch + 11);
>> +     if (!stat_tracking_info(branch, &num_ours, &num_theirs)) {
>> +
>> +             if(s->is_initial) {
>> +                     color_fprintf(s->fp,
>> +                             color(WT_STATUS_HEADER, s),
>> +                             "Initial commit ... ");
>> +             }
>> +             color_fprintf_ln(s->fp, branch_color,
>> +                     "%s", branch_name);
>> +             return;
>> +     }
>
> Why do we only mention it as an initial commit if there is no tracking?
> We get if it is an initial commit and no tracking:

i don't think it's (easily, without messing around with the .git directory) possible to create a branch without commits that tracks another branch (without commits). or is it?

Show 5 quoted lines
>  ## Initial commit ... master
>
> but if there is a tracking branch setup, we get no "Initial commit" at
> all. And the use of "..." is confusing, as it usually implies symmetric
> difference, which doesn't really make sense here.

i used ... to make it look consistent with normal branch output, but i guess you are right. i changed it to `Initial commit on <branchname>

Show 22 quoted lines
>> +     base = branch->merge[0]->dst;
>> +     base = shorten_unambiguous_ref(base, 0);
>> +     color_fprintf_ln(s->fp, branch_color,
>> +                     "%s (%d) ... %s (%d)",
>> +                     branch_name, num_ours,
>> +                     base, num_theirs);
>> +}
>
> Here we get:
>
>  ## master (1) ... origin/master (1)
>
> which kind of makes sense. The "..." implies symmetric difference. But
> in other spots, like "git fetch" and "git push" output, we usually try
> to make it cut-and-pastable in case one wants to view the actual
> history. So maybe something like:
>
>  ## master...origin/master [ahead 1, behind 1]
>
> The latter matches how "git branch -v" prints it. I dunno. I guess this
> is just bikeshedding really, so maybe others will chime in with
> suggestions and you can pick the one you like best.

oh, i didn't know `git branch -v`. the cut&paste argument is really strong, so i totally agree with you and changed my code.

branch names and ahead/behind numbers appear now in green and red to match the output of `git branch -l`

here is the updated patch:
 - initial commit is also printed when there is tracking information
(i still haven't managed to create a situation like that. `git branch
oldmaster; rm .git/refs/heads/master; git branch master --set-upstream
oldmaster` will reset branch master to oldmaster (a bug?))
 - colors to match output of `git branch` (green: current, red: remote)
 - output format is copy-pasteable, ahead/behind information is in the
same format as in `git branch -v`
 - branch information is still printed by default, i have to look into
commandline option parsing first. i was thinking of `git status -v -b`
(as in `git checkout -b` to mean branch)
cheers, daniel
(i forgot to send my reply to the mailing list too …)
---------8<----------------
From 82b4481d38ae0cd62030aeea67160656b7c763e2 Mon Sep 17 00:00:00 2001
From: Daniel Knittl-Frank <knittl89+git@googlemail.com>
Date: Tue, 20 Apr 2010 22:40:54 +0200
Subject: [PATCH] Show branch information in short output of git status

This patch adds a first line in the output of `git status -s`, showing which branch the user is currently on, and in case of tracking branches the number of commits on each branch.

Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
---
 wt-status.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 wt-status.h |    4 ++-
 2 files changed, 66 insertions(+), 1 deletions(-)
Show changes to 2 files +66 −1

wt-status.c, wt-status.h

diff --git a/wt-status.c b/wt-status.c
index 8ca59a2..f7f1269 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -9,6 +9,7 @@
 #include "quote.h"
 #include "run-command.h"
 #include "remote.h"
+#include "refs.h"

 static char default_wt_status_colors[][COLOR_MAXLEN] = {
 	GIT_COLOR_NORMAL, /* WT_STATUS_HEADER */
@@ -17,6 +18,8 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {
 	GIT_COLOR_RED,    /* WT_STATUS_UNTRACKED */
 	GIT_COLOR_RED,    /* WT_STATUS_NOBRANCH */
 	GIT_COLOR_RED,    /* WT_STATUS_UNMERGED */
+	GIT_COLOR_GREEN,  /* WT_STATUS_LOCAL_BRANCH */
+	GIT_COLOR_RED,    /* WT_STATUS_REMOTE_BRANCH */
 };

 static const char *color(int slot, struct wt_status *s)
@@ -721,9 +724,69 @@ static void wt_shortstatus_untracked(int
null_termination, struct string_list_it
 	}
 }

+static void wt_shortstatus_print_tracking(struct wt_status *s)
+{
+	struct branch *branch;
+	const char *header_color = color(WT_STATUS_HEADER, s);
+	const char *branch_color_local = color(WT_STATUS_LOCAL_BRANCH, s);
+	const char *branch_color_remote = color(WT_STATUS_REMOTE_BRANCH, s);
+
+	const char *base;
+	const char *branch_name;
+	int num_ours, num_theirs;
+
+	color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "## ");
+
+	if(!s->branch)
+		return;
+	branch_name = s->branch;
+
+	if (!prefixcmp(branch_name, "refs/heads/"))
+		branch_name += 11;
+	else if (!strcmp(branch_name, "HEAD")) {
+		branch_name = "HEAD (no branch)";
+		branch_color_local = color(WT_STATUS_NOBRANCH, s);
+	}
+
+	branch = branch_get(s->branch + 11);
+	if(s->is_initial) {
+		color_fprintf(s->fp, header_color, "Initial commit on ");
+	}
+	if (!stat_tracking_info(branch, &num_ours, &num_theirs)) {
+		color_fprintf_ln(s->fp, branch_color_local,
+			"%s", branch_name);
+		return;
+	}
+
+	base = branch->merge[0]->dst;
+	base = shorten_unambiguous_ref(base, 0);
+	color_fprintf(s->fp, branch_color_local, "%s", branch_name);
+	color_fprintf(s->fp, header_color, "...");
+	color_fprintf(s->fp, branch_color_remote, "%s", base);
+
+	color_fprintf(s->fp, header_color, " [");
+	if (!num_ours) {
+		color_fprintf(s->fp, header_color, "behind ");
+		color_fprintf(s->fp, branch_color_remote, "%d", num_theirs);
+	} else if (!num_theirs) {
+		color_fprintf(s->fp, header_color, "ahead ");
+		color_fprintf(s->fp, branch_color_local, "%d", num_ours);
+	} else {
+		color_fprintf(s->fp, header_color, "ahead ");
+		color_fprintf(s->fp, branch_color_local, "%d", num_ours);
+		color_fprintf(s->fp, header_color, ", behind ");
+		color_fprintf(s->fp, branch_color_remote, "%d", num_theirs);
+	}
+
+	color_fprintf_ln(s->fp, header_color, "]");
+}
+
 void wt_shortstatus_print(struct wt_status *s, int null_termination)
 {
 	int i;
+
+	wt_shortstatus_print_tracking(s);
+
 	for (i = 0; i < s->change.nr; i++) {
 		struct wt_status_change_data *d;
 		struct string_list_item *it;
diff --git a/wt-status.h b/wt-status.h
index 9120673..ca5db99 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -12,6 +12,8 @@ enum color_wt_status {
 	WT_STATUS_UNTRACKED,
 	WT_STATUS_NOBRANCH,
 	WT_STATUS_UNMERGED,
+	WT_STATUS_LOCAL_BRANCH,
+	WT_STATUS_REMOTE_BRANCH,
 };

 enum untracked_status_type {
@@ -42,7 +44,7 @@ struct wt_status {
 	int relative_paths;
 	int submodule_summary;
 	enum untracked_status_type show_untracked_files;
-	char color_palette[WT_STATUS_UNMERGED+1][COLOR_MAXLEN];
+	char color_palette[WT_STATUS_REMOTE_BRANCH+1][COLOR_MAXLEN];

 	/* These are computed during processing of the individual sections */
 	int commitable;
-- 
1.7.1.13.g5cd87

-- 
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
Knittl· May 7, 2010, 16:05 UTC · re: Knittl · lore

Re: [PATCH] Show branch information in short output of git status

hi all,

here's the second part of the branch, so it will only show branch information in `git status -s` if the additional option `-b` is given.

open for suggestions, daniel

----------8<-------------
From 00d7aa6872a8aaf98c7e5550ba64ec6e093ca897 Mon Sep 17 00:00:00 2001
From: Daniel Knittl-Frank <knittl89+git@googlemail.com>
Date: Tue, 20 Apr 2010 22:40:54 +0200
Subject: [PATCH 2/2] Hide branch information per default in short
output of status

Branch information remains hidden, unless the command line option `-b` is given to `git status -s`. This way the command does not change from older versions.

Also hide branch information in `--porcelain` output
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
---
 builtin/commit.c |    8 ++++++--
 wt-status.c      |    7 ++++---
 wt-status.h      |    2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)
Show changes to 3 files +11 −6

builtin/commit.c, wt-status.c, wt-status.h

diff --git a/builtin/commit.c b/builtin/commit.c
index c5ab683..b058e66 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -92,6 +92,7 @@ static enum {
 	STATUS_FORMAT_SHORT,
 	STATUS_FORMAT_PORCELAIN,
 } status_format = STATUS_FORMAT_LONG;
+static int status_show_branch;

 static int opt_parse_m(const struct option *opt, const char *arg, int unset)
 {
@@ -133,6 +134,7 @@ static struct option builtin_commit_options[] = {
 	OPT_BOOLEAN(0, "dry-run", &dry_run, "show what would be committed"),
 	OPT_SET_INT(0, "short", &status_format, "show status concisely",
 		    STATUS_FORMAT_SHORT),
+	OPT_BOOLEAN(0, "branch", &status_show_branch, "show branch information"),
 	OPT_SET_INT(0, "porcelain", &status_format,
 		    "show porcelain output format", STATUS_FORMAT_PORCELAIN),
 	OPT_BOOLEAN('z', "null", &null_termination,
@@ -417,7 +419,7 @@ static int run_status(FILE *fp, const char
*index_file, const char *prefix, int

 	switch (status_format) {
 	case STATUS_FORMAT_SHORT:
-		wt_shortstatus_print(s, null_termination);
+		wt_shortstatus_print(s, null_termination, status_show_branch);
 		break;
 	case STATUS_FORMAT_PORCELAIN:
 		wt_porcelain_print(s, null_termination);
@@ -1022,6 +1024,8 @@ int cmd_status(int argc, const char **argv,
const char *prefix)
 		OPT__VERBOSE(&verbose),
 		OPT_SET_INT('s', "short", &status_format,
 			    "show status concisely", STATUS_FORMAT_SHORT),
+		OPT_BOOLEAN('b', "branch", &status_show_branch,
+		            "show branch information"),
 		OPT_SET_INT(0, "porcelain", &status_format,
 			    "show porcelain output format",
 			    STATUS_FORMAT_PORCELAIN),
@@ -1063,7 +1067,7 @@ int cmd_status(int argc, const char **argv,
const char *prefix)

 	switch (status_format) {
 	case STATUS_FORMAT_SHORT:
-		wt_shortstatus_print(&s, null_termination);
+		wt_shortstatus_print(&s, null_termination, status_show_branch);
 		break;
 	case STATUS_FORMAT_PORCELAIN:
 		wt_porcelain_print(&s, null_termination);
diff --git a/wt-status.c b/wt-status.c
index f7f1269..e1b8188 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -781,11 +781,12 @@ static void wt_shortstatus_print_tracking(struct
wt_status *s)
 	color_fprintf_ln(s->fp, header_color, "]");
 }

-void wt_shortstatus_print(struct wt_status *s, int null_termination)
+void wt_shortstatus_print(struct wt_status *s, int null_termination,
int show_branch)
 {
 	int i;

-	wt_shortstatus_print_tracking(s);
+	if(show_branch)
+		wt_shortstatus_print_tracking(s);

 	for (i = 0; i < s->change.nr; i++) {
 		struct wt_status_change_data *d;
@@ -811,5 +812,5 @@ void wt_porcelain_print(struct wt_status *s, int
null_termination)
 	s->use_color = 0;
 	s->relative_paths = 0;
 	s->prefix = NULL;
-	wt_shortstatus_print(s, null_termination);
+	wt_shortstatus_print(s, null_termination, 0);
 }
diff --git a/wt-status.h b/wt-status.h
index ca5db99..4272539 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -61,7 +61,7 @@ void wt_status_prepare(struct wt_status *s);
 void wt_status_print(struct wt_status *s);
 void wt_status_collect(struct wt_status *s);

-void wt_shortstatus_print(struct wt_status *s, int null_termination);
+void wt_shortstatus_print(struct wt_status *s, int null_termination,
int show_branch);
 void wt_porcelain_print(struct wt_status *s, int null_termination);

 #endif /* STATUS_H */
-- 
1.7.1.12.g82b44.dirty
Jeff King· May 12, 2010, 13:35 UTC · re: Knittl · lore

Re: [PATCH] Show branch information in short output of git status

On Thu, May 06, 2010 at 02:24:41PM +0200, Knittl wrote:
>  - initial commit is also printed when there is tracking information
> (i still haven't managed to create a situation like that. `git branch
> oldmaster; rm .git/refs/heads/master; git branch master --set-upstream
> oldmaster` will reset branch master to oldmaster (a bug?))
Try:
  git branch oldmaster
  rm .git/refs/heads/master
  git config branch.master.remote .
  git config branch.master.merge refs/heads/oldmaster

That being said, I still get "Initial commit on master". I think that stat_tracking_branch just gives up if the branch doesn't exist (which does make some sense). So in practice, I think your original and this one actually behave the same (sorry, I know that changing it was my suggestion).

And no, the "--set-upstream" behavior is not a bug. At least not according to the documentation. ;)

>  - colors to match output of `git branch` (green: current, red: remote)
>  - output format is copy-pasteable, ahead/behind information is in the
> same format as in `git branch -v`

I think it's much nicer, though the colors are a bit much for my liking. Still, it's configurable, so I don't have to care. :)

>  - branch information is still printed by default, i have to look into
> commandline option parsing first. i was thinking of `git status -v -b`
> (as in `git checkout -b` to mean branch)

You may also want to have a configuration option if it is the output you prefer all the time (similarly, if you are using "git status -s" all the time, you might want a config option to make "git status" do what you want).

Show 5 quoted lines
> ---------8<----------------
> From 82b4481d38ae0cd62030aeea67160656b7c763e2 Mon Sep 17 00:00:00 2001
> From: Daniel Knittl-Frank <knittl89+git@googlemail.com>
> Date: Tue, 20 Apr 2010 22:40:54 +0200
> Subject: [PATCH] Show branch information in short output of git status
This patch looks OK, but:
  1. I think for the final version you can just squash in part 2/2.
  2. Your patch has wrapped lines which make it impossible to apply
     without fixing up manually. This is a common gmail problem.  See
     the "gmail" section of SubmittingPatches.
-Peff
Knittl· May 14, 2010, 06:54 UTC · re: Jeff King · lore

Re: [PATCH] Show branch information in short output of git status

On Wed, May 12, 2010 at 3:35 PM, Jeff King <peff@peff.net> wrote:
Show 22 quoted lines
> On Thu, May 06, 2010 at 02:24:41PM +0200, Knittl wrote:
>
>>  - initial commit is also printed when there is tracking information
>> (i still haven't managed to create a situation like that. `git branch
>> oldmaster; rm .git/refs/heads/master; git branch master --set-upstream
>> oldmaster` will reset branch master to oldmaster (a bug?))
>
> Try:
>
>  git branch oldmaster
>  rm .git/refs/heads/master
>  git config branch.master.remote .
>  git config branch.master.merge refs/heads/oldmaster
>
> That being said, I still get "Initial commit on master". I think that
> stat_tracking_branch just gives up if the branch doesn't exist (which
> does make some sense). So in practice, I think your original and this
> one actually behave the same (sorry, I know that changing it was my
> suggestion).
>
> And no, the "--set-upstream" behavior is not a bug. At least not
> according to the documentation. ;)

yep, that's what i discovered too—but i don't care if this condition is 3 lines up or down. if stat_tracking_branch decides it will work for initial commits, then this code will do the expected thing

Show 6 quoted lines
>>  - colors to match output of `git branch` (green: current, red: remote)
>>  - output format is copy-pasteable, ahead/behind information is in the
>> same format as in `git branch -v`
>
> I think it's much nicer, though the colors are a bit much for my liking.
> Still, it's configurable, so I don't have to care. :)

i find the numbers quicker to spot when they are a different color from normal text, but if the majority objects i can remove them of course.

Show 8 quoted lines
>>  - branch information is still printed by default, i have to look into
>> commandline option parsing first. i was thinking of `git status -v -b`
>> (as in `git checkout -b` to mean branch)
>
> You may also want to have a configuration option if it is the output you
> prefer all the time (similarly, if you are using "git status -s" all the
> time, you might want a config option to make "git status" do what you
> want).

on my local system i have `alias.st = git status -sb`, so i don't really find a need to make a config option. actually i fall into both groups you described in your first answer: having a quick glance what files were changed and grouping files based on status. so i write both `git st` and `git status` quite often (also with `git stat` my alias for `git diff --stat` to see what changed content-wise)

Show 9 quoted lines
>> ---------8<----------------
>> From 82b4481d38ae0cd62030aeea67160656b7c763e2 Mon Sep 17 00:00:00 2001
>> From: Daniel Knittl-Frank <knittl89+git@googlemail.com>
>> Date: Tue, 20 Apr 2010 22:40:54 +0200
>> Subject: [PATCH] Show branch information in short output of git status
>
> This patch looks OK, but:
>
>  1. I think for the final version you can just squash in part 2/2.

should be no problem. the second patch changed quite a bit, so i thought it is easier to review when i send it as a separate patch. the final patch can be squashed of course

>  2. Your patch has wrapped lines which make it impossible to apply
>     without fixing up manually. This is a common gmail problem.  See
>     the "gmail" section of SubmittingPatches.

ok, browsed through that. i think i will just put my branch into a pasteservice or on a fileserver, unless the email way is *really* preferred—what about email attachments?

cheers, daniel
-- 
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
Jeff King· May 23, 2010, 09:23 UTC · re: Knittl · lore

Re: [PATCH] Show branch information in short output of git status

On Fri, May 14, 2010 at 08:54:07AM +0200, Knittl wrote:
Show 9 quoted lines
> > That being said, I still get "Initial commit on master". I think that
> > stat_tracking_branch just gives up if the branch doesn't exist (which
> > does make some sense). So in practice, I think your original and this
> > one actually behave the same (sorry, I know that changing it was my
> > suggestion).
> 
> yep, that's what i discovered too—but i don't care if this condition
> is 3 lines up or down. if stat_tracking_branch decides it will work
> for initial commits, then this code will do the expected thing
Agreed.
> should be no problem. the second patch changed quite a bit, so i
> thought it is easier to review when i send it as a separate patch. the
> final patch can be squashed of course

OK. Nobody else seems to be commenting, so I would go ahead and put together your final patch, cc-ing the maintainer.

Show 7 quoted lines
> >  2. Your patch has wrapped lines which make it impossible to apply
> >     without fixing up manually. This is a common gmail problem.  See
> >     the "gmail" section of SubmittingPatches.
> 
> ok, browsed through that. i think i will just put my branch into a
> pasteservice or on a fileserver, unless the email way is *really*
> preferred—what about email attachments?

Inline email is best, but I think an email attachment would be preferred to putting it on some out-of-band service (it's nice for the mailing list archive to have a record of everything).

-Peff
Michael J Gruber· May 25, 2010, 07:19 UTC · re: Jeff King · lore

Re: [PATCH] Show branch information in short output of git status

Jeff King venit, vidit, dixit 23.05.2010 11:23:
Show 20 quoted lines
> On Fri, May 14, 2010 at 08:54:07AM +0200, Knittl wrote:
> 
>>> That being said, I still get "Initial commit on master". I think that
>>> stat_tracking_branch just gives up if the branch doesn't exist (which
>>> does make some sense). So in practice, I think your original and this
>>> one actually behave the same (sorry, I know that changing it was my
>>> suggestion).
>>
>> yep, that's what i discovered too—but i don't care if this condition
>> is 3 lines up or down. if stat_tracking_branch decides it will work
>> for initial commits, then this code will do the expected thing
> 
> Agreed.
> 
>> should be no problem. the second patch changed quite a bit, so i
>> thought it is easier to review when i send it as a separate patch. the
>> final patch can be squashed of course
> 
> OK.  Nobody else seems to be commenting, so I would go ahead and put
> together your final patch, cc-ing the maintainer.
Been following silently :)

I'm a regular shortstatus user and find myself calling ordinary status just to get that part of info you're adding to shortstatus. I agree the default should stay as is and use aliases anyways. (I also think we need to clean up our option/config mess at one point and make at least long options the same as config variables.)

I even wanted to try out the patch but was stopped by:
Show 12 quoted lines
> 
>>>  2. Your patch has wrapped lines which make it impossible to apply
>>>     without fixing up manually. This is a common gmail problem.  See
>>>     the "gmail" section of SubmittingPatches.
>>
>> ok, browsed through that. i think i will just put my branch into a
>> pasteservice or on a fileserver, unless the email way is *really*
>> preferred—what about email attachments?
> 
> Inline email is best, but I think an email attachment would be preferred
> to putting it on some out-of-band service (it's nice for the mailing
> list archive to have a record of everything).

I'm really wondering what the problem is with git-send-email + GMail's smtp. I'm not saying there is none: I'm just observing that we seem to attract a lot of new contributors lately and that the email-inline-patch requirement seems to be a hurdle to quite a few. I've created a mob branch at

http://repo.or.cz/w/git/mjg.git
based off current master to which you can push, Daniel.

I'm wondering whether we should have a mob branch+receive hook solution where people can push to mob-{maint,master,next} (whose tip coincides with the resp. main branches), maybe allowing fast-forwards only, and where a post-receive-hook hook sends the patch to the list and resets the mob-... branch.

That would require push/pull expertise only, no MUA tweaking necessary.

Cheers, Michael

Jeff King· May 25, 2010, 07:22 UTC · re: Michael J Gruber · lore

Re: [PATCH] Show branch information in short output of git status

On Tue, May 25, 2010 at 09:19:18AM +0200, Michael J Gruber wrote:
Show 5 quoted lines
> I'm really wondering what the problem is with git-send-email + GMail's
> smtp. I'm not saying there is none: I'm just observing that we seem to
> attract a lot of new contributors lately and that the email-inline-patch
> requirement seems to be a hurdle to quite a few. I've created a mob
> branch at
I don't use gmail, but my impression was that the problem is one of:
  1. pushing to gmail's drafts folder via imap, and then using the web
     interface to send the email
  2. cutting and pasting into the web interface

I would hope that sending directly via SMTP with git-send-email would not get munged. That is pretty broken otherwise.

-Peff
Michael J Gruber· May 25, 2010, 08:10 UTC · re: Jeff King · lore

Re: [PATCH] Show branch information in short output of git status

Jeff King venit, vidit, dixit 25.05.2010 09:22:
Show 17 quoted lines
> On Tue, May 25, 2010 at 09:19:18AM +0200, Michael J Gruber wrote:
> 
>> I'm really wondering what the problem is with git-send-email + GMail's
>> smtp. I'm not saying there is none: I'm just observing that we seem to
>> attract a lot of new contributors lately and that the email-inline-patch
>> requirement seems to be a hurdle to quite a few. I've created a mob
>> branch at
> 
> I don't use gmail, but my impression was that the problem is one of:
> 
>   1. pushing to gmail's drafts folder via imap, and then using the web
>      interface to send the email
> 
>   2. cutting and pasting into the web interface
> 
> I would hope that sending directly via SMTP with git-send-email would
> not get munged. That is pretty broken otherwise.

Well, I know what the problem is with GMail's IMAP and web, but it's good to have it summed up this concisely ;)

I'm wondering what the problem is with GMail's SMTP: Technically there is none, but people shy away from using it (together with git-send-email). It does not even require setting up an MTA like sendmail or msmtp. But, apparently, this is a hurdle, which is why I brought up the mob-auto-send.

Michael
Michael J Gruber· May 25, 2010, 08:30 UTC · re: Jeff King · lore

[PATCH] Documentation/SubmittingPatches: clarify GMail section and SMTP

We keep getting mangled submissions from GMail's web interface. Try to be more proactive in SubmittingPatches by

- pointing to MUA specific instructions early on,
- structuring the GMail section more clearly,
- putting send-email/SMTP before imap-send/IMAP.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/SubmittingPatches |   40 ++++++++++++++++++++------------------
 1 files changed, 21 insertions(+), 19 deletions(-)
Show changes to Documentation/SubmittingPatches +21 −19
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8db22ef..b9204c7 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -41,6 +41,7 @@ Checklist (and a short version for the impatient):
 	  maintainer (gitster@pobox.com) if (and only if) the patch
 	  is ready for inclusion. If you use git-send-email(1),
 	  please test it first by sending email to yourself.
+	- see below for instructions specific to your mailer
 
 Long version:
 
@@ -546,9 +547,27 @@ Gmail
 
 GMail does not appear to have any way to turn off line wrapping in the web
 interface, so this will mangle any emails that you send.  You can however
-use any IMAP email client to connect to the google imap server, and forward
+use "git send e-mail" and send your patches through the GMail SMTP server, or
+use any IMAP email client to connect to the google IMAP server and forward
 the emails through that.
 
+To use "git send-email" and send your patches through the GMail SMTP server,
+edit ~/.gitconfig to specify your account settings:
+
+[sendemail]
+	smtpencryption = tls
+	smtpserver = smtp.gmail.com
+	smtpuser = user@gmail.com
+	smtppass = p4ssw0rd
+	smtpserverport = 587
+
+Once your commits are ready to be sent to the mailing list, run the
+following commands:
+
+  $ git format-patch --cover-letter -M origin/master -o outgoing/
+  $ edit outgoing/0000-*
+  $ git send-email outgoing/*
+
 To submit using the IMAP interface, first, edit your ~/.gitconfig to specify your
 account settings:
 
@@ -564,8 +583,7 @@ You might need to instead use: folder = "[Google Mail]/Drafts" if you get an err
 that the "Folder doesn't exist".
 
 Once your commits are ready to be sent to the mailing list, run the
-following command to send the patch emails to your Gmail Drafts
-folder.
+following commands:
 
   $ git format-patch --cover-letter -M --stdout origin/master | git imap-send
 
@@ -573,19 +591,3 @@ Just make sure to disable line wrapping in the email client (GMail web
 interface will line wrap no matter what, so you need to use a real
 IMAP client).
 
-Alternatively, you can use "git send-email" and send your patches
-through the GMail SMTP server.  edit ~/.gitconfig to specify your
-account settings:
-
-[sendemail]
-	smtpencryption = tls
-	smtpserver = smtp.gmail.com
-	smtpuser = user@gmail.com
-	smtppass = p4ssw0rd
-	smtpserverport = 587
-
-Once your commits are ready to be sent to the mailing list, run the
-following commands:
-
-  $ git format-patch --cover-letter -M origin/master -o outgoing/
-  $ git send-email outgoing/*
-- 
1.7.1.342.g1c280
Jeff King· May 25, 2010, 09:25 UTC · re: Michael J Gruber · lore

Re: [PATCH] Documentation/SubmittingPatches: clarify GMail section and SMTP

On Tue, May 25, 2010 at 10:30:13AM +0200, Michael J Gruber wrote:
Show 6 quoted lines
> We keep getting mangled submissions from GMail's web interface. Try to
> be more proactive in SubmittingPatches by
> 
> - pointing to MUA specific instructions early on,
> - structuring the GMail section more clearly,
> - putting send-email/SMTP before imap-send/IMAP.

Like I said elsewhere in the thread, I do not use gmail, but from our prior discussion and what I have seen on the list, these seem like good changes to me.

-Peff
Ævar Arnfjörð Bjarmason· May 25, 2010, 09:47 UTC · re: Jeff King · lore

Re: [PATCH] Documentation/SubmittingPatches: clarify GMail section and SMTP

On Tue, May 25, 2010 at 09:25, Jeff King <peff@peff.net> wrote:
Show 12 quoted lines
> On Tue, May 25, 2010 at 10:30:13AM +0200, Michael J Gruber wrote:
>
>> We keep getting mangled submissions from GMail's web interface. Try to
>> be more proactive in SubmittingPatches by
>>
>> - pointing to MUA specific instructions early on,
>> - structuring the GMail section more clearly,
>> - putting send-email/SMTP before imap-send/IMAP.
>
> Like I said elsewhere in the thread, I do not use gmail, but from our
> prior discussion and what I have seen on the list, these seem like good
> changes to me.

I use GMail, and I think the SMTP instructions should come first, these changes look good.

← back to recent threads