Bug#876237: Doesn't display all commits
On Sun, 4 Feb 2018 07:57:47 +1100
Carlos Maddela wrote:
> I'm not sure if this bug can be safely closed now, since I don't know if the
> behaviour I described previously was intended.
>
> What has been resolved with the release of libgit2-glib/0.26.2-1 is that the
> 'Preferences' menu becomes available again in gitg, and you can choose
> the 'Show history in topological order' to restore the original behaviour in
> version 0.24.
>
Sorry but I still see the issue with gitg, it can be replicated cloning
the repository mentioned in the upstream report:
https://bugzilla.gnome.org/show_bug.cgi?id=788090
Enabling topological order to fix the gitg issue is just a workaround.
My test case is a simple repository with only one branch, and gitg fails
to show all the commits, while the git command line tools work fine.
I am not sure if this is a libgit2 issue TBH, this simple pygit2 example
shows all the commits:
#!/usr/bin/env python3
import pygit2
#mode = pygit2.GIT_SORT_NONE
#mode = pygit2.GIT_SORT_TOPOLOGICAL
mode = pygit2.GIT_SORT_TIME
#mode |= pygit2.GIT_SORT_REVERSE
repo = pygit2.Repository('.git')
for commit in repo.walk(repo.head.target, mode):
print(commit.id, commit.message.split('\n')[0])
Ciao,
Antonio
--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Bug#876237: Doesn't display all commits
I'm not sure if this bug can be safely closed now, since I don't know if the behaviour I described previously was intended. What has been resolved with the release of libgit2-glib/0.26.2-1 is that the 'Preferences' menu becomes available again in gitg, and you can choose the 'Show history in topological order' to restore the original behaviour in version 0.24. Best regards, Carlos
Bug#876237: Doesn't display all commits
On 24/09/17 21:13, Laurent Bigonville wrote: > On Wed, 20 Sep 2017 10:24:26 +1000 Carlos Maddela > wrote: > > Hi, > > Hi, > > > Something seems to have broken recently. I now don't always get the > > complete commit history when I select a specific branch. > > > > I have attached a screenshot and output log for comparison. Selecting > > the patch-queue/debian branch displays only 3 commits, suggesting that > > it may be an orphaned branch, whereas the output of > > 'git log patch-queue/debian' shows that it is in fact not orphaned. > > > > The funny thing is rolling back to version 3.23.0-1 produces the same > > result, however I don't remember having this problem previously. > > Could you also try to rollback libgit2-glib-1.0-0 to the 0.24 version? You're right. Rolling this back too restores the original behaviour. However, prior to doing this rollback, I thought I may have detected another related bug. I noticed that for repos that didn't display the complete history for some branch, displaying the 'General settings and options' menu would give you only the 'Reload' and 'Author Details' options, whereas for repos that didn't exhibit this problem, you would also get 'Preferences', 'Keyboard Shortcuts', 'About' and 'Quit'. Anyway, after doing the rollback, I only ever got 'Reload' and 'Author Details', but I have hardly ever used this feature, so I don't remember what the original behaviour was. After upgrading to the latest versions again, I can't get any other options from the 'General settings and options' menu to appear, except for 'Reload' and 'Author Details'. I have no idea if I have some other setting that's causing the other options not to appear. Thanks, Carlos > > Regards, > > Laurent Bigonville
Bug#876237: Doesn't display all commits
On Wed, 20 Sep 2017 10:24:26 +1000 Carlos Maddela wrote: > Hi, Hi, > Something seems to have broken recently. I now don't always get the > complete commit history when I select a specific branch. > > I have attached a screenshot and output log for comparison. Selecting > the patch-queue/debian branch displays only 3 commits, suggesting that > it may be an orphaned branch, whereas the output of > 'git log patch-queue/debian' shows that it is in fact not orphaned. > > The funny thing is rolling back to version 3.23.0-1 produces the same > result, however I don't remember having this problem previously. Could you also try to rollback libgit2-glib-1.0-0 to the 0.24 version? Regards, Laurent Bigonville
