[PATCH] branch: add show-tracking option

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

Signed-off-by: Felipe Contreras <redacted>
---
 Documentation/git-branch.txt | 5 ++++-
 builtin/branch.c             | 4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index b7cb625..1db04cd 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt

@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git branch' [--color[=<when>] | --no-color] [-r | -a]
-	[--list] [-v [--abbrev=<length> | --no-abbrev]]
+	[--list] [-v [--abbrev=<length> | --no-abbrev] --show-tracking]
 	[--column[=<options>] | --no-column]
 	[(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]

@@ -154,6 +154,9 @@ This option is only applicable in non-verbose mode.
 --no-abbrev::
 	Display the full sha1s in the output listing rather than abbreviating them.
 
+--show-tracking::
+	Display the tracking information when using --verbose, or not.
+
 -t::
 --track::
 	When creating a new branch, set up configuration to mark the

diff --git a/builtin/branch.c b/builtin/branch.c
index 0836890..2b586ea 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c

@@ -33,6 +33,7 @@ static const char * const builtin_branch_usage[] = {
 
 static const char *head;
 static unsigned char head_sha1[20];
+static int show_tracking = 1;
 
 static int branch_use_color = -1;
 static char branch_colors[][COLOR_MAXLEN] = {

@@ -424,7 +425,7 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
 	struct branch *branch = branch_get(branch_name);
 	struct strbuf fancy = STRBUF_INIT;
 
-	if (!stat_tracking_info(branch, &ours, &theirs)) {
+	if (!(show_tracking && stat_tracking_info(branch, &ours, &theirs))) {
 		if (branch && branch->merge && branch->merge[0]->dst &&
 		    show_upstream_ref) {
 			ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);

@@ -840,6 +841,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 			opt_parse_merge_filter, (intptr_t) "HEAD",
 		},
 		OPT_COLUMN(0, "column", &colopts, N_("list branches in columns")),
+		OPT_BOOL(0, "show-tracking", &show_tracking, N_("show tracking information")),
 		OPT_END(),
 	};
 

-- 
1.8.3.rc1.579.g184e698

On Thu, May 16, 2013 at 2:48 AM, Felipe Contreras
[off-list ref] wrote:

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

BTW. I ideally I would switch around so -v has upstream, and --vv has
the tracking information. But that is changing the behavior.

-- 
Felipe Contreras

On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras
[off-list ref] wrote:

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

Or we could cache the information somewhere in .git. If a ref still
points to <SHA-1> as recorded in the cache, use the cached tracking
information, otherwise go the slow way.
--
Duy

On Thu, May 16, 2013 at 2:54 AM, Duy Nguyen [off-list ref] wrote:

On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras
[off-list ref] wrote:

quoted

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

Or we could cache the information somewhere in .git. If a ref still
points to <SHA-1> as recorded in the cache, use the cached tracking
information, otherwise go the slow way.

That might be nice, but even if that was fast, I personally never use
that information, so I still would want this option.

-- 
Felipe Contreras

Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

I really like the idea of allowing that - not just because I've
suggested so myself in the past ;)

I feel, though, that we're really exploding our option and config realm.
For "git branch" in list mode, we are already able to stack "-v", i.e.
"-v" and "-vv" do different things. How about maybe adding "-vvv" and
arranging things so that the verbosity and the run time increases with
the number of v's?

-v list with sha1 + subject of last commit
-vv add upstream branch name
-vvv add ahead/behind info (the only costly mode)
-vvvv same with "--cherry" (ahead/behind/same)

Or maybe combine the middle two cases into "-vv", which means it would
be the same as "-vv", with only "-v" changing what it does now.

Yes, this changes current behavior (at least fpr -v), which sucks
anyways because of the costly lookup. And those scripting around "branch
-v" should get what they deserve. (I may sound annoyed by our
compatibility brakes, but here's a case where breaking it should be OK.)

On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber
[off-list ref] wrote:

Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:

quoted

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

I really like the idea of allowing that - not just because I've
suggested so myself in the past ;)

I feel, though, that we're really exploding our option and config realm.
For "git branch" in list mode, we are already able to stack "-v", i.e.
"-v" and "-vv" do different things. How about maybe adding "-vvv" and
arranging things so that the verbosity and the run time increases with
the number of v's?

-v list with sha1 + subject of last commit
-vv add upstream branch name
-vvv add ahead/behind info (the only costly mode)
-vvvv same with "--cherry" (ahead/behind/same)

Yeah, I thought about that too.

Or maybe combine the middle two cases into "-vv", which means it would
be the same as "-vv", with only "-v" changing what it does now.

Please no, I would like to see 'upstream', but not ahead/behind info.
In fact, that's my whole motivation behind this patch.

Yes, this changes current behavior (at least fpr -v), which sucks
anyways because of the costly lookup. And those scripting around "branch
-v" should get what they deserve. (I may sound annoyed by our
compatibility brakes, but here's a case where breaking it should be OK.)

I also agree that it would be OK to break this.

Alternatively, I've been thinking that we should have a v2.0 mode, or
a v2.0 branch, where all the compatibility breakage things go. We have
been so careful at not breaking things, that we have been too good at
stacking hacks and configurations all over the place, and in my
experience it's not unusual that right after an incompatibility
release, someone realizes that we forgot some compat breakage things,
and oh, well, maybe for v3.0.

The ones I have in mind are:

color.ui=true
merge.defaulttoupstream=true
format.coverletter=auto
branch.autosetupmerge=always
mergetool.prompt=false

Cheers.

-- 
Felipe Contreras

Felipe Contreras venit, vidit, dixit 16.05.2013 10:09:

On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber
[off-list ref] wrote:

quoted

Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:

quoted

Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.

I really like the idea of allowing that - not just because I've
suggested so myself in the past ;)

