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

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

[Knittl]

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(-)

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!

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

[Jeff King]

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;

> +	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.

> +	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

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

[Knittl]

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:
> 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?

>  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.

>> +     if(!s->branch) return;
>
> Style nits. This should be:
>
>  if (!s->branch)
>          return;

done …

>> +     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?

>  ## 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>

>> +     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(-)

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!

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

[Knittl]

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(-)

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

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

[Jeff King]

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).

> ---------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

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

[Knittl]

On Wed, May 12, 2010 at 3:35 PM, Jeff King <peff@peff.net> wrote:
> 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

>>  - 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.

>>  - 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)

>> ---------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!

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

[Jeff King]

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.

> >  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

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 23.05.2010 11:23:
> 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:

> 
>>>  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

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

[Jeff King]

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.

-Peff

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 25.05.2010 09:22:
> 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

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

[Michael J Gruber]

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(-)

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

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

[Jeff King]

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.

-Peff

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

[Ævar Arnfjörð Bjarmason]

On Tue, May 25, 2010 at 09:25, Jeff King <peff@peff.net> wrote:
> 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.