Show HN: Rebase-editor, a simple CLI app specifically for Git interactive rebase

by sjurba • 9 years ago

62 34 9 years ago

eridius4• 9 years ago

Cute, but I can do the exact same thing in Vim. It has built-in commands :Pick, :Reword etc that change the current line, and I've just defined my own ftplugin/gitrebase.vim file that looks like:

  nnoremap <buffer> <silent> <LocalLeader>p :Pick<CR>
  nnoremap <buffer> <silent> <LocalLeader>s :Squash<CR>
  nnoremap <buffer> <silent> <LocalLeader>e :Edit<CR>
  nnoremap <buffer> <silent> <LocalLeader>r :Reword<CR>
  nnoremap <buffer> <silent> <LocalLeader>f :Fixup<CR>
  nnoremap <buffer> <silent> <LocalLeader>c :Cycle<CR>

This way I just press e.g. "\p" or "\f" (my localleader is \) to change the line, which makes it just one more keypress than your command, but I have the full power of Vim and I don't have to go about changing my editor.

saurik• 9 years ago

So this is just "change the word at the beginning of the line to squash"? All of the commands can be replaced by one-character aliases, so I just use "cws<esc>" to like, "change to squash". What is proving these (much longer and less general) commands like ":Squash<enter>"?

tekknolagi• 9 years ago

You know, I have these too and I'm not sure. I can't find "Squash" or "Fixup" in my vim init directory. And yet, when I `vim -u NONE`, they don't exist...

eridius4• 9 years ago

Sure, you could do that, but if you're going down the list making changes to 12 lines, it's much easier just to say something like \fj\ejj\sj\sj\fjjj\e instead of ciwfixup<esc>jciwedit<esc>jjciwsquash<esc>jciwsquash<esc>jciwfixup<esc>jjjciwedit<esc>

csswizardry• 9 years ago

sjurba8• 9 years ago

Awesome. I know Vim is super awesome, flexible and very configurable (like emacs). I guess I never got around to learning it properly.. If you compare the time I spent writing this app to the time I would spend configuring and learning Vim, it might make me feel a bit stupid.. But then again, because of github and npm it is so easy to share the work I done, so that so many others don't have to spend that time at all.

Also I tried to make this app to have it do only one thing and do that one thing well. With no config, and no learning how to use it. Arrows to find your line, custom keys to change the action-word. Shift to select multiple lines, Ctrl to move/reorder line(s) and some extra niceties like undo/redo. Of course you can do all that and much more with vim. My point is that it is a strength of the app that it doesn't do anything else. I don't need it to do anything else. It only needs to do interactive rebase.

But of course I don't expect vim and emacs aficionados to take much interest in this app. My core audience are those who have to google 'how to exit vim' every time they venture a rebase. ;)

eridius4• 9 years ago

The time you spent writing this app is probably good experience for writing other things though. And of course someone who's using nano or pico as their editor might find this useful.

anaganisk• 9 years ago

Not everyone is a vim user.

sixstringtheory• 9 years ago

One tip when rebasing in vim, you can execute commands in the session. I use sed to replace picks with other commands:

:%s/pick/squash/gc

Also, I've gotten used to using git commit --fixup with git rebase --autosquash, so I rarely need to interactively rebase these days.

amluto• 9 years ago

What a strange world we live in that that a terminal app would be written in Node.js.

cadillackness• 9 years ago

I'd rather have people write Free software in JS than not write any at all.

zem• 9 years ago

isn't that what it's there for? node lets you use javascript just like any other scripting language; you wouldn't have blinked at this being done in perl or ruby

sjurba8• 9 years ago

Yupp. I agree. And writing something cross platform for the terminal kinda sux. I have given some thought to porting it to something else, but am not sure what that would be. Any suggestions? Requirements: a nice language to work with, cross platform, easy to install the executable(s)

anonfunction2• 9 years ago

You should give Golang a shot. It checks all your requirements.

microcolonel• 9 years ago

Cool, but I think it's better if it's in your text editor. In Emacs I use Magit, it is spectacular.

alphapapa• 9 years ago

Yep, looking at the screencast, Magit does exactly what this tool does, except much better.

sjurba8• 9 years ago

Yes, I respect that. I guess I wrote this app for the people who don't use Emacs and/or Vim on a regular basis, but still enjoy using git on the command line, like my self... I might have to check out magit though to see if there are some ideas I could steal. :) Any functionality/workflow in particular that works better with magit?

kaushalmodi• 9 years ago

