You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure how to provide relevant information for this issue, but if there's anything I can do to help debug let me know. The problem is that I have closed a few bugs from the command line using git bug status close <id>. After that, I started the termui, but it is displaying those bugs as "open". I'm using a filter status:open label:json. However, when I press enter to show details of that bug, it says "closed". Furthermore, when I go back to the list (press "q") that bug is no longer in the open list. I took a screencast:
In the screencast note bugs 12fc493 and 71ac52e at the bottom of the list. They are both listed as "open". Then I press "enter" to view the status. Note it says "closed". Then I press "q" and go back to the list. Note that the bug has disappeared from the list.
This is observed on master from today. I deleted that and went back to the prebuilt binary from v0.5.0 so I will update if the problem seems to go away or persists.
I will note that these labels were possibly assigned "near" a termui crash (#233) so that might be related.
Yup, issue persists with v0.5.0 (though maybe crossing the version boundary is the problem? I'm not sure how far master is from 0.5.0). In the screencast above note bug 92c0d09 (also near the bottom). This bug is closed and when I open termui with v0.5.0 it appears open, as it did with master (in the video above).
The termui list is only using the cache as a source of data. When you open a bug, the whole series of commit is loaded from git and the cache is updated (I think ... not sure if it's actually updated if you don't make any change to the bug). This suggest that your cache is somehow not reflecting the actual state of those bugs. A crash can very much do that.
To check that, you can either simply delete your cache (.git/git-bug/bug-cache), or make a change to those bugs to force the update of the cache.
Ok great! I'll hold off on deleting the cache and try to spot any more bugs that incorrectly show up as open. Then I'll delete the cache and see if they show up as closed. I will report back.
Ok I got a situation where this happened again. Indeed deleting the cache seems to have fixed the stale status. However, I don't think the stale status was due to crash this time. I'm pretty sure that this happened after two pulls, with no local edits to the bug. Here is what I think the situation was:
Machine A:
Create bug d3c0372
git bug push
Machine B:
git bug pull -> new bug d3c0372
git bug termui -> verify I can see new bug, "enter" to see the detail page
Machine A:
Close bug d3c0372
git bug push
Machine B:
git bug pull
git bug termui -> d3c0372 shows "open"
"enter" on d3c0372 -> details page shows "closed"
q back to the main page -> d3c0372 is not longer listed with "open" bugs
When I get a chance I will try to replicate this in a controlled setting and report back.
I think I've found the problem: in https://github.com/MichaelMure/git-bug/blob/master/bug/bug.go#L516-L602, a new slice of OperationPack is computed, but never assigned to the Bug. The correct data is written in git, but the in-memory state is incorrect. This state is used later to generate the Excerpt for the cache.
Activity
cheshirekow commentedon Oct 24, 2019
Yup, issue persists with
v0.5.0(though maybe crossing the version boundary is the problem? I'm not sure how far master is from0.5.0). In the screencast above note bug92c0d09(also near the bottom). This bug is closed and when I open termui withv0.5.0it appears open, as it did withmaster(in the video above).MichaelMure commentedon Oct 28, 2019
The termui list is only using the cache as a source of data. When you open a bug, the whole series of commit is loaded from git and the cache is updated (I think ... not sure if it's actually updated if you don't make any change to the bug). This suggest that your cache is somehow not reflecting the actual state of those bugs. A crash can very much do that.
To check that, you can either simply delete your cache (
.git/git-bug/bug-cache), or make a change to those bugs to force the update of the cache.cheshirekow commentedon Oct 28, 2019
Ok great! I'll hold off on deleting the cache and try to spot any more bugs that incorrectly show up as open. Then I'll delete the cache and see if they show up as closed. I will report back.
cheshirekow commentedon Nov 13, 2019
Ok I got a situation where this happened again. Indeed deleting the cache seems to have fixed the stale status. However, I don't think the stale status was due to crash this time. I'm pretty sure that this happened after two pulls, with no local edits to the bug. Here is what I think the situation was:
Machine A:
d3c0372git bug pushMachine B:
git bug pull-> new bugd3c0372git bug termui-> verify I can see new bug, "enter" to see the detail pageMachine A:
d3c0372git bug pushMachine B:
git bug pullgit bug termui->d3c0372shows "open"d3c0372-> details page shows "closed"qback to the main page ->d3c0372is not longer listed with "open" bugsWhen I get a chance I will try to replicate this in a controlled setting and report back.
MichaelMure commentedon Nov 13, 2019
When you do the second
git bug pulldo you see the bug marked as updated ? The cache is only updated for new or updated bugs.Is this something that you can replicate ?
cheshirekow commentedon Nov 14, 2019
Yes!
This was not a controlled experiment, but I just pulled from one machine to another and paid attention to output of the
pull:Note that
c2c6767says "updated" when I did a pull. Then I rungit bug termuiand I see:Note that it is listed as "open". I highlight and press "enter" on this bug and:
Note that it is shown as "closed". (I did close this bug on the remote machine). Press
qandc2c6767is no longer in the list.MichaelMure commentedon Nov 14, 2019
I think I've found the problem: in https://github.com/MichaelMure/git-bug/blob/master/bug/bug.go#L516-L602, a new slice of OperationPack is computed, but never assigned to the Bug. The correct data is written in git, but the in-memory state is incorrect. This state is used later to generate the Excerpt for the cache.
bug: don't forget to assign the new packs after a merge