We could make another command that goes a bit further with helping out vs. the user-driven 1: git go-patch rebase 2: [user does what they need] 3: git go-patch extract. The new command could open a new terminal for the user to run rebase-related commands in that starts at the root of the submodule. (So manual cd is not necessary.) Then, when they close the subterminal (exit), the new command would resume and run git go-patch extract automatically.
A concern is that if you forget you're in this mode, you have two nested terminals, and exit will be confusing and could overwrite some work you did later in a different terminal. Perhaps we can prepend something to PS1 to make it easy to see the mode at all times.
If you type code . inside the subterminal, you also get a VS Code instance with the submodule's history and not the parent repo's history. This might be a nice workflow for Go modules (no multimodule support needed for parent repo and submodule) and avoids potentially getting the two repos' Git history mixed up in VS Code's Git UI.
I'm not sure this is enough of a workflow improvement to justify the work and potential confusing states you might end up in with it. I had this idea while filing this other issue and thought it was worth typing up, anyway:
We could make another command that goes a bit further with helping out vs. the user-driven 1:
git go-patch rebase2: [user does what they need] 3:git go-patch extract. The new command could open a new terminal for the user to runrebase-related commands in that starts at the root of the submodule. (So manualcdis not necessary.) Then, when they close the subterminal (exit), the new command would resume and rungit go-patch extractautomatically.A concern is that if you forget you're in this mode, you have two nested terminals, and
exitwill be confusing and could overwrite some work you did later in a different terminal. Perhaps we can prepend something toPS1to make it easy to see the mode at all times.If you type
code .inside the subterminal, you also get a VS Code instance with the submodule's history and not the parent repo's history. This might be a nice workflow for Go modules (no multimodule support needed for parent repo and submodule) and avoids potentially getting the two repos' Git history mixed up in VS Code's Git UI.I'm not sure this is enough of a workflow improvement to justify the work and potential confusing states you might end up in with it. I had this idea while filing this other issue and thought it was worth typing up, anyway:
cdto the submodule directory when runninggit go-patch rebase#749