Add graph navigation buttons

[itaibh]

Add navigation buttons: Back / Current / Forward
I think it would be useful to have navigation buttons on the header (which should stay visible) that will scroll to the current checked-out commit (Current) (the commit currently marked with a blue circle), to the commit I interacted before (Back), and back to the commit I was handling (Forward).

While usually the current commit is found in one of the first lines, there are cases where it's far below (when searching for a commit that broke something, for example), and the ability to quickly get there and see what's around, and back to a new branch you are committing fixes to is helpful.

[mhutchie]

Thanks for raising this feature request!

As you’ve mentioned, this functionality is primarily used in some specific cases, so I don’t think it warrants adding 3 new buttons to the top control bar (when most of the time they won’t be used). The top control bar is already getting pretty full in multi-root workspaces on smaller screen devices, and I’ve reserved the little space that is left for upcoming commit filtering (by author, file, etc. as raised in other feature requests), which will be far more generally useful in many use cases. Having the buttons in the top control bar would also require it to stay visible when the view is scrolled as you mentioned (this has already been requested in #132). This adds a dependency on the other feature request, that will prevent this request from becoming available for a while (as #132 is actually very complex and hard to implement).

An alternative solution to this use case would be to add some new keyboard shortcuts instead of buttons on the top control bar (e.g. left arrow = back, h = go to head, right arrow = forward). This is consistent with the existing up and down arrow keyboard shortcuts that navigate the Commit Details View to the previous and next commits. Do you think this solution would work for you?

Just to clarify, I’d expect “interacted with” to mean a commit should be added to the history when it is right clicked on, or the Commit Details View is opened on it. Is this what you were thinking?

[itaibh]

Arrow navigation will work for me. Yet perhaps there should be a way to add a navigation bar that can be hidden by configuration. Regarding what I meant with "interacted with" - I thought of it as in opening the commit... it's kind of hard for me to explain. I originally only wanted to have a button to quickly scroll to HEAD, but then I thought of what it'll mean and I realized I'm consistently jumping between two HEADs (so to speak) and haven't figured our exactly how to define it. One HEAD was the actual commit checked out (the real HEAD) and the other "HEAD" was the last commit of the branch I was committing to, kinda like what happens right after you make a commit - it jumps to that commit.

…

On Sat, Sep 28, 2019 at 5:05 AM Michael Hutchison ***@***.***> wrote: Thanks for raising this feature request! As you’ve mentioned, this functionality is primarily used in some specific cases, so I don’t think it warrants adding 3 new buttons to the top control bar (when most of the time they won’t be used). The top control bar is already getting pretty full in multi-root workspaces on smaller screen devices, and I’ve reserved the little space that is left for upcoming commit filtering (by author, file, etc. as raised in other feature requests), which will be far more generally useful in many use cases. Having the buttons in the top control bar would also require it to stay visible when the view is scrolled as you mentioned (this has already been requested in #132 <#132>). This adds a dependency on the other feature request, that will prevent this request from becoming available for a while (as #132 <#132> is actually very complex and hard to implement). An alternative solution to this use case would be to add some new keyboard shortcuts instead of buttons on the top control bar (e.g. left arrow = back, h = go to head, right arrow = forward). This is consistent with the existing up and down arrow keyboard shortcuts that navigate the Commit Details View to the previous and next commits. Do you think this solution would work for you? Just to clarify, I’d expect “interacted with” to mean a commit should be added to the history when it is right clicked on, or the Commit Details View is opened on it. Is this what you were thinking? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#187?email_source=notifications&email_token=AABCNN2IS2ZCPYXRX3PP22TQL23VFA5CNFSM4I3JYBG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD72OJ2A#issuecomment-536143080>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCNN52MK5KWS44IJ75H7TQL23VFANCNFSM4I3JYBGQ> .

-- Itai Bar-Haim https://itaibarhaim.me/

[mhutchie]

Thanks for confirming that the arrow navigation will work for you (at least for now, it can always be complimented by buttons later).

In order to develop this feature, I will need to add commit hashes to a stack that can then be navigated with arrow keys (or buttons). The front end of the extension must trigger these events, so please define "interacted with" with respect to events that occur in the front end (e.g. right click on a commit / branch / tag, open the commit details, checkout a commit / branch, i.e. any user interaction with the front end). Also remember to keep your definition broad enough so that it is as broadly useful as possible (so that it can be used by others, and not just your specific use case).

[mhutchie]

As I can't think of a feasible history triggering solution that meets your needs (and is generally applicable / useful to other users), you haven't responded to my previous request for a definition of "interacted with" with respect to events that occur in the front end, and this would only be used in infrequent circumstances by some users, I'm closing this feature request for now and adding it to the backlog.

If you, myself, or other users reading this in the future can reply with a feasible, broadly useful, and consistent way to trigger commit hashes to be added to the history, I'd be more than happy to re-open and implement this.