Even if you don't use Emacs regularly, using Magit just for git operations might be worth it. Just have an Emacs config ready with Magit installed and use that as your "git user interface".

Every git operation I've done is effortless with Magit: interactive rebase, selective staging (line based, not just hunk based), cherry picking, reordering commits and squashing, creating/pushing to/deleting local/remote branches, viewing graphical branch log, .. (list goes on).

lumpypua• 9 years ago

I've seen people use rebase like a patch queue a few times, and it always comes off as awkward and painful. This app seems to make that pattern of use a little less painful -- but patch queues are better. I wish more people knew about them as a source control tool.

mercurial queues - far and away the my favorite patch queue implementation - https://developer.mozilla.org/en-US/docs/Mozilla/Mercurial/Q...

stacked git - a solid git patch queue - http://procode.org/stgit/doc/tutorial.html

deathanatos• 9 years ago

Out of curiosity, what about interactive rebases do you find awkward/painful? Or asked differently, what about hg's patch queues make them better?

Reading the linked documentation for patch queues, it isn't clear to me how they materially differ from git's interactive rebase. (Modulo hg's mutable/immutable differences.)

kazinator2• 9 years ago

The author of this is not making use of

  git commit --squash <sha>
  git commit --fixup <sha>
  git rebase -i --autosquash ...

Autosquash puts things in the right order.

Of course, you have to pick the target commit at the fixup commit time. But that is less error-prone then later trying to remember what such and such commit was intended to combine with.

ollysb• 9 years ago

Saw this just last week

    $ git config --global rebase.autosquash true

kazinator2• 9 years ago

How long has that been a feature, darn!

sjurba8• 9 years ago

Well, autosquash is great, and you are right that I don't really make use of it much, but I will now that I'm aware of how nice it is.

That being said, my tool will work nicely with autosquash. All 'fixup!' commits will be reordered and prefixed with fixup just like with the default editor. So you might say that you don't need my tool since autosquash is all you need, but I often use it to do manual reordering, editing and rewording. And in those cases I find it very useful.

mjbrownie• 9 years ago

Cool. I also wrote a vim plugin to do stuff like cycling between keywords. There is already a gitrebase filetype to hook it to as well.

https://github.com/mjbrownie/swapit

mosselman• 9 years ago

As it has been said a lot: you can use vim or whatever editor to do this just as easily for the amount of time this would save you.

How many times per day are you actually rebasing interactively? I myself might do it once per week and that in a project with 6 developers with a fairly strict commmit policy. I can only imagine having a job where doing interactive rebases is the only thing you do before you get a return of investment on a. building the tool (you) and b. learning how to use it (others).

You could probably have learned to use vim in the time it took you to build this, at least the basics. You could also start learning about vim by enabling vim-mode in your editor. Most editors have one at least.

sjurba8• 9 years ago

For me, I agree. I could easily learn vim in the time I wrote this. For others, I disagree. The time to learn my app is 0. Nothing to look up or check. The available keys are right there in front of you. And since they are what you would intuitively expect, you won't forget them. Up and down, shift to select, ctrl to move. f to fixup, s to squash, etc. If you are a avid vim user, yes. You don't need this tool (although it will still save you a few keystrokes), but if you are like most developers who struggles to remember how to exit vim, then you will love this app.

Vim is awesome and my app could never do a fraction of the stuff vim does. But my app can do interactive rebase. And since it is the only thing my app can do, it does it better then vim.

sjurba8• 9 years ago

And btw. since writing this app I started committing more often and using interactive rebase a lot more because it become so easy. I would say I use it almost daily.

rurban• 9 years ago

Nice, magit for dummies. But note that the rebase commands are only the start of your problems. Much more important is the conflict resolution step, which is easily doable in magit, but hard with this one. You need the list, where you are, keybindings to get ours or theirs or to jump to the conflict. A Three-way diff editor hook.

sjurba8• 9 years ago

Yupp. It's not a complete git gui. Its only used to work on the rebase sequence. Once you finish editing that, git takes over again. You need to use other tools to sort your conflicts, etc. But if you are working on the command line its very nice.

warpech• 9 years ago

Interesting! We maintain some coding tutorials and use Git interactive rebase to match the commit history to the tutorial steps:

Text: https://docs.starcounter.io/tutorial/

Code: https://github.com/StarcounterApps/HelloWorld/commits/tutori...

Interactive rebase instructions: https://github.com/StarcounterApps/HelloWorld/wiki

Show HN: Rebase-editor, a simple CLI app specifically for Git interactive rebase

Related Stories