git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@ozlabs.org>
To: Michael Rappazzo <rappazzo@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 1/2] gitk: alter the ordering for the "Tags and heads" view
Date: Sat, 19 Mar 2016 17:53:47 +1100	[thread overview]
Message-ID: <20160319065347.GC27126@fergus.ozlabs.ibm.com> (raw)
In-Reply-To: <1458327097-92126-2-git-send-email-rappazzo@gmail.com>

On Fri, Mar 18, 2016 at 02:51:36PM -0400, Michael Rappazzo wrote:
> In the "Tags and heads" view, the list of refs is globally sorted.
> Because of this, the list of local refs (heads) can be interrupted by the
> list of remote refs.  This change re-orders the view to be: local refs,
> remote refs tracked by local refs, remote refs, tags, and then other refs.

This seems like a nice idea, and could lead on to having a section that
can be opened and closed for each of these categories.  However, I
have some comments on the implementation:

> @@ -9933,35 +9933,71 @@ proc refill_reflist {} {
>      global curview
>  
>      if {![info exists showrefstop] || ![winfo exists $showrefstop]} return
> -    set refs {}
> +    set localrefs {}
> +    set remoterefs {}
> +    set locally_tracked_remote_refs {}
> +    set tagrefs {}
> +    set otherrefs {}
>      foreach n [array names headids] {
> -	if {[string match $reflistfilter $n]} {
> +	if {![string match "remotes/*" $n] && [string match $reflistfilter $n]} {
>  	    if {[commitinview $headids($n) $curview]} {
> -		lappend refs [list $n H]
> +		lappend localrefs [list $n H]
> +		catch {set remote_name [exec git config --get branch.$n.remote]}
> +		if {$remote_name ne ""} {
> +		    catch {set remote_ref [exec git config --get branch.$n.merge]}
> +		    set remote_ref [string map {"refs/heads/" ""} $remote_ref]
> +		    set locally_tracked_remote_ref "remotes/$remote_name/$remote_ref"
> +		    set upstream_exists ""
> +		    catch {set upstream_exists [exec git rev-parse --verify $locally_tracked_remote_ref]}
> +		    if {$upstream_exists ne ""} {
> +			if {[lsearch $locally_tracked_remote_refs [list $locally_tracked_remote_ref H]] < 0} {
> +			    lappend locally_tracked_remote_refs [list $locally_tracked_remote_ref H]
> +			}
> +		    }
> +		}

I'm worried about the number of external git invocations we're
potentially doing here, and how long that would take when you have a
lot of heads.  Can we cache the results perhaps?  Or is there a way to
do a single git command and get a list of tracking branches with their
remotes etc.?

Also, the default for lsearch is glob-style matching.  It's unlikely
that ref names would have any of *?[\ in them, but AFAIK it's not
impossible.  You probably want -exact in there.

Further, the kind of thing you are using lsearch for can often be done
more efficiently using an array (which becomes essentially a hash
table underneath).

Paul.

  reply	other threads:[~2016-03-19  7:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18 18:51 [PATCH v2 0/2] gitk: changes for the "Tags and heads" view Michael Rappazzo
2016-03-18 18:51 ` [PATCH v2 1/2] gitk: alter the ordering " Michael Rappazzo
2016-03-19  6:53   ` Paul Mackerras [this message]
2016-03-18 18:51 ` [PATCH v2 2/2] gitk: add an option to enable sorting the "Tags and heads" view by ref type Michael Rappazzo
2016-03-19  6:55   ` Paul Mackerras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160319065347.GC27126@fergus.ozlabs.ibm.com \
    --to=paulus@ozlabs.org \
    --cc=git@vger.kernel.org \
    --cc=rappazzo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).