mitmaro / git-interactive-rebase-tool Goto Github PK

I screwed up in the last release and forgot to bump the version number in main.rs. It should be easy enough to get the version number from the CARGO_PKG_VERSION environment variable instead.

I get the following when I try to run interactive-rebase-tool either directly or using git rebase -i origin/master

dyld: Library not loaded: /usr/local/opt/[email protected]/lib/libssl.1.1.dylib
Referenced from: /Users/david/bin/interactive-rebase-tool
Reason: image not found
Abort trap: 6

I'm on a Mac and downloaded the executable directly from
https://github.com/MitMaro/git-interactive-rebase-tool/releases/download/0.7.0/macos-interactive-rebase-tool and then used mv ~/Downloads/macos-interactive-rebase-tool ~/bin/interactive-rebase-tool and chmod 755 ~/bin/interactive-rebase-tool.

I've reverted to the 0.6 version which does work.

Also I really like this tool.

This may be more personal preference, but I find that once I've picked an action for a commit (say squash), I almost always want to go down to the next one and select an action for it. Autoselecting the next item may be a better default?

The code is currently in a single file. Break the code into several modules to better support testing and refactoring.

At least in my case, there's often a bunch of unused screen real estate, and displaying the help menu (or changing the display of the Actions: bar at the bottom) would be nice. Sort of like WordStar

Manual testing is a real pain, and I don't want to do it. Add some automated tests once #20 is done. Also look into adding some end-to-end tests with a bash script.