I feel, though, that we're really exploding our option and config realm.
For "git branch" in list mode, we are already able to stack "-v", i.e.
"-v" and "-vv" do different things. How about maybe adding "-vvv" and
arranging things so that the verbosity and the run time increases with
the number of v's?

-v list with sha1 + subject of last commit
-vv add upstream branch name
-vvv add ahead/behind info (the only costly mode)
-vvvv same with "--cherry" (ahead/behind/same)

Yeah, I thought about that too.

quoted

Or maybe combine the middle two cases into "-vv", which means it would
be the same as "-vv", with only "-v" changing what it does now.

Please no, I would like to see 'upstream', but not ahead/behind info.
In fact, that's my whole motivation behind this patch.

I'd be fine with combining the first two also.

quoted

Yes, this changes current behavior (at least fpr -v), which sucks
anyways because of the costly lookup. And those scripting around "branch
-v" should get what they deserve. (I may sound annoyed by our
compatibility brakes, but here's a case where breaking it should be OK.)

I also agree that it would be OK to break this.

Alternatively, I've been thinking that we should have a v2.0 mode, or
a v2.0 branch, where all the compatibility breakage things go. We have
been so careful at not breaking things, that we have been too good at
stacking hacks and configurations all over the place, and in my
experience it's not unusual that right after an incompatibility
release, someone realizes that we forgot some compat breakage things,
and oh, well, maybe for v3.0.

The ones I have in mind are:

color.ui=true
merge.defaulttoupstream=true
format.coverletter=auto
branch.autosetupmerge=always
mergetool.prompt=false

Cheers.

Yes. Additionally, there are things which we can break during normal
releases, but somehow the compatibility discussions have kept us from
doing so. Maybe we need a clearer separation of porcellain and plumbing
again? Or a clearer definition of x, y, z in x.y.z releases? We haven't
even used y increases for incompatible ui changes that much.

Michael

On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber
[off-list ref] wrote:

I feel, though, that we're really exploding our option and config realm.
For "git branch" in list mode, we are already able to stack "-v", i.e.
"-v" and "-vv" do different things. How about maybe adding "-vvv" and
arranging things so that the verbosity and the run time increases with
the number of v's?

-v list with sha1 + subject of last commit
-vv add upstream branch name
-vvv add ahead/behind info (the only costly mode)
-vvvv same with "--cherry" (ahead/behind/same)

Or maybe combine the middle two cases into "-vv", which means it would
be the same as "-vv", with only "-v" changing what it does now.

What if I want something in -vvvv except some in -vv? I think to avoid
option explosion, maybe we can adopt --pretty=format:xxx from "git
log" and let the user decideswhat (and how) to display. "pretty" code
learns about alignment already, which may be useful here.
--
Duy

Duy Nguyen venit, vidit, dixit 16.05.2013 10:23:

On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber
[off-list ref] wrote:

quoted

I feel, though, that we're really exploding our option and config realm.
For "git branch" in list mode, we are already able to stack "-v", i.e.
"-v" and "-vv" do different things. How about maybe adding "-vvv" and
arranging things so that the verbosity and the run time increases with
the number of v's?

-v list with sha1 + subject of last commit
-vv add upstream branch name
-vvv add ahead/behind info (the only costly mode)
-vvvv same with "--cherry" (ahead/behind/same)

Or maybe combine the middle two cases into "-vv", which means it would
be the same as "-vv", with only "-v" changing what it does now.

What if I want something in -vvvv except some in -vv? I think to avoid
option explosion, maybe we can adopt --pretty=format:xxx from "git
log" and let the user decideswhat (and how) to display. "pretty" code
learns about alignment already, which may be useful here.
--
Duy

Sure, that is the big solution we've been talking about. Unify
for-each-ref formats and log formats and use that. After all, "git
branch" in list mode really is for-each-ref, and should be transparently
so; same goes for "git tag". Think "git rev-list" and "git ref-list"!

But I guess we'll be compabeaten ;)

Michael

On Thu, May 16, 2013 at 3:40 PM, Michael J Gruber
[off-list ref] wrote:

quoted

What if I want something in -vvvv except some in -vv? I think to avoid
option explosion, maybe we can adopt --pretty=format:xxx from "git
log" and let the user decideswhat (and how) to display. "pretty" code
learns about alignment already, which may be useful here.
--
Duy

Sure, that is the big solution we've been talking about. Unify
for-each-ref formats and log formats and use that. After all, "git
branch" in list mode really is for-each-ref, and should be transparently
so; same goes for "git tag". Think "git rev-list" and "git ref-list"!

Again I forgot about for-each-ref. Sounds like sharing code between
for-each-ref and branch is a good thing to do. Then just add more
candy placeholders from git-log like %C(xx). Sounds like a fun topic.

But I guess we'll be compabeaten ;)

No idea what that last word means :(
--
Duy