Show HN: Interactive Smartlog VSCode Extension – An Interactive Git GUI (marketplace.visualstudio.com)
Interactive Smartlog is a graphical VSCode extension that presents a simplified view of the Git log, directly highlighting the branches and commits that are most relevant to your current work. And it's not just a visual tool — it's fully interactive, allowing you to add/switch/remove branches, stage/unstage files, and manage commits directly from the GUI.
This tool draws inspiration from Meta's Interactive Smartlog built for the Sapling source control system, and I've adapted it to work with Git. Transitioning the functionality from Sapling to Git wasn't just about a one-to-one feature transfer; it involved changing how data is queried & presented, as well as introducing UI interactions for several Git concepts (like branches, staging/unstaging changes, etc) which are not present in the Sapling source control system.
Originally a personal project to enhance my own workflow, I've published the extension on the VSCode marketplace for anyone who would like to use it. I'm keen to hear your feedback and suggestions, as community input is invaluable in shaping its future updates.
24 comments
[ 87.3 ms ] story [ 1439 ms ] threadI edit with neovim. Open a terminal within my editor (yea i know neovim has magit and others but I'm oldschool) and stage things and commit as atomicly as I can, and then go back to work.
But as a team we try to get everyone to merge often and are very long lived branches as code smells. This keeps changes small and conflicts small.
Even some projects that offer only APIs on GitHub make it seem like they’re more open source than they are, putting the whole project info into the readme. Some people care about visibility into the software that runs on their machine.
VSCode's built-in commit-crafting UI (diffing, staging, stashing, committing) is good enough but branch management (viewing, switching, rebasing, squashing) is lacking a built-in solution. I'll give this one a try, thanks for sharing.
[1] https://github.com/FredrikNoren/ungit
1. Rebasing doesn't appear to be supported 2. An extra "Sapling" repository has appeared alongside my git repository in the "Source Control" tab
I'm looking forward to trying it out more, thanks for publishing this.
#2 definitely sounds like a bug - I’ll look into that!
#1 - Rebasing should definitely be possible, but only when A) the commit you’re rebasing onto is not a descendent of the one you’re currently on, and vice versa and B) The target commit should either be on the primary branch (usually origin/main or origin/master) or have branched off from the primary branch at the same point or later than the commit you’re currently on does. This condition isn’t strictly necessary, but the thinking is that usually people want to rebase onto the commit that’s further ahead.
For any commit where these conditions are met , a rebase icon-button should appear when you hover over that commit, to its right.
Let me know if you’re still having trouble, or if you have any follow up UX feedback!
[1]: https://marketplace.visualstudio.com/items?itemName=mhutchie...
- In ISL, your uncommitted changes are highlighted as a key part of the UI, and you can perform git actions on your uncommitted changes (staging/unstaging, reverting, etc)
- ISL aims to present a minimalist view of your repository, with only commits and branches that are relevant to your work.
- You can view pull request status via ISL (accepted/rejected/needs-review, # of comments, CI status).
- ISL aims to never send you to the command line. When you rebase, for example, you can perform all actions entirely within the UI (though you may need to go into files for conflict resolution).
- ISL encourages usage of the UI for git operations: git actions appear as buttons in the UI (whereas in Git Graph, they appear via a context menu when you right-click on a commit)
- You can easily create & amend commits, and push branches in ISL via buttons in the UI.
Hope this helps! Let me know if I can answer any other questions :)
How exactly is it determining the "most relevant" commits? Is this just filtering out commits that don't touch the current file(s)? Or some kind of scoring metric?
1. The branch isn't following a remote branch that's been deleted (which often happens after merging or deleting a pull request).
2. The branch has a common commit with the primary remote branch (usually origin/main or origin/master) from the last 2 weeks. You can see older commits & branches by clicking “load more commits.”
Then, it displays all the commits from the top of that branch down to where it joins with the main branch.
If the HEAD commit meets the primary branch at a commit more than 2 weeks old, then the 2 week range is extended (for all branches) as well.
One thing I'm missing is interactive rebasing - being able to whip up an interactive rebase by perhaps right-clicking a commit in the history of the currently active branch would be useful, I think.