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:
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.
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>"?
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...
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>
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. ;)
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.
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
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)
Cross compiling is very easy since Go 1.5, just add some environment variables before running `go build`, which can be put in a Makefile.
Distribution is a little trickier since there is no package manager ala npm, however it's a little easier in that you don't need anything except for the binary. For people who have Go installed they just `go get REPO` and it's installed, for others they can just wget the binary into their bin.
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?
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).
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.
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.)
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.
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.
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.
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.
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.
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.
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.
36 comments
[ 3.5 ms ] story [ 92.7 ms ] threadAlso 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. ;)
:%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.
Distribution is a little trickier since there is no package manager ala npm, however it's a little easier in that you don't need anything except for the binary. For people who have Go installed they just `go get REPO` and it's installed, for others they can just wget the binary into their bin.
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).
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
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.)
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.
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.
https://github.com/mjbrownie/swapit
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.
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.
Text: https://docs.starcounter.io/tutorial/
Code: https://github.com/StarcounterApps/HelloWorld/commits/tutori...
Interactive rebase instructions: https://github.com/StarcounterApps/HelloWorld/wiki