alicederyn / git-rex Goto Github PK

If scripts don't output much, it's not clear which line they have failed on (or even that failure has occurred at all, if rex is not running within a rebase).

We could leverage https://stackoverflow.com/a/10744519/125663 to output the line number of the failure. (We will need to start capturing line number information in extract_scripts.)

This should function like cherry-pick --no-commit:

• leaves changes uncommitted
• disables the startup check that the index is clean
• leaves the commit message in .git/MERGE_MSG

Ideally, it would also flatten the executed script in interactive mode, though that introduces a lot of complexities around state (e.g. cwd, env vars).

The following:

mkdir foo
cd foo
echo "Hello there" > bar.txt

should create bar.txt in the folder foo/, but currently does not.

Separate script blocks should be run in separate shells (in particular, doing a cd in one script block should not affect any subsequent script block).

Errors should be handled as if -e and -o pipefail were set

Currently, git rex relies on comments being stripped from commit messages. However, depending on the value of the git commit --cleanup flag, comments may be left in. rex should strip them (and, in particular, error if a commit contains only comments in its script section).

This should probably do at least the following:

• Run set -x in bash
• Message when each bash script finishes, and with what status code Not necessary now we have fixed #27

$ git rex --help
No manual entry for git-rex

We might be able to leverage argparse-manpage to do the actual generation. However, I am unclear:

• how to run the generator automatically with poetry
• where the manpage needs to live for git to pick it up
• how one would then get it there with pipx

It would be very convenient for rex to offer a --from-history flag, where it captures all the current shell's history, back to whatever the last git command was, and drop into an editor for a commit message with said commands listed in a script block.

This feature is likely to have a lot of subtle complexities to worry about; for instance, certain git commands like diff are a common part of establishing that a command has done what the user anticipated, so should be skipped over in the history.

Should respect the core.editor config, if set.

The following should be valid commands:

• git rex --edit COMMIT — Opens the commit message of COMMIT in an editor prior to executing the script, similar to git cherry-pick --edit
• git rex --edit — Opens a template commit message in an editor; executes the user-supplied script and commits.

Both will need to implement the behaviour of the git commit --cleanup flag prior to executing the script. Optionally, we could add a new default mode that does not ignore comments in script sections, as that's probably going to be pretty convenient.

Automated commit created with git-rex

The following commands were executed:

```bash
# Enter your script here. It will be executed, and all files created
# or changed committed to your repository.
```

# Please enter the commit message for your changes. Lines starting
# with '#', except those in script sections, will be ignored, and an
# empty commit message, or one with no script commands to execute,
# aborts the commit.
#
# On branch foo

Both should respect the core.editor config, if set.

Error trace from version 0.2.0:

$ git rex -h
Traceback (most recent call last):
  File "/home/apurcell14/.local/bin/git-rex", line 5, in <module>
    from git_rex import main
  File "/home/apurcell14/.local/pipx/venvs/git-rex/lib/python3.8/site-packages/git_rex/__init__.py", line 33, in <module>
    def extract_script(message: str) -> tuple[str, ...]:
TypeError: 'type' object is not subscriptable

I note that the CI tests for python 3.8 just say "Error" on the step that should install this version of python, which is probably why we have regressed.

It would be very convenient for rex to offer an --interactive mode, where it enters a REPL for bash that captures all commands run and, once the user has run exit or hit ^D, drops into an editor for a commit message with all evaluated commands listed in a script block.

We can probably leverage bash itself for the REPL, if we can reliably configure its history mode without the user's config files interfering. This means:

• Changing which file history gets written to
• Turning off the leading-space-disables-history feature
• Setting a trap for errors that documents ways to recover (e.g. using || true)

We will also ideally have some consistent way of handling executed git commands in a non-surprising way; for instance, we could do one or more of:

• strip informational commands like status from the history
• replace the command itself to intercept and disable commands like commit
• leave the repository locked to prevent concurrent operations

In particular, this should run:

• black
• pytest

In particular, the following shells are likely to be desireable to anyone not familiar with bash:

• ksh
• tcsh
• python

This issue should be split into multiple issues, one per shell, prior to implementation.