Complete support of rebase operation

[scippio]

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.

[mhutchie]

Thank you for raising this feature request.

Just to clarify, am I correct in saying that the workflow for this scenario is:

1. User selects "Rebase current branch on this Commit..." or "Rebase current branch on Branch..." from the respective context menu.
2. User checks "Launch Interactive Rebase in new Terminal".
3. User presses "Yes, rebase".
4. User begins the interactive rebase process in the terminal.
5. Git Graph keeps a dialog open while the interactive rebase is occuring. On this dialog, there are button that automate running git rebase --continue, git rebase --abort etc.

[scippio]

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.

[arisjulio]

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:

1. User selects "Rebase current branch on this Commit..." or "Rebase current branch on Branch..." from the respective context menu.
2. User presses "Yes, rebase".
3. Git Graph keeps a dialog open while the rebase is occuring.
4. If there are conflicting files, the dialog will avail buttons that automate running git rebase --continue, git rebase --abort etc.

[mhutchie]

@arisjulio What you've described should definitely be possible! I'll keep it in mind when I implement this feature request.

[Gruntfuggly]

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?

[mhutchie]

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’t 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’t anything that I can change in the extension to change what you’re experiencing.

I am aware that the Visual Studio Code’s 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’ve also observed that when running Git commands on a network share running a different OS sometimes the Git lock files are not released (I’m not sure if this may be applicable for you).

[Gruntfuggly]

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.

[mhutchie]

@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’t running any Git commands at the exact same time.

[Gruntfuggly]

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.

[mhutchie]

@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:

1. Keep watching the repository for file system changes while the vscode window is unfocussed, so the extension can still be aware of any changes to the repository.
2. Use 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.
3. When the window is refocussed, if any changes occurred in the repository while the vscode window was unfocussed the Git Graph View will do a background refresh.

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).

[dan1994]

I've been tinkering with this feature and came up with something like:

@scippio, @arisjulio, is this the kind of UI you were looking for? @mhutchie, Do you think this is a good idea? If so I can develop this feature.

[mhutchie]

Hi @dan1994,

After the initial discussion on this feature request, I’d come to the opinion that if it were to be included, I’d want to include more than just abort and continue. Both for completeness, and to better deal with a number of resulting scenarios I’d identified (that requires uplifting the broader Git Graph View capabilities). Consequently, this feature request would require a custom user interface (more than just a few buttons), and be quite complex & time consuming to implement.

As only 5 users have indicated they’d value this feature (out of over 1.2 million users in almost two years), it frankly doesn’t justify the effort and time to implement it. If significantly more interest is expressed in the future, it can be re-prioritised appropriately.

[dan1994]

OK, thanks for the response

[dzid26]

Hi @dan1994,

After the initial discussion on this feature request, I’d come to the opinion that if it were to be included, I’d want to include more than just abort and continue. Both for completeness, and to better deal with a number of resulting scenarios I’d identified (that requires uplifting the broader Git Graph View capabilities). Consequently, this feature request would require a custom user interface (more than just a few buttons), and be quite complex & time consuming to implement.

As only 5 users have indicated they’d value this feature (out of over 1.2 million users in almost two years), it frankly doesn’t justify the effort and time to implement it. If significantly more interest is expressed in the future, it can be re-prioritised appropriately.

Can GitGraph use GitLens rebase interactive GUI? https://github.com/gitkraken/vscode-gitlens#interactive-rebase-editor-

I think it can be called via: git -c sequence.editor="code --wait --reuse-window" rebase --interactive comit_xxxxxxxx

[scippio]

@dzid26 that's looks really nice...