-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a step-by-step git commiter #94
Comments
@rnorth that's kinda what I talked about in the last TAB. |
Further questions: Should it be Y/n or y/N? Easier to start with no default to start with and see what happens. |
Started working on this, just to validate the proposed workflow:
The untracked files are explicitly excluded from the list, because by default |
While looking at #94, I've notived that the output of `turbolift commit` includes a weird line: ``` Executing: /opt/homebrew/bin/zsh [-c ...] ``` This is because `isRepoChanged` function executes a command to figure out whether something is marked as changed. Every command executed generates an echo of the command for the user. This PR introduces a new flag on the executor that will skip the echo. This fixes the extraneous output in `isRepoChanged` but will also be useful in future features.
* fix(executor): Adding silent mode and tests While looking at #94, I've notived that the output of `turbolift commit` includes a weird line: ``` Executing: /opt/homebrew/bin/zsh [-c ...] ``` This is because `isRepoChanged` function executes a command to figure out whether something is marked as changed. Every command executed generates an echo of the command for the user. This PR introduces a new flag on the executor that will skip the echo. This fixes the extraneous output in `isRepoChanged` but will also be useful in future features. * fix(executor): Fix unit test and condition pattern
On large repo lists, one often has to run this kind of workflow:
then, to validate the changes, they would run something like this:
It would be nice to have a way to commit those step-by-step with a visual validation from the user, introducing a
--incremental
.The workflow would look like:
We will log in the end the repo list that WASN'T updated, the user can decide what to do with it then.
The text was updated successfully, but these errors were encountered: