I have found that git-revise strips GPG signatures from commits.

This seems better than leaving invalid signatures behind, but still seems unfortunate, especially given there is no visible warning.

Is it possible to sign revised commits as part of the revision process?

In an interactive rebase, 'edit' means changing the contents of the commit, which is not available in revise. So --edit might be a bit confusing, as it actually corresponds to rewording a commit.
Should this be renamed to --reword?

As a non-native English speaker, when I encounter 'cut' in an application, I link it to cut/copy/paste (so: delete-and-place-on-clipboard). I think a term like 'split' covers the goal more clearly (supported by the fact that the man page explains the feature with 'split' and 'splitting').
This should not only impact command line option --cut, but also command cut in an interactive revise. Here, split will conflict with squash. So maybe chop (and --chop) is a feasible alternative?

This project should provide a mechanism to perform git add -p-style changes to a commit, splitting it into distinct commits.

I tried git revise upstream/master on my local gecko-dev clone and got this:

invalid value: Commit bac38ea0eacfc9f319de142aa6ca3483dcdce780 has 2 parents

That's mozilla/gecko-dev@bac38ea, but not sure why it is a problem. Can I get some help?

I don't see a changelog anywhere. The only way to see what's in a new release seems to be to read through the git commit history.

It would be nice to be able to edit a stack of messages at the same time to ensure that an entire commit stack is consistent. Currently I often do this with my git-rmsg project, but it might make sense to integrate into this project.

Frequently when splitting a commit, I want to split it into more than two pieces. For example, there may be several kinds of independent kinds of changes that need to be split out; or a commit with several instances of the same kind of change, that might need to split per each file or module.

git-revise is very useful for quickly cutting up those commits, and faster than rebasing, but it currently only supports "part [1]"/"part [2]". In order to make multiple cuts, currently it requires repeated invocations, manually copying the commit hashes (since the target hash for a new cut will always be different each time).

It would be extremely useful to support repeated cuts. This also may not be very difficult to do: for example just restart cutting on the "part [2]" until the user specifies an empty cut.

I'm on a pretty vanilla MacOs Mojave.

I had to add python3 using brew since my system only had python2 by default
brew install python3

Installed using a slightly different command than the one in the doc
pip3 install --user git-revise

No the modules is installed but when I run git revise I get this error.
git: 'revise' is not a git command. See 'git --help'.

Unless i just haven found that file this feature i have been missing:

when revise tries to do its thing it sometimes fails which is mostly due to botching the editing. Hence it would be grand not loose all that work and retry with where one has left off. 2 ideas come to mind on this:

a) echo where the content is stored (e.g. $PWD/.revise.txt, or .git/info/revise.txt)
b) have an option to rerun the last interactive session with the editor prefilled with that content + afterwards the normal generated content but commented out, so that it may serve as a reference.

This could also help in the case of #34 in which the revise would run thru,but w/o a failure. Nevertheless, those precious message edits are lost to /dev/null.

This project should be able to automatically apply autosquash commits, ideally without needing to explicitly specify a base commit.

First of all, thanks for the excellent tool! Very useful and well documented.

I've set up ed as my git editor (using git config, no env variables involved):

$ git config --get core.editor
ed --loose-exit-status --prompt 'ed> '
$ git var GIT_EDITOR
ed --loose-exit-status --prompt 'ed> '
$ env | grep EDITOR
$

Everything works fine in git rebase, but not in git revise:

$ git revise -ei
': No such file or directory
'ed>

The editor is loaded, but it's empty (the revise file is not read).

I've found out that the problem is the 'ed> ' part in my GIT_EDITOR, which breaks this code:

The combination of bash -c, exec and a subshell $(...) does not work as expected in that case, because of the quoting and the white space. If I change 'ed> ' to something like 'ed>' (no space this time), it works, but not a 100% correctly:

$ git revise -ei
747
'ed>'

Now the file was loaded into the editor and everything works in the git revise side. But those literal ' chars are not supposed to be there.

In my local testings here, everything work as expected when I first get the git var GIT_EDITOR output into a variable, and then use that variable in the editor call:

# get user's editor

>>> editor = subprocess.run(["git", "var", "GIT_EDITOR"], stdout=subprocess.PIPE).stdout.decode('utf-8').rstrip()
>>> editor
"ed --loose-exit-status --prompt 'ed> '"


# try to run with the current code (== error)

>>> subprocess.run(["bash", "-c", "exec $(git var GIT_EDITOR)"])
': No such file or directory
'ed>q
CompletedProcess(args=['bash', '-c', 'exec $(git var GIT_EDITOR)'], returncode=0)


