Describe the feature that you'd like
Git Graph supports "rebase current branch to this commit..." but after than there are some another possibile steps like --continue --abbort etc... and it will be nice to have this operation supported better than like console command.
Thank you for raising this feature request.
Just to clarify, am I correct in saying that the workflow for this scenario is:
git rebase --continue, git rebase --abort etc.Yes, the interactive mod will be great. Workflow like in this article: https://medium.com/singlestone/a-git-workflow-using-rebase-1b1210de83e5
But graphical UI for this process can be great too... but it's more complex... so I think it's better with terminal for now.
Is it possible to add this feature outside of the interactive mode?
For example, If the rebase has conflicting files, the continue button or abort could be added in some place on the UI like in a dialog.
The workflow for this scenario that I propose is:
git rebase --continue, git rebase --abort etc.@arisjulio What you've described should definitely be possible! I'll keep it in mind when I implement this feature request.
At the moment, if I do an interactive rebase outside of the extension (and vscode) the extension interferes (it grabs the .git lock file). Is there a way to tell the extension to ignore changes while the code windows is not active?
Hi @Gruntfuggly,
Git Graph only runs Git commands when the user interacts with the extension (either when loading / refreshing the view, or running an action). If the Git Graph View is not open or it is not the visible tab, it does not watch the file system for background changes (and consequently won鈥檛 run any Git commands). Only when a Git command is running will Git create the lock. As such, the extension does not interact with the Git lock in any way, so there isn鈥檛 anything that I can change in the extension to change what you鈥檙e experiencing.
I am aware that the Visual Studio Code鈥檚 built-in Git extension has been known to monitor the file system and run Git commands that can create the lock, even when it is not active. I believe this is the most likely cause of the lock file for you. Additionally, I鈥檝e also observed that when running Git commands on a network share running a different OS sometimes the Git lock files are not released (I鈥檓 not sure if this may be applicable for you).
I've turned vscode's settings for monitoring the repo, and when I quit code, the rebase was fine. I did have git graph visible when I was doing the rebase though.
I'll investigate further.
@Gruntfuggly, The Git Graph Output Channel logs all Git commands that the extension runs (with timestamps). If you observe the lock, you can check the Output Channel to confirm that the extension wasn鈥檛 running any Git commands at the exact same time.
Yes, it's because the view was active. I can see it detects something changing and does a reflog to refresh.
Would it be possible to stop watching when the vscode window becomes unfocused, even if the git graph is still visible?
There is vscode.window.onDidChangeWindowState which indicates if the window is focused.
@Gruntfuggly
I think the best solution for Git Graph, when the Git Graph View is the active tab in vscode but the vscode window itself is unfocussed, would be to:
vscode.window.onDidChangeWindowState to hold running a background refresh (and the associated Git commands) on the repository until the vscode window is refocussed. This will prevent any Git locks from being created while the vscode window is unfocussed.I'll raise a feature request for this, and implement it in Git Graph 1.24.0 (a beta release will be available for you to use with this change within the next week). I'm currently in the final preparations for releasing Git Graph 1.23.0, once it is released this will be the second item I do for 1.24.0 (after a PR that is currently waiting my review).