A feature of jumping to a specific commit

[cateyes99]

Describe the feature that you'd like
With Git Graph showing all those history lines, if there is a feature of jumping to the commit in the history giving a commit id, i.e., the section containing the commit with the given id will be brought into the view. After that i can also scroll up and down as usual to view the history. Just like what the Jump to commit feature in SourceTree does. Well SourceTree is heavyweight, slow and a bit unstable, i don't really use it much now. But I still need SourceTree to just do this for me in this case. If Git Graph has this feature, it'll make Git Graph so powerful, Don't need SourceTree at all. Well not sure how much performance impact on Git Graph this feature will have though.

Currently Git Graph has a search feature which can search any string not just commit id but just works with the content has been already viewed by the user (It looks like that this search feature is just based on VSCode's Search Ctrl+F). For the content hasn't been viewed, for example far down in the history, the search functionality is unable to search. So cannot use this feature to do what i said above

[mhutchie]

The Find Widget is custom made (although styled to be consistent with the Visual Studio Code Find Widget). As you mentioned it will only find (and go to) the commit if it is one of the loaded commits in the Git Graph View.

Unfortunately it’s not possible to know if an entered commit id is either:

• An ancestor of the currently loaded commits (and would eventually be shown if Load More Commits was pressed enough times to load enough commits to see it)
• On an arbitrary branch (or maybe not an a branch at all) that is filtered out using the Branches Dropdown.

The only way to distinguish between these two cases would be to load all of the repositories commits into memory (which I assume is what SourceTree must do), which is definitely to expensive / costly (with respect to performance and memory) to be feasible for all repositories for all users.

An easy option for you would be to increase the value of Initial Load Commits to accomodate the number of commits you’d be searching within. This way the existing Find Widget would work as you’re wanting, without having to affect everyone with loading all commits into memory.

FYI: An alternative feature would be to allow the user to specify a commit id instead of a branch in the Branches dropdown. The existing view would just load all parent ancestors of the given commit id (just like how it already displays the parent ancestors from a branch ref). The issue with this approach is that it only shows the parent ancestors of the commit, not any of the children commits (like you would get if the view loaded all commits, and just jumped to the specified commit).

Please close this feature request if your fine with the first (easy) option I suggested (due to the implementation reasons I provided). If you’d value the alternative feature I suggested, let me know so I can work out how it could be accommodated in the UI.

[cateyes99]

I don't think both serve well the purpose though. What about just park the idea now rather than to close it, as no good clues to implement it in an efficient way right now? You might mark it with some tags?

[mhutchie]

I'll close this issue for now, but tag it as a backlog item (which are "Requests that are closed for now, but may be re-opened in the future if more interest is expressed").

Note to users reading this in the future:

• If you'd like this functionality, please reply to this thread to express your interest.
• If you have a feasible (reasonably efficient) solution to this feature, please reply with your suggestions.

I'll happily re-open and implement this feature if there is any indication it would be used by a decent number of users, and a feasible solution is found.

[PathogenDavid]

I'm interested in this feature.

On an arbitrary branch (or maybe not an a branch at all) that is filtered out using the Branches Dropdown.

I think this would generally be a workable solution for me.

An ancestor of the currently loaded commits (and would eventually be shown if Load More Commits was pressed enough times to load enough commits to see it)

I believe git merge-base --is-ancestor <revision> HEAD could be used for this purpose. Although I suppose you'd have to run it for each head.

However I'm not sure if the "Load commits until the desired one appears" is a feasible solution for large repos when the commit is really old. Imagine if you tried to navigate to 3611ed35610793e814c8aa25715aa582ec08a8b6 in Roslyn, which is 65k commits deep into the repo.

At the very least this strategy would require using something like git rev-list --count to estimate the number of commits it needs to load and fail/warn if it's too many. (Since I assume handling it gracefully would require some major rearchitecting of Git Graph's internals.)

[bradlitterell]

I would sure be interested in a jump to commit feature as well. Regarding the comment above about loading children, this jump to commit would be useful even if it loaded only ancestors of the given commit, though it would be admittedly better to also show children.

Implementing this in the branch selection dropdown makes the "ancestor-only" view make more consistent sense - since that's what you'd get if there was a branch at that same commit and selected that in the branch drop-down.

Kindly request consider reactivating this issue.

[pktiuk]

I find this feature essential in bigger repositories.
There are already some duplicates mentioning similar solutions. (#358 #505)

I think this feature could be also linked with jumping to tags and branches in source tree.

Instead of keeping all of sha-s in memory we could just try to check whether does it exist in git repository and then scroll to it.

I don't know how it should be implemented, but I am sure, that there is a way of doing without storing immense amount of data in memory.

[pktiuk]

Even if there is no chance of implementing it right now, I think it should be opened to avoid further duplications.
(Anyway, I think using separate function jump to commit is much better than merging it with search, as it is suggested in other issues)

[hashfx]

Here's a temporary fix if anyone want to access specific older commits on some click (in Binary Search logic):
Notice the +xx part after ?after=commitNumber+xx in commits URL, like https://github.com/hashfx/pvtRepo/commits/master?after=698069a420a3a6090a6699c94a98e8d1e16b2254+34 [ +34 in this case ];
That's how commit pages in GitHub are indexed. So to visit specific page of commits history: change +xx to:

number of commits (c) = xxx
let index = c - {number < c}

URL would look like:
https://github.com/user/repo/commits/master?after=commitNumber+index

More like: https://github.com/hashfx/pvtRepo/commits/master?after=698069a420a3a6090a6699c94a98e8d1e16b2254+69

Keep trying until you get your required page 👍🏻