cmd/git-go-patch: enhance git-go-patch with robust patch application and streamlined interactive rebase workflow#281
cmd/git-go-patch: enhance git-go-patch with robust patch application and streamlined interactive rebase workflow#281
Conversation
…flow Adds a new `git go-patch rebase-interactive` command that provides an automated workflow for patch file editing. This addresses issue #750 by combining the manual steps of rebase and extract into a guided process. Features: - Opens interactive terminal in submodule directory (no manual cd needed) - Modifies PS1 prompt to show "(git-go-patch)" mode indicator - Automatically runs `git go-patch extract` when terminal exits - Supports --skip-extract flag for manual control - Sets GIT_GO_PATCH_INTERACTIVE=1 environment variable - Provides clear instructions for VS Code integration (`code .`) This streamlines the previous 6-step manual workflow: 1. git go-patch apply 2. cd submodule 3. git rebase -i <base> 4. [manual work] 5. cd .. 6. git go-patch extract Into a 2-step guided process: 1. git go-patch apply 2. git go-patch rebase-interactive The nested terminal approach avoids confusion with clear visual indicators while enabling complex rebase operations and IDE integration. Fixes microsoft/go#750
d01fc29 to
5b237c6
Compare
|
CC @dagood, I was playing around with this the other day and nearly created an identical issue to yours, have a play around with this and let me know what you think |
|
@dagood updated PTAL |
|
@dagood updated PTAL |
| } | ||
|
|
||
| fmt.Printf("\n%s=== Press Enter to continue ===%s\n", "\033[1;33m", "\033[0m") // Yellow text | ||
| _, _ = fmt.Scanln() // Wait for user to press Enter |
There was a problem hiding this comment.
I (slightly) preferred git go-patch shell rather than tacking this onto rebase, but wasn't sure why... now I realize I don't think it's always useful to immediately run a rebase. It seems like it would only make sense to rebase immediately if you're using edit/break and other rebase commands directly, but I rarely do that. I rebase after I've poked around and figured out what I want to do, and probably integrate some new commits back into the sequence of patches.
Or maybe I only have a new patch to add, no rebase at all.
Splitting it out simplifies each command and removes the reason to have this "just press enter" step.
git go-patch shell could accept git go-patch shell -rebase as a way to keep this functionality (which I could see being useful depending on what kind of patches you're doing), but in a more flexible way.
An -apply flag would also fit in, that way.
| if userShell == "" { | ||
| userShell = "/bin/bash" // Default Unix shell | ||
| } | ||
| } |
There was a problem hiding this comment.
File issue about PowerShell support (on Windows and on Linux)?
| The shell prompt is automatically updated to show `(git-go-patch)` to indicate you're in the interactive mode: | ||
| * Unix shells: Updates the `PS1` environment variable | ||
| * Windows Command Prompt: Updates the `PROMPT` environment variable | ||
| * Powershell is not currently supported |
There was a problem hiding this comment.
Also doesn't work if on Linux if using PROMPT_COMMAND because it overwrites PS1 all the time.
This PR addresses issue microsoft/go#750 by significantly improving the patch application process and adding a new interactive shell mode for rebase operations.
Key Features:
Enhanced Patch Application
Streamlined Interactive Rebase Workflow
Workflow Transformation
Before (manual 6-step process):
After (2-step guided process):
git go-patch apply git go-patch rebase -shell # Interactive session with automatic extraction