1. cargo calls it git-interactive-rebase-tool.
2. The usage refers to git-interactive
3. And the README.md has just `interactive-rebase-tool

and depending on which name is actually used there are different git configure commands in the README.md

I think it would be good to settle on one uniq name for the program and use this across all OSes.

I cloned the project to try and play around with it. Usually the first thing I do in any project is run the autoformatter. Doing that, I noticed that this project appears to use hard tabs, and adding a .rustfmt.toml with the line hard_tabs = true may be useful.

Would it be feasible to have exceptional package built for older Debian-based releases like Ubuntu 14.04 trusty? I've got a bunch of legacy setups where I'd like to use this tool but cannot upgrade to newer Ubuntu release =( If I got things right it's only about versions of dependencies not the tool itself.

Thanks in advance.

I am continuously copying/pasting a commit into another terminal window to run git show on it. Would be nice to be able to display the same information within the tool.

I have trouble reading white-on-black text, so I use the following iTerm2 configuration:

After the fix from #66 what used to be printed as black-on-white (my default foreground/background combination) now looks like ANSI-white-on-white:

If I change IRB to use the color pair 0 for foreground_color (PR upcoming), it looks fine again:

With rebase.abbreviateCommands I think the tool will do something bad.

I installed this via cargo install --git and when I run it with the --help flag, I get:

Error opening file, -h
Reason: entity not found

A comment on HackerNews mentioned putting the supported Git versions in the README.

i'm trying to drop 30k commits in a rebase ( gh-pages branch )… would be nice if i could (1) exit out to my usual editor, or even (2) run a command on the todo file, something like this:

• i hit !
• i see a prompt: Execute command on todofile: with the default: ( assuming VISUAL=emacs)

$ emacs .git/rebase-merge/git-rebase-todo

• if i hit Enter it will sublaunch emacs ./git/rebase-merge/git-rebase-todo and edit the file
• when editor exits, interactive-rebase-tool re-reads git-rebase-todo and shows it onscreen
• proceed with the session

one could run sed or something against the file.

The help text is currently missing a keybinding for visual mode.

See also:

For example:

16:06:55 project (some-branch>) $ git rebase -i HEAD some-branch
thread 'main' panicked at 'Invalid line noop', src/main.rs:121
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Could not execute editor

Right now only Debian derivatives are supported, it would be nice to have an SDKMAN package to easily support all Linux versions.

For more information about creating a package see: https://sdkman.io/vendors

(Btw, running Fedora I tried using Homebrew but that gave all kinds of problems besides Homebrew downloading and installing half the internet)

After downloading 0.6.0 version for macos I tried:

$ interactive-rebase-tool --help
Error opening file, --help

$ interactive-rebase-tool
Must provide a filepath.

Usage: git-interactive <filepath>

$ interactive-rebase-tool --version
v0.5.0

Which means that basically no single invocation returned expected response. First didn't recognise the --help switch even if the switch is listed in README.md. Second shows incorrect tool name (git-interactive instead of interactive-rebase-tool as it is supposed to be called, according to README.md. Eventually the last one says that my version is 0.5.0 even if I explicitly downloaded it from the 0.6.0 release section.

Currently only the v key can be used to exit from visual mode, but the ESC key should also work.

After tool usage if you scroll up in iTerm 2 you'll see screen 'snapshots' for each action

Just in case here is settings regarding scrollback buffer:

v0.6.0 mac.

Using a step suggested by the node-core-utils nodejs/node-core-utils#237 (comment) for landing Node.js commits I ran:

$ git rebase upstream/master -i -x "git node land --amend"
Error reading file, /Users/srl/src/node/.git/rebase-merge/git-rebase-todo
Reason: Invalid action: exec
Could not execute editor

It's not a bug with git-node because I got the same result with:

$ git rebase -i b -x /bin/date
Error reading file, /tmp/foo/.git/rebase-merge/git-rebase-todo
Reason: Invalid line: exec /bin/date
Could not execute editor

man git-rebase says:

   -x <cmd>, --exec <cmd>
       Append "exec <cmd>" after each line creating a commit in the final history. <cmd> will be interpreted as one or more
       shell commands.

       You may execute several commands by either using one instance of --exec with several commands:

           git rebase -i --exec "cmd1 && cmd2 && ..."

       or by giving more than one --exec:

           git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

       If --autosquash is used, "exec" lines will not be appended for the intermediate commits, and will only appear at the end
       of each squash/fixup series.

       This uses the --interactive machinery internally, but it can be run without an explicit --interactive.

Sounds like the exec action needs to be supported by the editor.

Git supports a git rebase todo file that handles merges that occur during rebase. For example:

$ git rebase @~3 -i -r
label onto

# Branch MitMaro/tim/use-try-from
reset onto
pick 08d9e70 Use TryFrom trait now that it is stable
label MitMaro/tim/use-try-from

# Branch MitMaro/tim/basic-break-support
reset onto
merge -C 88cdea0 MitMaro/tim/use-try-from # Merge pull request #104 from MitMaro/tim/use-try-from
label branch-point
pick ac02006 Add basic support for the break instruction
label MitMaro/tim/basic-break-support

reset branch-point # Merge pull request #104 from MitMaro/tim/use-try-from
merge -C c9a6c7f MitMaro/tim/basic-break-support # Merge pull request #105 from MitMaro/tim/basic-break-support
pick 3a46420 Add full support for the break action

# Rebase 371df63..3a46420 onto 371df63 (12 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

There was a note made in #36 that a note should be added to the README on why this project is different from others similar such as sjurba/rebase-editor.

Two things come to mind immediately, this runs natively not requiring a runtime such as nodejs and second it should work within git bash.

It would be nice if, in addition to the commit information, the commit's diff/patch were shown.

In #62 there was a request by @srl295 to include the command name before the error output to make it clear where the error message is coming from. This is a great idea and shoudn't be too bad to implement.

If the console window shrinks below 4 lines the program crashes.

For example, in the following gif, I want to be able to press and hold r and use my arrow keys to select a range of commits. I think that'd be neat.

This variable is not mentioned in the git manpage (that I could find), but one can temporarily override the editor with something like:

env GIT_SEQUENCE_EDITOR=emacs git rebase -i

Used this to work around #62

Now that #33 is complete, the install instructions should be updated to install via homebrew.

Git 2.20 has been released with a new break command that can be inserted between list items:

* "git rebase -i" learned a new [instruction], 'break', that the user can
  insert in the to-do list.  Upon hitting it, the command returns
  control back to the user.

— git/Documentation/RelNotes/2.20.0.txt

The asset target/release/git-interactive-tool should be renamed to target/release/git-interactive-rebase-tool

(I'm not sure where this option would go right since there's no config yet.)

It'd be neat if there was an option to have references to commits in the commit messages rewritten when successfully rebased. For example, let's say we have the following commits:

commit 7567b3365d2c2f18379b8305a174c99bc9f634dc (HEAD -> master)
Date:   Sat Sep 8 21:00:25 2018 -0230

    3rd
    
    Refs bcc2868

commit bcc2868f126a0392576c5ac4d4612d7d069444c9
Date:   Sat Sep 8 21:00:03 2018 -0230

    2nd

commit 9aff63810b6b22fa7fc8825791b2491d4e750a88
Date:   Sat Sep 8 20:59:57 2018 -0230

    1st

When I rebase the 2nd and 3rd commits it would be useful if the 3rd commit's message could automagically have its reference to bcc2868 updated to the new hash of the 2nd commit.

While exec actions are supported, their command cannot be modified. Let's fix that!

The macOS build isn't building the correct binary, as it seems I'm building the mac-os version on Linux instead of macOS.

Thanks @jackharrhy for testing this for me.

A new release is ready to go and needs to be properly released.

A few tasks that are required to get the release finished:

• Test on Windows
• Test on MacOS
• Test on Linux
• Update CHANGELOG
• Bump Cargo.toml version number
• Tag new release
• Release to Cargo
• Release to Homebrew
• Release to FreeBSD
• Verify release complete

Would display basic usage of the tool. Could have similar output to the manpage.

I installed this on macos 10.13 and ubuntu 18.04 via cargo install --git (to get the latest version possible) and set this to be my sequence editor with git config --global sequence.editor interactive-rebase-tool . I get this error when I try to rebase:

Error reading file, (...)/.git/rebase-merge/git-rebase-todo
Reason: Invalid action: %
Could not execute editor

Changing the binary name from git-interactive-rebase-tool to interactive-rebase-tool didn't help.

It's nice to be able to diff your current tree from what you're rebasing against, and a keybinding like v (for view) to run git diff would be helpful.

The left handside blue on black letters are hard to read:

PS As a side note:

1. Also, to me as a rebase beginner (and I think that especially beginners might benefit from a great interactive tool like this) it was not clear that w / W means save and proceed. Not sure, but when using the node based rebase-editor I think it was clearer what each command / letter would do. Also, Immediately write/abort sounded to me like a really strong action, where it just seems to mean that the "Do you really want to ..." question is overstepped.

Thanks for the nice tool.

I got confused by .deb release for v0.4.0 whose filename is git-interactive-rebase-tool_0.3.0_amd64.deb (the same as for the v0.3.0).

The binary itself does neither support the --version command-line option nor seem to tell its version somewhere else.

So after having downloaded a file git-interactive-rebase-tool_0.3.0_amd64.deb its not clear which version it actually is, both before and after installation.

I suggest to provide the common --version option and, if possible, correct the .deb filename of the v0.4.0 release retroactively.

When in visual mode you need to exit visual mode to save the TODO file and finish the rebase. There is no reason why from visual mode you shoudn't be able to finish a rebase.

I work at a Windows shop. Is Windows supported and are there installation packages? I know that ripgrep and fd have Windows executables as part of their CI builds.

Maybe relevant: The Windows issue of rebase-editor for this: sjurba/rebase-editor#7 Which is what I use atm with the mentioned workaround.

When I run the tool, I notice that there are tildes on the left margin like in vim. This is very much an aesthetic thing, but ever since vim let me remove those tildes, I've pursued their eradication in any program I use. They seem to be drawn in view.rs on line 250.

In the case of this tool, I don't see the benefit to them since they add visual clutter and don't help you find your current line since there's a little pointer for that already.