gitk does not reload tag messages

If a tag that gitk knows about is deleted and recreated with a different message, gitk still shows the old message after any combination of refresh, reload, and reread refs.

git-gui version 0.13.0.8.g8f85

Reproduce:
1. git tag -a test -m "foo" HEAD
2. Open gitk, see that correct message ("foo") is present for tag "test"
3. git tag -d test
4. Reload/refresh gitk [optional, it won't make a difference]
5. git tag -a test -m "bar" HEAD
6. Reload/refresh gitk
7. See that the message on tag "test" is still "foo"
8. $ git show test # shows correct message "bar"

Apologies if this is an old version or a known bug; I could not find an issue tracker to search, although I did check the gmane archives.

 - Tim McCormack

On Thu, Sep 6, 2012 at 11:17 AM, Tim McCormack <cortex@brainonfire.net> wrote:

Tags in git are meant to be immutable. You can delete them, but you shouldn't. That's not really how they are intended to be used.

gitk avoids re-reading that information because the normal, typical use case is that the tag messages do not change.

It would probably be a performance regression to "fix" this. In which case, IMO it's not a bug.

David Aguilar <davvid@gmail.com> writes:

The reasoning behind your argument, i.e. the first paragraph, is correct, and I agree that it certainly easier to implement a "read once and assume it won't change."

But wouldn't it be OK for an explicit user action to cause reload of the contents?

I just did this in my git.git tree:

    1. Start "gitk". The branch checked out is 'master', and it
       shows the v1.7.12 tag somewhere in the recent past.

    2. Click on v1.7.12; its contents and my signature is visible.

    3. "git tag -f -m 'Fake v1.7.12' v1.7.12 master". Don't worry, I
       have backups everywhere ;-)

    4. Of course, nothing changes in "gitk".  I wouldn't expect a
       magic.

    5. File -> Reread references.  This correctly moves the flag
       labelled as v1.7.12 in the history graph.

    6. After clicking on some random commit (to view its message)
       click v1.7.12 tag.  The original contents, not the "Fake" one
       is shown.

       Would it really be too much work to run "cat-file" at this
       point?  I think the earlier "File -> Reread references" is a
       strong enough clue the user gave "gitk" that something have
       changed, and I think it currently uses this clue to purge the
       cached mapping between refname and commit.

       Perhaps it can and should purge the cached tag object
       contents as well? The worst that can happen is when the user
       clicks a tag, we would need to read the tag object.

    7. File -> Reload.  Even this does not seem to purge the cached
       tag contents, even though it seems to redraw the whole
       history.

Note that if I swap the order of step #2 and step #3, I see the "Fake" message; I think we are reading the contents of the tag on demand. I think the problem is just the contents, once read, seem to be forever cached.

It may just be the matter of something like this.

 gitk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Tag contents, once read, are forever cached in memory. This makes gitk unable to notice when tag contents change.

Allow users to cause a reload of the tag contents by using the "File->Reread references" action.

Reported-by: Tim McCormack <cortex@brainonfire.net>
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
 gitk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Name the 'tagcontents' variable similarly to the rest of the variables cleared in the changedrefs() function.

This makes the naming consistent and provides a hint that it should be cleared when reloading gitk's cache.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---

Follow-up to 'gitk: Teach "Reread references" to reload tags'

 gitk |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

I've applied these two, on top of Paul's master branch at

    git://ozlabs.org/~paulus/gitk.git

and tentatively queued in 'pu', but I would prefer to see it eyeballed by and queued in his tree first.

Thanks.

Junio C Hamano <gitster@pobox.com> writes:

Pinging Paul...

The following changes since commit a135f214e371311f13807da637d492fd9642a2e3:

  gitk: Avoid Meta1-F5 (2012-04-25 13:44:31 +1000)

are available in the git repository at:

  git://github.com/gitster/git da/gitk-reload-tag-contents

for you to fetch changes up to 587277fea3bf3bfc4302480178bd88a277a69f05:

  gitk: Rename 'tagcontents' to 'cached_tagcontent' (2012-09-08 20:25:09 -0700)

----------------------------------------------------------------
David Aguilar (2):
      gitk: Teach "Reread references" to reload tags
      gitk: Rename 'tagcontents' to 'cached_tagcontent'

 gitk | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

Thanks.

On Wed, Sep 12, 2012 at 02:25:28AM -0700, Junio C Hamano wrote:

Thanks, pulled and pushed out. I had one other commit queued up, so if you pull from git://ozlabs.org/~paulus/gitk.git you will get that plus a merge.

Paul.