[PATCH 0/6] Provide for config to specify tags not to abbreviate

Hi.

Please find in the following mails patches which provide a way to make
gitk display certain tags in full, even if they would normally be
abbreviated.

There are four patches to gitk, three to prepare the ground, and one
to introduce the new feature.

There is one patch for git, to just document the new config variable.

I hope this is the right way to submit this series.  Thanks for your
attention.


As I say in the patch "gitk: Provide for config to specify tags not to
abbreviate":

The config setting is in git config logs.* rather than gitk's
own configuration, because:

 - Tools which manage git trees may want to set this, depending
   on their knowledge of the nature of the tags likely to be
   present;

 - Whether this property ought to be set is mostly a property of the
   contents of the tag namespaces in the tree, not a user preference.
   (Although of course user preferences are supported.)

 - Other git utilities (or out of tree utilities) may want to
   reference this setting for their own display purposes.

There will be another, separate, patch to the `git' tree to document
this config option.

Background motivation:

Debian's dgit archive gateway tool generates and uses tags called
archive/debian/VERSION.  If such a tag refers to a Debian source tree,
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.

We would therefore like a way to specify that such tags should be
displayed in full.  dgit will be able to set an appropriate config
setting in the trees it deals with.



Ian Jackson (4):
  gitk: Internal: drawtags: Abolish "singletag" variable
  gitk: Internal: drawtags: Idempotently reset "ntags"
  gitk: drawtags: Introduce concept of unabbreviated marks
  gitk: Provide for config to specify tags not to abbreviate

 gitk | 34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)


Ian Jackson (1):
  config docs: Provide for config to specify tags not to abbreviate

 Documentation/config.txt | 8 ++++++++
 1 file changed, 8 insertions(+)


-- 
2.10.1

We are going to want to show some tags in full, even if they are long
or there are other tags.  Do this by filtering the tags into
`marks_unabbrev' and `marks'.  `marks_unabbrev' bypasses the tag
abbreviation, and is put on the front of the marks array after any
abbreviation has been done.

No functional change right now because no tags are considered
`unabbrev'.

Signed-off-by: Ian Jackson <redacted>
---
 gitk | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
index 31aecda..d76f1e3 100755
--- a/gitk
+++ b/gitk

@@ -6546,6 +6546,10 @@ proc totalwidth {l font extra} {
     return $tot
 }
 
