{"thread":{"id":"44439","subject":"[PATCH 0/6] Provide for config to specify tags not to abbreviate","startedAt":"2016-11-08T00:53:13Z","lastAt":"2016-11-10T00:36:29Z","messageCount":18,"participants":["Ian Jackson","Jacob Keller","Markus Hitter","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":6},"messages":[{"id":"305523","messageId":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","threadId":"44439","inReplyTo":null,"subject":"[PATCH 0/6] Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:52:36Z","receivedAt":"2016-11-08T00:53:13Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Hi.\n\nPlease find in the following mails patches which provide a way to make\ngitk display certain tags in full, even if they would normally be\nabbreviated.\n\nThere are four patches to gitk, three to prepare the ground, and one\nto introduce the new feature.\n\nThere is one patch for git, to just document the new config variable.\n\nI hope this is the right way to submit this series. Thanks for your\nattention.\n\n\nAs I say in the patch \"gitk: Provide for config to specify tags not to\nabbreviate\":\n\nThe config setting is in git config logs.* rather than gitk's\nown configuration, because:\n\n - Tools which manage git trees may want to set this, depending\n on their knowledge of the nature of the tags likely to be\n present;\n\n - Whether this property ought to be set is mostly a property of the\n contents of the tag namespaces in the tree, not a user preference.\n (Although of course user preferences are supported.)\n\n - Other git utilities (or out of tree utilities) may want to\n reference this setting for their own display purposes.\n\nThere will be another, separate, patch to the `git' tree to document\nthis config option.\n\nBackground motivation:\n\nDebian's dgit archive gateway tool generates and uses tags called\narchive/debian/VERSION. If such a tag refers to a Debian source tree,\nit is probably very interesting because it refers to a version\nactually uploaded to Debian by the Debian package maintainer.\n\nWe would therefore like a way to specify that such tags should be\ndisplayed in full. dgit will be able to set an appropriate config\nsetting in the trees it deals with.\n\n\n\nIan Jackson (4):\n gitk: Internal: drawtags: Abolish \"singletag\" variable\n gitk: Internal: drawtags: Idempotently reset \"ntags\"\n gitk: drawtags: Introduce concept of unabbreviated marks\n gitk: Provide for config to specify tags not to abbreviate\n\n gitk | 34 ++++++++++++++++++++++++++++++----\n 1 file changed, 30 insertions(+), 4 deletions(-)\n\n\nIan Jackson (1):\n config docs: Provide for config to specify tags not to abbreviate\n\n Documentation/config.txt | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\n\n-- \n2.10.1\n\n"},{"id":"305524","messageId":"20161108005241.19888-4-ijackson@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH GITK 3/6] gitk: drawtags: Introduce concept of unabbreviated marks","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:52:39Z","receivedAt":"2016-11-08T00:53:16Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"We are going to want to show some tags in full, even if they are long\nor there are other tags. Do this by filtering the tags into\n`marks_unabbrev' and `marks'. `marks_unabbrev' bypasses the tag\nabbreviation, and is put on the front of the marks array after any\nabbreviation has been done.\n\nNo functional change right now because no tags are considered\n`unabbrev'.\n\nSigned-off-by: Ian Jackson \n---\n gitk | 15 ++++++++++++++-\n 1 file changed, 14 insertions(+), 1 deletion(-)\n\ndiff --git a/gitk b/gitk\nindex 31aecda..d76f1e3 100755\n--- a/gitk\n+++ b/gitk\n@@ -6546,6 +6546,10 @@ proc totalwidth {l font extra} {\n return $tot\n }\n \n+proc tag_want_unabbrev {tag} {\n+ return 0\n+}\n+\n proc drawtags {id x xt y1} {\n global idtags idheads idotherrefs mainhead\n global linespc lthickness\n@@ -6564,8 +6568,16 @@ proc drawtags {id x xt y1} {\n set delta [expr {int(0.5 * ($linespc - $lthickness))}]\n set extra [expr {$delta + $lthickness + $linespc}]\n \n+ set marks_unabbrev {}\n if {[info exists idtags($id)]} {\n-\tset marks $idtags($id)\n+\tset marks {}\n+\tforeach tag $idtags($id) {\n+\t if {[tag_want_unabbrev $tag]} {\n+\t\tlappend marks_unabbrev $tag\n+\t } else {\n+\t\tlappend marks $tag\n+\t }\n+\t}\n \tset ntags [llength $marks]\n \tif {$ntags > $maxtags ||\n \t [totalwidth $marks mainfont $extra] > $maxwidth} {\n@@ -6577,6 +6589,7 @@ proc drawtags {id x xt y1} {\n \t }\n \t}\n }\n+ set marks [concat $marks_unabbrev $marks]\n set ntags [llength $marks]\n \n if {[info exists idheads($id)]} {\n-- \n2.10.1\n\n"},{"id":"305525","messageId":"20161108005241.19888-3-ijackson@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH GITK 2/6] gitk: Internal: drawtags: Idempotently reset \"ntags\"","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:52:38Z","receivedAt":"2016-11-08T00:53:18Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"The previous code tracked its change to the length of `marks' by\nupdateing the variable `ntags'. This is a bit fragile and cumbersome,\nand we are going to want to modify `marks' some more in a moment.\n\nInstead, simply reset ntags to the length of marks, after we have\npossibly done any needed abbreviation.\n\nNo functional change.\n\nSigned-off-by: Ian Jackson \n---\n gitk | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/gitk b/gitk\nindex 42fa41a..31aecda 100755\n--- a/gitk\n+++ b/gitk\n@@ -6575,9 +6575,10 @@ proc drawtags {id x xt y1} {\n \t } else {\n \t\tset marks [list [format \"%d tags...\" $ntags]]\n \t }\n-\t set ntags 1\n \t}\n }\n+ set ntags [llength $marks]\n+\n if {[info exists idheads($id)]} {\n \tset marks [concat $marks $idheads($id)]\n \tset nheads [llength $idheads($id)]\n-- \n2.10.1\n\n"},{"id":"305526","messageId":"20161108005241.19888-2-ijackson@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH GITK 1/6] gitk: Internal: drawtags: Abolish \"singletag\" variable","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:52:37Z","receivedAt":"2016-11-08T00:53:19Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"We are going to want to make the contents of `marks' somewhat more\ncomplicated in a moment, so it won't be possible to use what is\neffectively a single variable to represent the status of the whole of\nthe non-heads part of the marks list.\n\nLuckily the strings that replace actual tag names, in the `singletag'\ncase, are not themselves valid tag names. So they can be detected\ndirectly.\n\n(Also, `singletag' was not quite right anyway: really it meant that\nthe tag name(s) had been abbreviated.)\n\nNo functional change.\n\nSigned-off-by: Ian Jackson \n---\n gitk | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/gitk b/gitk\nindex 805a1c7..42fa41a 100755\n--- a/gitk\n+++ b/gitk\n@@ -6570,7 +6570,6 @@ proc drawtags {id x xt y1} {\n \tif {$ntags > $maxtags ||\n \t [totalwidth $marks mainfont $extra] > $maxwidth} {\n \t # show just a single \"n tags...\" tag\n-\t set singletag 1\n \t if {$ntags == 1} {\n \t\tset marks [list \"tag...\"]\n \t } else {\n@@ -6620,7 +6619,7 @@ proc drawtags {id x xt y1} {\n \t\t $xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \\\n \t\t -width 1 -outline $tagoutlinecolor -fill $tagbgcolor \\\n \t\t -tags tag.$id]\n-\t if {$singletag} {\n+\t if {[regexp {^tag\\.\\.\\.|^\\d+ } $tag]} {\n \t\tset tagclick [list showtags $id 1]\n \t } else {\n \t\tset tagclick [list showtag $tag_quoted 1]\n-- \n2.10.1\n\n"},{"id":"305527","messageId":"20161108005241.19888-5-ijackson@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH GITK 4/6] gitk: Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:52:40Z","receivedAt":"2016-11-08T00:53:22Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Tags matching a new multi-valued config option log.noAbbrevTags\nare not abbreviated.\n\nThe config setting is in git config logs.* rather than gitk's\nown configuration, because:\n\n - Tools which manage git trees may want to set this, depending\n on their knowledge of the nature of the tags likely to be\n present;\n\n - Whether this property ought to be set is mostly a property of the\n contents of the tag namespaces in the tree, not a user preference.\n (Although of course user preferences are supported.)\n\n - Other git utilities (or out of tree utilities) may want to\n reference this setting for their own display purposes.\n\nThere will be another, separate, patch to the `git' tree to document\nthis config option.\n\nBackground motivation:\n\nDebian's dgit archive gateway tool generates and uses tags called\narchive/debian/VERSION. If such a tag refers to a Debian source tree,\nit is probably very interesting because it refers to a version\nactually uploaded to Debian by the Debian package maintainer.\n\nWe would therefore like a way to specify that such tags should be\ndisplayed in full. dgit will be able to set an appropriate config\nsetting in the trees it deals with.\n\nSigned-off-by: Ian Jackson \n---\n gitk | 13 +++++++++++++\n 1 file changed, 13 insertions(+)\n\ndiff --git a/gitk b/gitk\nindex d76f1e3..515d7b0 100755\n--- a/gitk\n+++ b/gitk\n@@ -6547,6 +6547,14 @@ proc totalwidth {l font extra} {\n }\n \n proc tag_want_unabbrev {tag} {\n+ global noabbrevtags\n+ # noabbrevtags was reversed when we read config, so take first match\n+ foreach pat $noabbrevtags {\n+\tset inverted [regsub {^\\^} $pat {} pat]\n+\tif {[string match $pat $tag]} {\n+\t return [expr {!$inverted}]\n+\t}\n+ }\n return 0\n }\n \n@@ -12138,6 +12146,11 @@ set tclencoding [tcl_encoding $gitencoding]\n if {$tclencoding == {}} {\n puts stderr \"Warning: encoding $gitencoding is not supported by Tcl/Tk\"\n }\n+set noabbrevtags {}\n+catch {\n+ set noabbrevtags [exec git config --get-all log.noAbbrevTags]\n+}\n+set noabbrevtags [lreverse [split $noabbrevtags \"\\n\"]]\n \n set gui_encoding [encoding system]\n catch {\n-- \n2.10.1\n\n"},{"id":"305528","messageId":"20161108005241.19888-6-ijackson@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:52:41Z","receivedAt":"2016-11-08T00:53:25Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Tags matching a new multi-valued config option log.noAbbrevTags\nshould not be abbreviated. Currently this config option is\nused only by gitk (and the patch to gitk will come via the\ngitk maintainer tree).\n\nThe config setting is in git config logs.* rather than gitk's\nown configuration, because:\n\n - Tools which manage git trees may want to set this, depending\n on their knowledge of the nature of the tags likely to be\n present;\n\n - Whether this property ought to be set is mostly a property of the\n contents of the tag namespaces in the tree, not a user preference.\n (Although of course user preferences are supported.)\n\n - Other git utilities (or out of tree utilities) may want to\n reference this setting for their own display purposes.\n\nBackground motivation:\n\nDebian's dgit archive gateway tool generates and uses tags called\narchive/debian/VERSION. If such a tag refers to a Debian source tree,\nit is probably very interesting because it refers to a version\nactually uploaded to Debian by the Debian package maintainer.\n\nWe would therefore like a way to specify that such tags should be\ndisplayed in full. dgit will be able to set an appropriate config\nsetting in the trees it deals with.\n\nSigned-off-by: Ian Jackson \n---\n Documentation/config.txt | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a0ab66a..6aade4f 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -2002,6 +2002,14 @@ log.abbrevCommit::\n \tlinkgit:git-whatchanged[1] assume `--abbrev-commit`. You may\n \toverride this option with `--no-abbrev-commit`.\n \n+log.noAbbrevTags::\n+\tEach value is a glob pattern, specifying tag nammes which\n+\tshould always be displayed in full, even when other tags may\n+\tbe omitted or abbreviated (for example, by linkgit:gitk[1]).\n+\tValues starting with `^` specify tags which should be\n+\tabbreviated. The order is important: the last match, in the\n+\tmost-local configuration, wins.\n+\n log.date::\n \tSet the default date-time mode for the 'log' command.\n \tSetting a value for log.date is similar to using 'git log''s\n-- \n2.10.1\n\n"},{"id":"305529","messageId":"22561.8757.914542.10409@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108005241.19888-1-ijackson@chiark.greenend.org.uk","subject":"Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T00:54:13Z","receivedAt":"2016-11-08T00:54:19Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Ian Jackson writes (\"[PATCH 0/6] Provide for config to specify tags not to abbreviate\"):\n> Please find in the following mails patches which provide a way to make\n> gitk display certain tags in full, even if they would normally be\n> abbreviated.\n> \n> There are four patches to gitk, three to prepare the ground, and one\n> to introduce the new feature.\n>\n> There is one patch for git, to just document the new config variable.\n\nThe eagle-eyed reader will spot that that makes 5 patches, not 6.\nThere are indeed only 5. The subject mentioning 6 is a mistake -\nsorry.\n\nThanks,\nIan.\n\n-- \nIan Jackson These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"305532","messageId":"CA+P7+xoQFsN1tPvKCA6+aRMChFwpMs73D=2kwvVRcxALWK0mZQ@mail.gmail.com","threadId":"44439","inReplyTo":"20161108005241.19888-6-ijackson@chiark.greenend.org.uk","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-11-08T02:28:17Z","receivedAt":"2016-11-08T02:28:47Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson\n wrote:\n> +log.noAbbrevTags::\n> + Each value is a glob pattern, specifying tag nammes which\n> + should always be displayed in full, even when other tags may\n> + be omitted or abbreviated (for example, by linkgit:gitk[1]).\n> + Values starting with `^` specify tags which should be\n> + abbreviated. The order is important: the last match, in the\n> + most-local configuration, wins.\n> +\n\nIt seems weird that this description implies some sort of behavior\nchange in core git itself, but in fact is only used as a reference for\nother tools that may or may not honor it. I guess the reasoning here\nis to try to get other external tools that abbreviate tags to also\nhonor this? But it still seems pretty weird to have a documented\nconfig that has no code in core git to honor it...\n\nThanks,\nJake\n"},{"id":"305539","messageId":"0d7ff8e5-230a-c6e1-6663-eaecee5d5620@jump-ing.de","threadId":"44439","inReplyTo":"22561.8757.914542.10409@chiark.greenend.org.uk","subject":"Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate","fromName":"Markus Hitter","fromEmail":"mah@jump-ing.de","sentAt":"2016-11-08T09:19:12Z","receivedAt":"2016-11-08T09:19:26Z","isPatch":true,"sender":{"key":"mah@jump-ing.de","avatar":"https://avatars.githubusercontent.com/u/318581?v=4"},"body":"Am 08.11.2016 um 01:54 schrieb Ian Jackson:\n> Please find in the following mails patches which provide a way to make\n> gitk display certain tags in full, even if they would normally be\n> abbreviated.\n\nTBH, 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.\n\nYour use case looks like a nice opportunity for\n\n- 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\n\n- even better, abbreviate them depending on the size of the visible area, like a web browser would do, and/or\n\n- considering whether tags should be abbreviated on the left instead of on the right and/or\n\n- finding a mechanism to show them in full length even on small visible areas.\n\nThe 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.\n\nTrying to enforce long names just means they're not cut off by the abbreviation algorithm, but by the right boundary of the visible area.\n\n\nMy $0.02,\nMarkus\n\n-- \n- - - - - - - - - - - - - - - - - - -\nDipl. Ing. (FH) Markus Hitter\nhttp://www.jump-ing.de/\n"},{"id":"305540","messageId":"22561.44597.59852.574831@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"CA+P7+xoQFsN1tPvKCA6+aRMChFwpMs73D=2kwvVRcxALWK0mZQ@mail.gmail.com","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T10:51:33Z","receivedAt":"2016-11-08T10:52:09Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Jacob Keller writes (\"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate\"):\n> On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson\n> wrote:\n> > +log.noAbbrevTags::\n> > + Each value is a glob pattern, specifying tag nammes which\n> > + should always be displayed in full, even when other tags may\n> > + be omitted or abbreviated (for example, by linkgit:gitk[1]).\n> > + Values starting with `^` specify tags which should be\n> > + abbreviated. The order is important: the last match, in the\n> > + most-local configuration, wins.\n> > +\n> \n> It seems weird that this description implies some sort of behavior\n> change in core git itself, but in fact is only used as a reference for\n> other tools that may or may not honor it. I guess the reasoning here\n> is to try to get other external tools that abbreviate tags to also\n> honor this? But it still seems pretty weird to have a documented\n> config that has no code in core git to honor it...\n\nThanks for your attention.\n\nYes, I agree that it does seem weird. But the alternatives seem\nworse. I think it's probably best if options like this (currently\nonly honoured by out-of-core tools but of general usefulness) are\ncollected together here.\n\nThere is a precedent: `git config gui.encoding' is, according to the\ndocumentation, honoured only by git-gui and gitk.\n\nCalling the config option `gitk.noAbbrevTags' would be possible but\nthat would invite everyone else to invent their own, which would be\nquite annoying. (Also, gitk does not have any gitk-specific git\nconfig options right now, AIUI. It does honour `git config\ngui.encoding'.)\n\nWould it help to add a sentence to the documentation saying that this\nis currently only honoured by gitk ? (The paragraph for gui.encoding\nsays something similar.) Of course I don't know who else abbreviates\ntags, but as they gain support they could be added to the docs.\n\nThanks,\nIan.\n\n-- \nIan Jackson These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"305558","messageId":"22561.54876.646018.985175@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"0d7ff8e5-230a-c6e1-6663-eaecee5d5620@jump-ing.de","subject":"Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-08T13:42:52Z","receivedAt":"2016-11-08T13:44:14Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Markus Hitter writes (\"Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate\"):\n> TBH, I see a violation of tool independence with the choice of\n> preference storage. Abbreviation of tags isn't a property of the\n> repository, but a pure visual thing (screen real estate, whatever),\n> so it should be handled by the tool doing the visuals, only.\n\nAs I explained in my cover letter, the set of tags which are important\nenough not to abbreviate, even if they would normally be abbreviated,\nis indeed a property of the repository.\n\nThe alternative would be for a tool like gitk to grow an\never-increasing set of heuristics. Or, worse, for a tool like dgit\n(which knows that archive/* are special) to edit the user's personal\ngitk settings.\n\n> Your use case looks like a nice opportunity for\n> \n> - adding a Gitk user preference on how long displayed tags are\n> allowed to be (instead of distinguishing between abbreviated and\n> unabbreviated ones; set it to 999 for your use case) and/or\n\nThis would be wrong, because it's only certain tags that ought not to\nbe abbreviated. The right way to identify those tags is by 1. what\nrepo they are in 2. what their name is. (It might be possible to\nidentify them by content or something - for example, the interesting\narchive/* tags all refer to commits whose trees contain debian/ - but\nthat is getting quite out of hand.)\n\nWhat you propose are possible general improvements to the abbreviation\nsystem in gitk. But they do not address the fundamental point that\nsome tags are much more interesting than others. It is this latter\npoint that I am trying to deal with.\n\nIan.\n\n-- \nIan Jackson These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"305588","messageId":"20161108215709.rvmsnz4fvhizbocl@sigill.intra.peff.net","threadId":"44439","inReplyTo":"22561.44597.59852.574831@chiark.greenend.org.uk","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-11-08T21:57:09Z","receivedAt":"2016-11-08T21:57:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 08, 2016 at 10:51:33AM +0000, Ian Jackson wrote:\n\n> Yes, I agree that it does seem weird. But the alternatives seem\n> worse. I think it's probably best if options like this (currently\n> only honoured by out-of-core tools but of general usefulness) are\n> collected together here.\n> \n> There is a precedent: `git config gui.encoding' is, according to the\n> documentation, honoured only by git-gui and gitk.\n\nYeah, I think git's config system was always designed to carry options\nfor porcelains outside of git-core itself. So your new option fits into\nthat.\n\nI think the two things I found weird were:\n\n - it's in the \"log\" section, which makes me think it's an option for\n git-log. But it's not. I'm not sure what the _right_ section is, but\n hopefully it would make it clear that this is command-agnostic.\n\n Something like \"gui.abbrevTags\" might be OK (and as you note, has\n precedence). But of course it's possible that a command like \"tig\"\n could learn to support it. I'm not sure if that counts as a GUI or\n not. :)\n\n - The description talks about tag abbreviation, but doesn't really\n define it. Not being a gitk user, it was hard for me to figure out\n whether this was even relevant. Does it mean turning\n \"refs/tags/v1.0\" into \"1.0\"? From the rest of the series, it sounds\n like no. That should be more clear from the documentation.\n\n-Peff\n"},{"id":"305609","messageId":"22562.32428.287354.214659@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"20161108215709.rvmsnz4fvhizbocl@sigill.intra.peff.net","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-09T01:41:00Z","receivedAt":"2016-11-09T01:41:13Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Jeff King writes (\"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate\"):\n> Yeah, I think git's config system was always designed to carry options\n> for porcelains outside of git-core itself. So your new option fits into\n> that.\n\nGood, thanks.\n\n> I think the two things I found weird were:\n> \n> - it's in the \"log\" section, which makes me think it's an option for\n> git-log. But it's not. I'm not sure what the _right_ section is, but\n> hopefully it would make it clear that this is command-agnostic.\n> \n> Something like \"gui.abbrevTags\" might be OK (and as you note, has\n> precedence). But of course it's possible that a command like \"tig\"\n> could learn to support it. I'm not sure if that counts as a GUI or\n> not. :)\n\nI don't really have an opinion about the name. gui.abbrevTags would\nbe a possibility. (It's a bit odd that implicitly, the default would\nbe `*'.)\n\n> - The description talks about tag abbreviation, but doesn't really\n> define it. Not being a gitk user, it was hard for me to figure out\n> whether this was even relevant. Does it mean turning\n> \"refs/tags/v1.0\" into \"1.0\"? From the rest of the series, it sounds\n> like no. That should be more clear from the documentation.\n\nI can do that, sure.\n\nBy default, gitk doesn't like to use much screen real estate for tags.\nIf there are long tag names, or many tags, it shows them all as a\nsingle small indication saying just ` These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"305612","messageId":"xmqqa8d9b3jh.fsf@gitster.mtv.corp.google.com","threadId":"44439","inReplyTo":"22562.32428.287354.214659@chiark.greenend.org.uk","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-09T05:55:30Z","receivedAt":"2016-11-09T05:55:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ian Jackson writes:\n\n>> I think the two things I found weird were:\n>> \n>> - it's in the \"log\" section, which makes me think it's an option for\n>> git-log. But it's not. I'm not sure what the _right_ section is, but\n>> hopefully it would make it clear that this is command-agnostic.\n>> \n>> Something like \"gui.abbrevTags\" might be OK (and as you note, has\n>> precedence). But of course it's possible that a command like \"tig\"\n>> could learn to support it. I'm not sure if that counts as a GUI or\n>> not. :)\n>\n> I don't really have an opinion about the name. gui.abbrevTags would\n> be a possibility. (It's a bit odd that implicitly, the default would\n> be `*'.)\n\nI have trouble with both \"log\" and \"abbrev\" in the name. Perhaps I\nam biased by our recent discussion on a feature in the core that we\nuse the word \"abbrev\" to describe, but I fear that most Git users,\nwhen told the word, would imagine the act of shortening 40-hex full\nobject name down to shorter but still unique prefix, not the \"this\nrefname is too long, so let's show only the first few letters in GUI\nlabel\".\n\nAnd I do not think we would want \"log\" or any core side Porcelain\ncommand to have too many \"information losing\" options like this\n\"truncate refnames down to a point where it is no longer unique and\nmeaningful\". GUI tools can get away with doing sos because they can\narrange these truncated labels to react to end-user input (e.g. the\ntruncated Tag in the history display of gitk could be made to react\nto mouse-over and pop-up to show a full name, for example), but the\noutput from the core side is pretty much fixed once it is emitted.\n\nSo my first preference would be to teach gitk such a \"please\nclarify\" UI-reaction, if it does not know how to do so yet. There\nis no need for a configuration variable anywhere with this approach.\n\nIf you do want to add a configuration to show fuller name in the\ntag, which would make it unnecessary for the user to do \"please\nclarify, as I am hovering over what I want to get details of\"\naction, that may also be a good way to go. But I think the right\nplace to do so would be Edit -> Preferences menu in Gitk, and the\nsettings will be stored in ~/.gitk or ~/.config/git/gitk or whatever\ngitk-specific place.\n\n"},{"id":"305626","messageId":"22562.65461.845411.29907@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"xmqqa8d9b3jh.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-09T10:51:33Z","receivedAt":"2016-11-09T11:12:21Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Junio C Hamano writes (\"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate\"):\n> And I do not think we would want \"log\" or any core side Porcelain\n> command to have too many \"information losing\" options like this\n> \"truncate refnames down to a point where it is no longer unique and\n> meaningful\". GUI tools can get away with doing sos because they can\n> arrange these truncated labels to react to end-user input (e.g. the\n> truncated Tag in the history display of gitk could be made to react\n> to mouse-over and pop-up to show a full name, for example), but the\n> output from the core side is pretty much fixed once it is emitted.\n> \n> So my first preference would be to teach gitk such a \"please\n> clarify\" UI-reaction, if it does not know how to do so yet. There\n> is no need for a configuration variable anywhere with this approach.\n\ngitk already has a way for the user to find out what the elided tag\nnames are. The underlying difficulty is that the situation that the\ngitk behaviour is designed for (long tag names, perhaps several to a\ncommit, not particularly interesting), is not applicable to these\nparticular tags.\n\nWhether the tag is `particularly interesting' depends, as I say, on\nboth what tree it is in, and on its name. It might be appropriate for\nterminal-based tools to highlight these tags too, or show them when\ntags are not normally displayed.\n\n`core.interestingTags' ?\n\n> If you do want to add a configuration to show fuller name in the\n> tag, which would make it unnecessary for the user to do \"please\n> clarify, as I am hovering over what I want to get details of\"\n> action, that may also be a good way to go.\n\nI think in my use case, which I hope to become common within Debian,\nthis is going to be essential.\n\n> But I think the right\n> place to do so would be Edit -> Preferences menu in Gitk, and the\n> settings will be stored in ~/.gitk or ~/.config/git/gitk or whatever\n> gitk-specific place.\n\nThis is not correct, because as I have explained, this should be a\nper-tree configuration:\n\nIf it can't be a `git config' option, even `git config gui.something',\nthen I guess I will have to teach gitk to read a config file in\nGIT_DIR too. But I think that is silly given that git already has a\nconfig file reading system which handles per-tree configs.\n\nIf we can't get agreement from the git-core developers on a config to\nbe used, and documented, for any tool which has similar behaviour, I\nthink the right answer is `git config gitk.', which would\nbe documented in gitk.\n\nThanks,\nIan.\n\n-- \nIan Jackson These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"305655","messageId":"xmqqeg2k8cwz.fsf@gitster.mtv.corp.google.com","threadId":"44439","inReplyTo":"22562.65461.845411.29907@chiark.greenend.org.uk","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-11-09T23:13:32Z","receivedAt":"2016-11-09T23:13:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ian Jackson writes:\n\n>> But I think the right\n>> place to do so would be Edit -> Preferences menu in Gitk, and the\n>> settings will be stored in ~/.gitk or ~/.config/git/gitk or whatever\n>> gitk-specific place.\n>\n> This is not correct, because as I have explained, this should be a\n> per-tree configuration:\n\nI do not have fundamental opposition to make it part of .git/config,\nbut the name \"gitk.something\" or if you are enhancing git-gui at the\ntime perhaps \"gui.something\" would be appropriate. \n\nBut it is still silly to have this kind of information that is very\nspecific to Gitk in two places, one that is pretty Gitk specific\nthat core-git does not know anything about, the other that are part\nof the configuration storage of the core-git. In the longer term,\nit is necessary for them to be accessible from gitk's \"Edit ->\nPreferences\" mechanism somehow, I would think, rather than forcing\nusers to sometimes go to GUI to tweak and sometimes run \"git config\".\n"},{"id":"305659","messageId":"22563.45501.383303.374430@chiark.greenend.org.uk","threadId":"44439","inReplyTo":"xmqqeg2k8cwz.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2016-11-09T23:31:09Z","receivedAt":"2016-11-09T23:31:18Z","isPatch":true,"sender":{"key":"ijackson@chiark.greenend.org.uk","avatar":null},"body":"Junio C Hamano writes (\"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate\"):\n> Ian Jackson writes:\n> > This is not correct, because as I have explained, this should be a\n> > per-tree configuration:\n> \n> I do not have fundamental opposition to make it part of .git/config,\n> but the name \"gitk.something\" or if you are enhancing git-gui at the\n> time perhaps \"gui.something\" would be appropriate. \n> \n> But it is still silly to have this kind of information that is very\n> specific to Gitk in two places, one that is pretty Gitk specific\n> that core-git does not know anything about, the other that are part\n> of the configuration storage of the core-git. In the longer term,\n> it is necessary for them to be accessible from gitk's \"Edit ->\n> Preferences\" mechanism somehow, I would think, rather than forcing\n> users to sometimes go to GUI to tweak and sometimes run \"git config\".\n\nI am proposing to set this configuration setting automatically in\ndgit. Other tools that work with particular git tags would do the\nsame. There would be no need for users to do anything.\n\nHaving this as an option in a menu would be quite wrong, because it\nwould end up with the user and the tooling fighting. This is why I\ndon't want to put this in gitk's existing config file mechanism.\n\nIt would be wrong for dgit to edit the user's gitk config file, for\nmany reasons.\n\nTo put it another way, this setting is a way for a tool like dgit to\ncommunicate with gitk (or other programs which have to make guesses\nabout how prominently to present certain information to the user).\nIt's not intended to be a way for users, certainly not non-expert\nusers, to communicate with gitk.\n\nThe way I have structured my proposed patches in gitk would make it\neasy to provide a gui option to adjust these settings. Such a gui\noption ought to save its value in the gitk config file, and those\nvalues ought to override what comes from `git config'.\n\nBut such a system would not obviate the need for a legitimate way for\nprograms like dgit to communicate with gitk.\n\nThanks,\nIan.\n\n-- \nIan Jackson These opinions are my own.\n\nIf I emailed you from an address @fyvzl.net or @evade.org.uk, that is\na private address which bypasses my fierce spamfilter.\n"},{"id":"305665","messageId":"ac17a9a7-d951-67f6-8428-d2e142a1f648@jump-ing.de","threadId":"44439","inReplyTo":"22563.45501.383303.374430@chiark.greenend.org.uk","subject":"Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate","fromName":"Markus Hitter","fromEmail":"mah@jump-ing.de","sentAt":"2016-11-10T00:36:19Z","receivedAt":"2016-11-10T00:36:29Z","isPatch":true,"sender":{"key":"mah@jump-ing.de","avatar":"https://avatars.githubusercontent.com/u/318581?v=4"},"body":"Am 10.11.2016 um 00:31 schrieb Ian Jackson:\n> I am proposing to set this configuration setting automatically in\n> dgit. Other tools that work with particular git tags would do the\n> same. There would be no need for users to do anything.\n> \n> Having this as an option in a menu would be quite wrong, because it\n> would end up with the user and the tooling fighting. This is why I\n> don't want to put this in gitk's existing config file mechanism.\n\nHaving this conversation watched for a while I get the impression that your point is essentially about introducing another type of references, next to branches and (ordinary) tags. Let's call them \"interesting tags\", \"itags\".\n\nThe logical path to get this, IMHO, isn't to add some configuration variable, but to store such interesting tags in .git/refs/itags/, just like the other reference types. Then one would create such interesting tags with\n\n git tag -i \nor\n git tag --interesting \n\nTo reduce the backwards compatibility problem these itags could be stored in .git/refs/tags as well, itag-aware tools would sort the duplicates out.\n\n\nMarkus\n\n-- \n- - - - - - - - - - - - - - - - - - -\nDipl. Ing. (FH) Markus Hitter\nhttp://www.jump-ing.de/\n"}]}