GNOME Bugzilla – Bug 648228
preserve All Branches view across gitg invocations
Last modified: 2018-05-22 13:05:39 UTC
For certain repositories I like to stay in the All Branches view all the time. Unfortunately, each time I start gitg it shows a single branch view once again and I have to switch to All Branches manually. It would be great if gitg could remember when I'm in All Branches (or Local Branches) view for a repository and switch to that view automatically the next time it runs.
This is a pretty big annoyance for me. I pretty much *always* want to see all branches (I'm a branch manager), so this is the second thing I do when I open gitg. The first thing is loading a repo (would be nice to auto-reload the last one).
As bug was filed against an older version of gitg, moving bug to gitg-0.x. Keeping bug open as current gitg too, does not remember last viewed branch.
In my opinion we shouldn't move this bug to gitg-0.x since it is relevant to the current version in git master. I don't think it really matters where it was originally filed. The important question is this: is it something that should be fixed in git master, given the current feature set? In this case I think the answer is yes.
"However, if they relate to things like not-yet-implemented features, then we should keep them and close them whenever it's implemented in the new gitg." https://mail.gnome.org/archives/gitg-list/2013-June/msg00000.html Am just doing what seems most appropriate when triaging bugs. I have kept the bug open because: > it something that > should be fixed in git master, given the current feature set? In this case I > think the answer is yes. I am categorizing it to gitg-0.x for sake of correctness. Please feel free to move it to component 'git head', if you feel that is more apt. The idea is to mark all open issues as RESOLVED and fixed once the feature has been implmented. The idea of component categorization (as an aid to the open status) in addition to the correctness, is to identify how long this feature request was waiting.
(In reply to comment #4) > The idea of component categorization (as an aid to the open > status) in addition to the correctness, is to identify how long this feature > request was waiting. I think that's the intent of the Version field in Bugzilla, actually. Perhaps the right thing to do here is to invent a new version number (0.3.x) for the new gitg. In any case, I think it's up to the gitg developers (I am not one!) to decide how they'd like these bugs to be organized.
There are two recent developments that improve this situation: 1. You can now specify --branches on the command line which select "All branches" by default 2. There is now a global setting (prefernce) which determines the default selection in the history activity, and you can set this to "All branches" This isn't exactly what you were asking for, but it might help with some of your annoyances. I think storing some of gitg state per repository could be interesting, we already do this for one other thing, namely the "main line" settings.
After some more thought, I'm not sure preserving the branch selection per repository is really the right thing to do. In particular, in the default case of selecting the current branch, this strategy wouldn't really work. The other options is to allow configuring the default selection per repository, in a sort of per-repository preferences dialog.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gitg/issues/14.