Re: gitk does not reload tag messages

2012-09-06 Thread Junio C Hamano
David Aguilar  writes:

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

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

diff --git i/gitk w/gitk
index 22270ce..6abe240 100755
--- i/gitk
+++ w/gitk
@@ -10599,7 +10599,7 @@ proc movedhead {hid head} {
 }
 
 proc changedrefs {} {
-global cached_dheads cached_dtags cached_atags
+global cached_dheads cached_dtags cached_atags tagcontents
 global arctags archeads arcnos arcout idheads idtags
 
 foreach id [concat [array names idheads] [array names idtags]] {
@@ -10611,6 +10611,7 @@ proc changedrefs {} {
}
}
 }
+catch {unset tagcontents}
 catch {unset cached_dtags}
 catch {unset cached_atags}
 catch {unset cached_dheads}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: gitk does not reload tag messages

2012-09-06 Thread David Aguilar
On Thu, Sep 6, 2012 at 11:17 AM, Tim McCormack  wrote:
> 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.

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


gitk does not reload tag messages

2012-09-06 Thread Tim McCormack
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html