Git: Support interactive rebase

[cleidigh]

Since it is typical for projects like Code and others to have PRs with a single command for brevity and cleanliness, this feature would be really helpful to not have to go into the terminal.

Willing to do a PR...

[cleidigh]

@joaomoreno Would you accept a PR on this? Or do you want to keep it internal?

[joaomoreno]

I'm not sure how this could look like. What are your thoughts?

[cleidigh]

@joaomoreno

• Command is squash commits
• Use quick pick menu with two sections
• At top of list give user option to squash commits to common ancestry point (put Master at top of list if exist) for each entry show date and short hash (could use base-merge option)
• After list of common ancestry points, show commit list to allow a squash to any commit
• Give user option to create squash commit or not
• Give user option for default base branch for common ancestry point

As stated before , the use case is mainly cleaning up local commits in preparation for single commit PRs as is preferred for projects like VSC

[cleidigh]

@joaomoreno I guess the other option is doing this through an extension (GitLens) if you think that would be better. Either way it would be great to have your opinion on the approach above.

[joaomoreno]

I think getting started with an extension would be a great way to prototype this thing. Gitlens would not be ideal since it seems that extension, though powerful, dedicates itself to a read-only view of repositories.

Since git is now an extension, it could actually expose API to other extensions to give them the full power of git: #31103. This could open the door to explore new features as extensions, such as the one we mention here.

Finally, one thing seems to be missing from this story: squashing is but a small part of a much powerful feature, rebasing, which we should probably tackle first.

[cleidigh]

@joaomoreno Great. Thanks for discussion points ! I get that rebasing is the main feature. Let me to do more research as I am no git guru then I will put out a proposal for an extension approaching rebasing first.

Should I change the title of this issue to reflect a discussion on rebasing?

[benc-uk]

Any update on this? Would be really good to have squash supported directly by VSCode with the UI supporting it

[jmbockhorst]

I have started working on some initial rebase features. Here is what I have so far:

• The ability to rebase a branch on the current branch.
• The ability to consolidate commits

When a rebase is in progress, the rebase command shows the "Continue", "Abort", and "Skip" options.

Rebase from a branch

This command lets you choose a branch to rebase onto the current branch. If there are any conflicts, you can resolve them manually and run the "Rebase: Continue" command. Repeat this process until all conflicts are resolved (like you normally would with git rebase) and it tells you that the rebase is complete.

Consolidate commits

This command lets you choose a commit to consolidate back to, and then opens up the git interactive rebase file for editing. The ability to squash all commits and add a new commit message without having to edit the text file could be a specific option added in the future.

Feedback would be appreciated on what other features to add and how it looks so far. Thanks!

[antonholmberg]

@jmbockhorst That is exactly what i want! Looks amazing. Will it be released to insiders?

[jmbockhorst]

Any feedback on the above rebasing features? Should I create a PR as it is currently?

[senolfeldmann]

This is exactly what I miss after switching from SmartGit to VS Code for git. So, please create a PR :)

[wmertens]

Some possible features, borrowed from https://github.com/git-up/GitUp:

• single commands that use rebasing behind the scenes to:
  • move commits up/down
  • squash into parent
  • fixup (same as squash but allows editing the combined commit messages
  • rewrite commit (roll back working tree to commit, drop into amend interface for commit, afterwards apply all later commits)
  • whenever a merge conflict would happen, allow fixing it or cancel the action
• undo/redo: any action stores the refs and undo/redo lets you walk those refs. So you can never mess up a rebase.
• history view: see the undo stack

[Kurt-von-Laven]

@jmbockhorst would you be willing to open a PR with the impressive features you demoed? If more features are desired, they could go in a separate PR, or someone else could build atop of your hard work.

[holbrookdev]

This fixed it for me:

git config --global core.editor "code --new-window --wait"

The difference from prior solutions is the --new-window option which forces to open a new window.

Past Issues:

• https://github.com/microsoft/vscode/issues/110995
• https://github.com/microsoft/vscode/issues/92628
• https://github.com/microsoft/vscode/issues/66146
• https://github.com/microsoft/vscode/issues/61877
• https://github.com/microsoft/vscode/issues/51262
• https://github.com/microsoft/vscode/issues/42806

[phil-blain]

Now that VSCode for the web and github.dev exist, it would be really nice to be able to do an interactive rebase using the VSCode UI, since these environments lack a terminal.

[kasperk81]

any updates? lack of interactive rebase in github.dev is a huge pain!

[AnthonyMastrean]

I'd say Continue and Abort operations are needed for the normal Merge and Cherry-Pick workflows, too. #193042