patchbranch: add show-tracking option

> On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras
> <felipe.contreras@gmail.com> 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.

> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  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(),
>  	};
>  
> 

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

> On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> 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)
> 
> 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.

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

> On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber
> <git@drmicha.warpmail.net> 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

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

> On Thu, May 16, 2013 at 3:40 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>>> 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 :(

> On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> *1* indented because this is dependent of @{u}; showing ahead/behind
>>     without showing @{u} would not make any sense.
>
> That's what 'git branch -v' does.

> On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> *1* indented because this is dependent of @{u}; showing ahead/behind
>>     without showing @{u} would not make any sense.
>
> That's what 'git branch -v' does.