+proc tag_want_unabbrev {tag} {
+    return 0
+}
+
 proc drawtags {id x xt y1} {
     global idtags idheads idotherrefs mainhead
     global linespc lthickness

@@ -6564,8 +6568,16 @@ proc drawtags {id x xt y1} {
     set delta [expr {int(0.5 * ($linespc - $lthickness))}]
     set extra [expr {$delta + $lthickness + $linespc}]
 
+    set marks_unabbrev {}
     if {[info exists idtags($id)]} {
-	set marks $idtags($id)
+	set marks {}
+	foreach tag $idtags($id) {
+	    if {[tag_want_unabbrev $tag]} {
+		lappend marks_unabbrev $tag
+	    } else {
+		lappend marks $tag
+	    }
+	}
 	set ntags [llength $marks]
 	if {$ntags > $maxtags ||
 	    [totalwidth $marks mainfont $extra] > $maxwidth} {

@@ -6577,6 +6589,7 @@ proc drawtags {id x xt y1} {
 	    }
 	}
     }
+    set marks [concat $marks_unabbrev $marks]
     set ntags [llength $marks]
 
     if {[info exists idheads($id)]} {

-- 
2.10.1

The previous code tracked its change to the length of `marks' by
updateing the variable `ntags'.  This is a bit fragile and cumbersome,
and we are going to want to modify `marks' some more in a moment.

Instead, simply reset ntags to the length of marks, after we have
possibly done any needed abbreviation.

No functional change.

Signed-off-by: Ian Jackson <redacted>
---
 gitk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
index 42fa41a..31aecda 100755
--- a/gitk
+++ b/gitk

@@ -6575,9 +6575,10 @@ proc drawtags {id x xt y1} {
 	    } else {
 		set marks [list [format "%d tags..." $ntags]]
 	    }
-	    set ntags 1
 	}
     }
+    set ntags [llength $marks]
+
     if {[info exists idheads($id)]} {
 	set marks [concat $marks $idheads($id)]
 	set nheads [llength $idheads($id)]

-- 
2.10.1

We are going to want to make the contents of `marks' somewhat more
complicated in a moment, so it won't be possible to use what is
effectively a single variable to represent the status of the whole of
the non-heads part of the marks list.

Luckily the strings that replace actual tag names, in the `singletag'
case, are not themselves valid tag names.  So they can be detected
directly.

(Also, `singletag' was not quite right anyway: really it meant that
the tag name(s) had been abbreviated.)

No functional change.

Signed-off-by: Ian Jackson <redacted>
---
 gitk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gitk b/gitk
index 805a1c7..42fa41a 100755
--- a/gitk
+++ b/gitk

@@ -6570,7 +6570,6 @@ proc drawtags {id x xt y1} {
 	if {$ntags > $maxtags ||
 	    [totalwidth $marks mainfont $extra] > $maxwidth} {
 	    # show just a single "n tags..." tag
-	    set singletag 1
 	    if {$ntags == 1} {
 		set marks [list "tag..."]
 	    } else {

@@ -6620,7 +6619,7 @@ proc drawtags {id x xt y1} {
 		       $xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
 		       -width 1 -outline $tagoutlinecolor -fill $tagbgcolor \
 		       -tags tag.$id]
-	    if {$singletag} {
+	    if {[regexp {^tag\.\.\.|^\d+ } $tag]} {
 		set tagclick [list showtags $id 1]
 	    } else {
 		set tagclick [list showtag $tag_quoted 1]

-- 
2.10.1

Tags matching a new multi-valued config option log.noAbbrevTags
are not abbreviated.

The config setting is in git config logs.* rather than gitk's
own configuration, because:

 - Tools which manage git trees may want to set this, depending
   on their knowledge of the nature of the tags likely to be
   present;

 - Whether this property ought to be set is mostly a property of the
   contents of the tag namespaces in the tree, not a user preference.
   (Although of course user preferences are supported.)

 - Other git utilities (or out of tree utilities) may want to
   reference this setting for their own display purposes.

There will be another, separate, patch to the `git' tree to document
this config option.

Background motivation:

Debian's dgit archive gateway tool generates and uses tags called
archive/debian/VERSION.  If such a tag refers to a Debian source tree,
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.

We would therefore like a way to specify that such tags should be
displayed in full.  dgit will be able to set an appropriate config
setting in the trees it deals with.

Signed-off-by: Ian Jackson <redacted>
---
 gitk | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/gitk b/gitk
index d76f1e3..515d7b0 100755
--- a/gitk
+++ b/gitk

@@ -6547,6 +6547,14 @@ proc totalwidth {l font extra} {
 }
 
 proc tag_want_unabbrev {tag} {
+    global noabbrevtags
+    # noabbrevtags was reversed when we read config, so take first match
+    foreach pat $noabbrevtags {
+	set inverted [regsub {^\^} $pat {} pat]
+	if {[string match $pat $tag]} {
+	    return [expr {!$inverted}]
+	}
+    }
     return 0
 }
 

@@ -12138,6 +12146,11 @@ set tclencoding [tcl_encoding $gitencoding]
 if {$tclencoding == {}} {
     puts stderr "Warning: encoding $gitencoding is not supported by Tcl/Tk"
 }
+set noabbrevtags {}
+catch {
+    set noabbrevtags [exec git config --get-all log.noAbbrevTags]
+}
+set noabbrevtags [lreverse [split $noabbrevtags "\n"]]
 
 set gui_encoding [encoding system]
 catch {

-- 
2.10.1

Tags matching a new multi-valued config option log.noAbbrevTags
should not be abbreviated.  Currently this config option is
used only by gitk (and the patch to gitk will come via the
gitk maintainer tree).

The config setting is in git config logs.* rather than gitk's
own configuration, because:

 - Tools which manage git trees may want to set this, depending
   on their knowledge of the nature of the tags likely to be
   present;

 - Whether this property ought to be set is mostly a property of the
   contents of the tag namespaces in the tree, not a user preference.
   (Although of course user preferences are supported.)

 - Other git utilities (or out of tree utilities) may want to
   reference this setting for their own display purposes.

Background motivation:

Debian's dgit archive gateway tool generates and uses tags called
archive/debian/VERSION.  If such a tag refers to a Debian source tree,
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.

We would therefore like a way to specify that such tags should be
displayed in full.  dgit will be able to set an appropriate config
setting in the trees it deals with.

Signed-off-by: Ian Jackson <redacted>
---
 Documentation/config.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index a0ab66a..6aade4f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt

@@ -2002,6 +2002,14 @@ log.abbrevCommit::
 	linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
 	override this option with `--no-abbrev-commit`.
 
+log.noAbbrevTags::
+	Each value is a glob pattern, specifying tag nammes which
+	should always be displayed in full, even when other tags may
+	be omitted or abbreviated (for example, by linkgit:gitk[1]).
+	Values starting with `^` specify tags which should be
+	abbreviated.  The order is important: the last match, in the
+	most-local configuration, wins.
+
 log.date::
 	Set the default date-time mode for the 'log' command.
 	Setting a value for log.date is similar to using 'git log''s

-- 
2.10.1

Ian Jackson writes ("[PATCH 0/6] Provide for config to specify tags not to abbreviate"):

Please find in the following mails patches which provide a way to make
gitk display certain tags in full, even if they would normally be
abbreviated.

There are four patches to gitk, three to prepare the ground, and one
to introduce the new feature.

There is one patch for git, to just document the new config variable.

The eagle-eyed reader will spot that that makes 5 patches, not 6.
There are indeed only 5.  The subject mentioning 6 is a mistake -
sorry.

Thanks,
Ian.

-- 
Ian Jackson [off-list ref]   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson
[off-list ref] wrote:

+log.noAbbrevTags::
+       Each value is a glob pattern, specifying tag nammes which
+       should always be displayed in full, even when other tags may
+       be omitted or abbreviated (for example, by linkgit:gitk[1]).
+       Values starting with `^` specify tags which should be
+       abbreviated.  The order is important: the last match, in the
+       most-local configuration, wins.
+

It seems weird that this description implies some sort of behavior
change in core git itself, but in fact is only used as a reference for
other tools that may or may not honor it. I guess the reasoning here
is to try to get other external tools that abbreviate tags to also
honor this? But it still seems pretty weird to have a documented
config that has no code in core git to honor it...

Thanks,
Jake

Am 08.11.2016 um 01:54 schrieb Ian Jackson:

Please find in the following mails patches which provide a way to make
gitk display certain tags in full, even if they would normally be
abbreviated.

TBH, I see a violation of tool independence with the choice of preference storage. Abbreviation of tags isn't a property of the repository, but a pure visual thing (screen real estate, whatever), so it should be handled by the tool doing the visuals, only.

Your use case looks like a nice opportunity for

- adding a Gitk user preference on how long displayed tags are allowed to be (instead of distinguishing between abbreviated and unabbreviated ones; set it to 999 for your use case) and/or

- even better, abbreviate them depending on the size of the visible area, like a web browser would do, and/or

- considering whether tags should be abbreviated on the left instead of on the right and/or

- finding a mechanism to show them in full length even on small visible areas.

The latter could be done by a tooltip appearing when hovering with the mouse over an abbreviated tag or by allowing multiple lines for a single commit in the list of commits.

Trying to enforce long names just means they're not cut off by the abbreviation algorithm, but by the right boundary of the visible area.


My $0.02,
Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/

Jacob Keller writes ("Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate"):

On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson
[off-list ref] wrote:

quoted

+log.noAbbrevTags::
+       Each value is a glob pattern, specifying tag nammes which
+       should always be displayed in full, even when other tags may
+       be omitted or abbreviated (for example, by linkgit:gitk[1]).
+       Values starting with `^` specify tags which should be
+       abbreviated.  The order is important: the last match, in the
+       most-local configuration, wins.
+

It seems weird that this description implies some sort of behavior
change in core git itself, but in fact is only used as a reference for
other tools that may or may not honor it. I guess the reasoning here
is to try to get other external tools that abbreviate tags to also
honor this? But it still seems pretty weird to have a documented
config that has no code in core git to honor it...

Thanks for your attention.

Yes, I agree that it does seem weird.  But the alternatives seem
worse.  I think it's probably best if options like this (currently
only honoured by out-of-core tools but of general usefulness) are
collected together here.

There is a precedent: `git config gui.encoding' is, according to the
documentation, honoured only by git-gui and gitk.

Calling the config option `gitk.noAbbrevTags' would be possible but
that would invite everyone else to invent their own, which would be
quite annoying.  (Also, gitk does not have any gitk-specific git
config options right now, AIUI.  It does honour `git config
gui.encoding'.)

Would it help to add a sentence to the documentation saying that this
is currently only honoured by gitk ?  (The paragraph for gui.encoding
says something similar.)  Of course I don't know who else abbreviates
tags, but as they gain support they could be added to the docs.

Thanks,
Ian.

-- 
Ian Jackson [off-list ref]   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Markus Hitter writes ("Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate"):

TBH, I see a violation of tool independence with the choice of
preference storage. Abbreviation of tags isn't a property of the
repository, but a pure visual thing (screen real estate, whatever),
so it should be handled by the tool doing the visuals, only.

As I explained in my cover letter, the set of tags which are important
enough not to abbreviate, even if they would normally be abbreviated,
is indeed a property of the repository.

The alternative would be for a tool like gitk to grow an
ever-increasing set of heuristics.  Or, worse, for a tool like dgit
(which knows that archive/* are special) to edit the user's personal
gitk settings.

Your use case looks like a nice opportunity for

- adding a Gitk user preference on how long displayed tags are
  allowed to be (instead of distinguishing between abbreviated and
  unabbreviated ones; set it to 999 for your use case) and/or

This would be wrong, because it's only certain tags that ought not to
be abbreviated.  The right way to identify those tags is by 1. what
repo they are in 2. what their name is.  (It might be possible to
identify them by content or something - for example, the interesting
archive/* tags all refer to commits whose trees contain debian/ - but
that is getting quite out of hand.)

What you propose are possible general improvements to the abbreviation
system in gitk.  But they do not address the fundamental point that
some tags are much more interesting than others.  It is this latter
point that I am trying to deal with.

Ian.

-- 
Ian Jackson [off-list ref]   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

On Tue, Nov 08, 2016 at 10:51:33AM +0000, Ian Jackson wrote:

Yes, I agree that it does seem weird.  But the alternatives seem
worse.  I think it's probably best if options like this (currently
only honoured by out-of-core tools but of general usefulness) are
collected together here.

There is a precedent: `git config gui.encoding' is, according to the
documentation, honoured only by git-gui and gitk.

Yeah, I think git's config system was always designed to carry options
for porcelains outside of git-core itself. So your new option fits into
that.

I think the two things I found weird were:

  - it's in the "log" section, which makes me think it's an option for
    git-log. But it's not. I'm not sure what the _right_ section is, but
    hopefully it would make it clear that this is command-agnostic.

    Something like "gui.abbrevTags" might be OK (and as you note, has
    precedence). But of course it's possible that a command like "tig"
    could learn to support it.  I'm not sure if that counts as a GUI or
    not. :)

  - The description talks about tag abbreviation, but doesn't really
    define it. Not being a gitk user, it was hard for me to figure out
    whether this was even relevant. Does it mean turning
    "refs/tags/v1.0" into "1.0"? From the rest of the series, it sounds
    like no. That should be more clear from the documentation.

-Peff

Jeff King writes ("Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate"):

Yeah, I think git's config system was always designed to carry options
for porcelains outside of git-core itself. So your new option fits into
that.

Good, thanks.

I think the two things I found weird were:

  - it's in the "log" section, which makes me think it's an option for
    git-log. But it's not. I'm not sure what the _right_ section is, but
    hopefully it would make it clear that this is command-agnostic.

    Something like "gui.abbrevTags" might be OK (and as you note, has
    precedence). But of course it's possible that a command like "tig"
    could learn to support it.  I'm not sure if that counts as a GUI or
    not. :)

I don't really have an opinion about the name.  gui.abbrevTags would
be a possibility.  (It's a bit odd that implicitly, the default would
be `*'.)

  - The description talks about tag abbreviation, but doesn't really
    define it. Not being a gitk user, it was hard for me to figure out
    whether this was even relevant. Does it mean turning
    "refs/tags/v1.0" into "1.0"? From the rest of the series, it sounds
    like no. That should be more clear from the documentation.

I can do that, sure.

By default, gitk doesn't like to use much screen real estate for tags.
If there are long tag names, or many tags, it shows them all as a
single small indication saying just `<tag...|' or whatever with the
literal `tag...', not with the tag value.

Maybe a better name would be
   gui.alwaysShowTags
?

I'm happy to be just told what the name ought to be, if the gitk and
git maintainers can agree.  It seems largely a matter of taste.

Thanks,
Ian.

-- 
Ian Jackson [off-list ref]   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.