# running with the modified code is ok

>>> subprocess.run(["bash", "-c", f"exec {editor}"])
ed> q
CompletedProcess(args=['bash', '-c', "exec ed --loose-exit-status --prompt 'ed> '"], returncode=0)
>>> 

I've opened #31 to address that.

Would be nice to have tags in Git, so we can fetch tarballs from Github as as well.

I'm curious to know why we cant use Golang or Rust. 🤔

When on Windows, git-revise starts the GIT_EDITOR command itself, rather than invoking it through the shell. Correctly invoking through the shell on Windows is more complex than on other systems, as the environment which git is run in is not the same as the current python instance.

Git for Windows ships with a msys-based environment, including its own copy of bash and other *nix utilities. In order to correctly match GIT_EDITOR behaviour, git-revise would need to run the command within the same msys environment it was executed from. Unfortunately, I am not aware of a way to return to this environment once it has invoked a native windows application, such as python.

Originally, git-revise would invoke an executable named bash on the PATH for this purpose, but that could cause massive overhead, such as starting a wsl environment (#19). The current behaviour, suggested in #19 (comment), is to attempt to invoke GIT_EDITOR directly, however this can cause issues due to differences in PATH searching, such as in #24 (comment).

Workaround

Use a native Windows editors, and reference them from core.editor by their unambiguous Windows path.

Given a git log like this:

1 add feature
2 fix something
3 fix tidy

Currently, git-revise only combines messages of squashed commit one by one.
Which means that it combines 1 and 2 saved, then combine the result to 3.
git-rebase combines 1, 2, 3 in one step.

Lovely tool, I'm packaging it for Void Linux.

Please add a LICENSE with a copyright line file if it's MIT-licensed.

When using git rebase, one can add the --root options to allow editing even the very first commit in a repository.

I would like to have a way to do the same with git revise, I even tried using the semi-famous empty tree hash-id, without success.

It would be nice if the interactive mode had an exec command. This would be executed with the working directory pointing at an empty temporary directory, but environment variables set up appropriately such that git commands will manipulate the git index. This way I can do arbitrary operations that don't rely on a working directory.

For example, if I want to reset the author of a single commit, I could insert the line

exec git commit --amend -C HEAD --reset-author

There's also an argument for having another variant of this that operates out of a workdir, but the default should be index-only.

If multiple exec commands are given they should run from the same temporary directory. The temporary directory should also only be cleaned up after the whole operation is complete. This means that without the workdir version I could approximate it by saying something like

exec git --work-tree=. checkout -- .
exec echo foo > foo
exec git --work-tree=. commit --amend -C HEAD foo

I know from past git rebase -i usage that I sometimes instinctively try to edit commit summary lines directly in the interactive line view, instead of selecting to reword each messaage. Which just drops my changes. And despite learning this lesson numerous times, it still happens that I forget myself.

Learning that the awesome git revise -ie command supports bulk renaming, I had to see what it would do in -i mode, and the story seems to be the same. Thus what the headline suggests.

Benefits:

1. It is nice when it just works™.
2. Avoids a separate renaming pass if you already are in -i mode for other reasons.
3. Not all editors have a block mode that supports editing multiple non-consecutive lines (making the -ie view less ideal when you only want to edit the first line of each commit).

this git doc states that:

... A commit matches the ... if the commit subject matches, or if the ... refers to the commit’s hash. As a fall-back, partial matches of the commit subject work, too.

It seems however that revise only supports matching on the full subject line.
This should be noted in the doc or the code fixed.

This would be similar to the rebase.autoSquash config variable for git rebase -i. It should only have an effect if the -i flag is passed to git revise.

The condition for this if check will need to be expanded to consider git config:

When in a subdir of the git repo I am getting:

Traceback (most recent call last):
  File "/home/thiblahute/.local/bin/git-revise", line 10, in <module>
    sys.exit(main())
  File "/home/thiblahute/.local/lib/python3.7/site-packages/gitrevise/tui.py", line 191, in main
    inner_main(args, repo)
  File "/home/thiblahute/.local/lib/python3.7/site-packages/gitrevise/tui.py", line 182, in inner_main
    interactive(args, repo, staged, head)
  File "/home/thiblahute/.local/lib/python3.7/site-packages/gitrevise/tui.py", line 99, in interactive
    todos = edit_todos(repo, todos, msgedit=args.edit)
  File "/home/thiblahute/.local/lib/python3.7/site-packages/gitrevise/todo.py", line 213, in edit_todos
    """,
  File "/home/thiblahute/.local/lib/python3.7/site-packages/gitrevise/utils.py", line 90, in run_editor
    path = repo.get_tempdir() / filename
  File "/home/thiblahute/.local/lib/python3.7/site-packages/gitrevise/odb.py", line 223, in get_tempdir
    self._tempdir = TemporaryDirectory(prefix="revise.", dir=str(self.gitdir))
  File "/usr/lib64/python3.7/tempfile.py", line 788, in __init__
    self.name = mkdtemp(suffix, prefix, dir)
  File "/usr/lib64/python3.7/tempfile.py", line 366, in mkdtemp
    _os.mkdir(file, 0o700)
FileNotFoundError: [Errno 2] No such file or directory: '.git/revise.99am3enc'

cd the toplevel dir works just fine.

Thank you so much for git-revise, it's such a pleasure to use.

I tend to only use -p/--patch to add to the index because it lets me review the changes that are going in, and leave out anything that should go into a separate commit. It's even more useful with git-revise because often I only want to move a single hunk to an old commit while I develop a new one.

Just like -a/--all is supported, it would be great to support -p/--patch directly in git-revise, without having to git add beforehand.

First of all, great tool.

I have set git config --global core.commentchar ';', so comments in, for example, the interactive rebase TODO editor aren't prefixed with # but with ;. git revise -i ignores the settings and still shows # (which is unfortunate when editing commit messages with git revise -ie, since our commit messages start with #<ticket number>).

Could git revise respect the set commentchar?

I don't believe there is a realistic possibility the name of the module named __main__ will not be equal to "__main__".

Sometimes when I'm rewriting history, I've got multiple branches that contain the rewritten commits. For example:

A---B---C---D---E
 \       \       \
  master  featA   featB

This is common if I'm working on a feature, and decide that I want to publish a subset of commits to PR right now while I continue to work on the rest.

With this setup, if I rewrite commits B or C while featB is checked out, then featB diverges from featA and I have to go force-update my featA branch to point to the equivalent rewritten commit.

What I'd really like is a way to ask git-revise to just deal with this for me.

Non-interactive mode

In non-interactive mode, git-revise should print a warning to stdout if any local branches contain the rewritten commits but aren't being updated by this command. That way I can decide whether I should undo my change, or update the branch.

It should also support a flag that lets me list additional branches (besides HEAD) that should be rewritten as needed. This flag should take a glob string, so I can pass * to mean "rewrite any affected branches". I should be able to specify it multiple times. Alternatively it could take a fixed string and have a separate flag to mean "rewrite all branches", but I figure the glob string is a bit simpler.

This is somewhat related to the existing --ref flag, but that flag only identifies a single ref, and it's also got usability issues (apparently I need to list the entire ref)

With the above example, this would let me say something like git revise --rewrite-additional-local-branches \* $B while featB is checked out and it would rewrite both featA and featB for me (this flag is too verbose but it's just for illustrative purposes).

Interactive mode

In interactive mode, a new command ref should be added that lets me create or update a ref. In interactive mode it should behave as though --rewrite-additional-local-branches \* is implicitly specified if the flag isn't otherwise listed. When constructing the todo list, it should insert a ref command for every matching branch that points to a commit in the todo list, except of course for the working ref (HEAD or --ref) because that will always point to the final result. The --rewrite-additional-local-branches flag would default to * because I can always delete refs I don't want to update from the todo list before committing it.

When --autosquash is specified, any refs that point to a fixup or squash commit will not move with the fixup or squash commit, they will end up pointing to whatever non-fixup/squash commit was behind it. For example, if my initial todo list is

pick 5152786f70f2 b
pick 736a81426962 c
pick c08daa5ef3d5 fixup! b
ref refs/heads/featA
pick ce817c55b54c d
pick e7b6185cdd59 e

then autosquash will turn that into

pick 5152786f70f2 b
fixup c08daa5ef3d5 fixup! b
pick 736a81426962 c
ref refs/heads/featA
pick ce817c55b54c d
pick e7b6185cdd59 e

If the ref command is used to list the working ref (HEAD or the --ref value), this will do nothing because that ref will always be updated with the final result of the revise; listing this should be legal but it may be worth printing a warning about the ref command being ignored (and why).

Calling git revise -i HEAD~3 and removing a line to move it to the index does not work.

The help text in the git-revise-todo buffer says:

# If a line is removed, it will be treated like an 'index' line.

but removing a line (even the last) shows an error:

invalid value: Unexpected commits missing from TODO list.

Maybe it should also be mentioned that index lines must be last.

git-rebase(1) has this:

--signoff

Add a Signed-off-by: trailer to all the rebased commits. Note that if --interactive is given then only commits marked to be picked, edited or reworded will have the trailer added.

Hi,
I often tend to do a lot of patches and then "squash" them at once. This also often means doing fixup commits to fixup commits. This seems to be completely fine with git rebase as it orders the commits correctly when using --autosquash. Revise on the other hand only moves the fist fixup commit, but not the subsequent one. I've done a minimal example in new repo, hope it helps with understanding the issue.

The git log after fixups

b87da89 (HEAD -> master) fixup! fixup! commit file
b6f2725 commit foo
30ef468 fixup! commit file
66129ee commit bar
8c62b80 commit file

What git rebase -i --autosquash HEAD~5 shows:

pick 8c62b80 commit file
fixup 30ef468 fixup! commit file
fixup b87da89 fixup! fixup! commit file
pick 66129ee commit bar
pick b6f2725 commit foo

What git revise -i --autosquash HEAD~5 shows:

pick 8c62b80f0846 commit file
fixup 30ef468dcb74 fixup! commit file
pick 66129ee8750d commit bar
fixup b87da89b57b3 fixup! fixup! commit file
pick b6f27254b70f commit foo

The revise command only reorders the first fixup, not the subsequent one.
My git version and git-revise version:

> git --version
git version 2.25.2
> git-revise --version
0.5.1

I put → into a branch name, because I like doing things like that from time to time, and git-revise 0.5.0 didn’t like it:

invalid value: 'ascii' codec can't encode character '\u2192' in position 29: ordinal not in range(128)

(At first I thought this was because of a commit message, but when I modified tui.py to stop it suppressing the backtrace (please don’t unconditionally suppress backtraces like that!), I realised it was the branch name that did it.)

My initial reaction is that all mentions of "ascii" should be changed to "utf-8" in odb.py.

I have a Windows system with GIT_EDITOR=code --wait. When running git revise -i {whatever}, that editor is launched from within bash:

On Windows + recent copies of VS code, that invokes a fairly expensive operation that installs the Visual Studio Code Remote - WSL tools inside the WSL environment, then starts client and server processes to communicate with each other. Here, that's wasted effort amounting to several seconds of wait time, since the TODO file that's being edited is present on the Windows filesystem.

Is it possible to avoid the bash invocation, at least when running on Windows?

A useful feature of git rebase -i is that it says which commit failed to apply when there is a conflict:

Could not apply badbeef... Commit bla bla

To me, this is essential information, because the editing is after all not of the end result, but some intermediate commit – you need to know which commit you're editing. Even if you can guess it, you don't want to take chances here, because of how easily this can make a tangled mess of the commits.

Git rebase also repeats the commit title inside the editable git conflict (whereas revise just puts "incoming" here). That would also suffice, though I really don't like the userfriendlyness of standard git conflicts. Thus why I suggest printing a message in plain English.

Perhaps the git conflict is the better place for this info, but then I would say the real problem is the readability of standard git conflicts: They look too much like a conflict between equals, and presents which two commits it came from, when what matters is which one commit you're editing. They really should just say You are editing commit "Commit bla bla". If this is fixable, I would say you don't need the message, because then, a preview would hint even better to the user whether to edit or abort.

The blog post refers to using git revise in a patch stack workflow (e.g. Gerrit). However, neither the blog post nor the man page describes what the workflow actually is.

Given commits

A
B
C - HEAD

and my reviewer wants changes to commit B, I find myself needing to perform a git rebase -i / [hack hack] / git commit / git rebase --continue (and usually screw it up at some stage if I am honest with myself).

How do I use git-revise to edit commit B? Can this be added to the documentation?

Before I start using any CLI, I like to go through its --help options to make sure I understand how to use it. In this case, here is the abbreviated output of git-revise version 0.4.2:

$ git-revise --help
usage: git-revise [-h] [--ref REF] [--reauthor] [--version] [--autosquash]
                  [--edit] [--no-index | --all]
                  [--interactive | --message MESSAGE | --cut]
                  [target]

As you can see on the last line, [target] appears to be optional since it's wrapped in square brackets ([]). However, when I call git-revise with no additional parameters in some repo, it reports the following error:

$ git-revise
invalid value: <target> is a required argument

Please consider updating the --help output to indicate that target is in fact a required argument.

I just tried to invoke git revise -i and I get the following error:

foo$ git revise -i
bash: line 0: exec: 'nvim': not found
editor error: Editor exited with status Command '['bash', '-c', 'exec $(git var GIT_EDITOR) git-revise-todo']' returned non-zero exit status 127.

I'm using zsh, but I get the same error even if I try this command in a bash shell. Any ideas?

Both git commit and during a reword during rebase show the staged patch within the editor. I find it very useful context to have while crafting the message, it would be great for git-revisebto do the same.

I often want to revise the last commit that changed the file or files in the index.

I had been doing this manually until today, but I finally got fed up with it enough to make a simple alias.

As an alias (add to .gitconfig):

[alias]
	revise-most-recent-commit-that-touched-file = "!f() { if [ $# -eq 0 ]; then REV=\"$(git status --porcelain --untracked-files=no | sed '/^ /d;s/^.. //' | xargs -n1 git rev-list -1 HEAD --)\"; NUM_REVS=\"$(echo \"$REV\" | wc -l)\"; if [ $NUM_REVS -ne 1 ]; then >&2 echo Files in the index were not all last modified in the same commit; exit 1; fi; else REV=\"$(git rev-list -1 HEAD -- \"$1\")\"; shift; fi; echo git revise \"$REV\" \"$@\"; }; f"

Reformatted as a standalone script:

#!/bin/bash
if [ $# -eq 0 ]; then
	REV="$(
		git status --porcelain --untracked-files=no |
			sed '/^ /d;s/^.. //' |
			xargs -n1 git rev-list -1 HEAD --
	)"
	NUM_REVS="$(echo "$REV" | wc -l)"
	if [ $NUM_REVS -ne 1 ]; then
		>&2 echo Files in the index were not all last modified in the same commit
		exit 1
	fi
else
	REV="$(git rev-list -1 HEAD -- "$1")"
	shift
fi
git revise "$REV" "$@"

This script is not robust (I doubt it handles things like uncommitted files properly), but it’s good enough for me.

I have created this issue because I think this would be useful functionality to upstream into git-revise, e.g. git revise --last-commit-for-file=… (with the files defaulting to all the files in the index).

A better and safer version of this would allow users to specify an acceptable range of commits to revise (I’ve hardcoded HEAD here, but things like @{u}.. and master.. would be useful).

Another power-user feature would be to be able to revise different commits for each file in the index (rather than just bailing as I’ve written here). The alternative is adding each file and revising, one by one (or by as many files as are in each commit, anyway). This functionality would definitely save me time occasionally.

use case:
i had a commit with a couple of binary files but accidentally a change in a source file that i wanted to move to it's own commit

so i fired up git revise -c my-hash

...
Apply this hunk to index [y,n,q,a,d,e,?]? n

invalid value: cut part [1] is empty - aborting

it appears that the cut operation doesnt consider binary changes....

I have an alias recommit:

$ git config alias.recommit
commit --amend -CHEAD

It occurred to me that git revise HEAD desugars to essentially the same thing and so my alias is no longer needed. It would be nice if git revise used HEAD as a default target, so staged changes would simply be amended to the current commit with no other arguments.

pylint 2.3.1 works OK. pylint is updated to 2.4.1, and gives issues

py36 run-test: commands[1] | pylint gitrevise
************* Module gitrevise.odb
gitrevise/odb.py:141:8: E0242: Value 'workdir' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:142:8: E0242: Value 'gitdir' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:143:8: E0242: Value 'default_author' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:144:8: E0242: Value 'default_committer' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:145:8: E0242: Value 'index' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:146:8: E0242: Value '_objects' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:147:8: E0242: Value '_catfile' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:148:8: E0242: Value '_tempdir' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:400:17: E0242: Value 'repo' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:400:25: E0242: Value 'body' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:400:33: E0242: Value 'oid' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:400:40: E0242: Value 'persisted' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:471:17: E0242: Value 'tree_oid' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:471:29: E0242: Value 'parent_oids' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:471:44: E0242: Value 'author' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:471:54: E0242: Value 'committer' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:471:67: E0242: Value 'message' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:475:29: E1101: Instance of 'Commit' has no 'body' member (no-member)
gitrevise/odb.py:496:15: E1101: Instance of 'Commit' has no 'repo' member (no-member)
gitrevise/odb.py:500:16: E1101: Instance of 'Commit' has no 'repo' member (no-member)
gitrevise/odb.py:507:39: E1101: Instance of 'Commit' has no 'oid' member (no-member)
gitrevise/odb.py:549:15: E1101: Instance of 'Commit' has no 'repo' member (no-member)
gitrevise/odb.py:558:23: E1101: Instance of 'Commit' has no 'oid' member (no-member)
gitrevise/odb.py:601:17: E0242: Value 'repo' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:601:25: E0242: Value 'mode' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:601:33: E0242: Value 'oid' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:646:17: E0242: Value 'entries' in slots conflicts with class variable (class-variable-slots-conflict)
gitrevise/odb.py:650:15: E1101: Instance of 'Tree' has no 'body' member (no-member)
gitrevise/odb.py:656:39: E1101: Instance of 'Tree' has no 'repo' member (no-member)
gitrevise/odb.py:666:22: E1101: Instance of 'Tree' has no 'repo' member (no-member)
gitrevise/odb.py:667:8: E1101: Instance of 'Tree' has no 'repo' member (no-member)
gitrevise/odb.py:678:24: E1101: Instance of 'Tree' has no 'oid' member (no-member)
gitrevise/odb.py:687:24: E1101: Instance of 'Blob' has no 'oid' member (no-member)
gitrevise/odb.py:687:40: E1101: Instance of 'Blob' has no 'body' member (no-member)
************* Module gitrevise.tui
gitrevise/tui.py:214:8: R1722: Consider using sys.exit() (consider-using-sys-exit)
gitrevise/tui.py:217:8: R1722: Consider using sys.exit() (consider-using-sys-exit)
gitrevise/tui.py:220:8: R1722: Consider using sys.exit() (consider-using-sys-exit)
gitrevise/tui.py:223:8: R1722: Consider using sys.exit() (consider-using-sys-exit)
************* Module gitrevise.merge
gitrevise/merge.py:139:12: E1101: Instance of 'Blob' has no 'oid' member (no-member)

When cutting a commit, it lets you choose which patches to include in the first commit, but it doesn’t show anything for empty files that are created, meaning that all empty file creations will end up in the second commit.

At least slightly related to #33 which is about binary changes always ending up in the second commit.

Saying which commit has failed (#45) only helps as far as one remembers what each commit is doing in the conflicting lines. In a conflict situation with regular rebase, git diff will show a combined diff, which helps get a sense of this:

- Hello Word!
+ Hello World!
 +Oops, gotta add a new line!
  How are things?

The same information is available in the --diff3 mode of git merge-file.

Not sure if this is intentional or not or something that can be fixed with revise's design, but we use gerrit at work so each commit has to have a change-id inserted into the commit message before it can be pushed. I tried splitting up a commit with git revise -c (awesome btw) and it worked perfectly but did not run the commit hook so I was left without the change id in the new commit.

This isn't a huge issue, I just immediately ran git commit --amend after the revise and it added the change id no problem, but I figured I'd mention it in case its a feature you can / would like to add.

If I have a “base” commit and then several “fixup! base” commits, running an interactive revise will prepare the commit list in the wrong order.

For example, if the commit list is:

abc123 base commit
abc456 fixup! base commit
abc789 fixup! base commit

Then running git revise -i abc123~ will open an editor with these contents:

pick abc123 base commit
fixup abc789 fixup! base commit
fixup abc456 fixup! base commit

It should have generated this instead:

pick abc123 base commit
fixup abc456 fixup! base commit
fixup abc789 fixup! base commit

I suspect the this commit is the culprit.

It seems the --ref flag requires a fully-specified ref. This is a bit weird. I should be able to specify an abbreviated ref which it will expand for me, e.g. git revise --ref feature/foo instead of git revise --ref refs/heads/feature/foo.

Because this flag requires specifying an existing ref, this will not change the behavior of any existing legal invocations, it will only make it accept more values than it used to.

Curiously, the output suggests that part of the command does interpret it as an abbreviated ref, but the rest doesn't. In particular, --ref featA gives me the output

Applying staged changes to 'HEAD~3'
5e82a2e300e2 b
603f745f9635 c
Updating featA (736a814269625c169cf7123d0b3c3d49d7bc5126 => 603f745f96350564289ac6234d4476cc2b0d3ae8)
fatal: update_ref failed for ref 'featA': cannot lock ref 'featA': unable to resolve reference 'featA'

So it's doing all of the work with the correct ref, including printing the old and new SHAs, but the only failing at the final update_ref invocation.

To be consistent with git, see git-config(1).
Since this was added in #60: cc @rwe

Also thanks for this awesome tool, git revise is incredibly useful!