Show HN: 'rebaser' improves on 'git rebase -i'

https://gist.github.com/koreno/5893d2d969ccb6b8341d

by koreno • 11 years ago

66 20 11 years ago

gist.github.com

koreno6• 11 years ago

'rebaser' improves on 'git rebase -i' by adding information per commit regarding which files it touched.

Each file gets an alpha-numeric character at a particular column, a list of which appears below the commit list.

Commits can be moved up and down safely (no conflicts) as long as they don't have any clashing columns.

dhruvbird• 11 years ago

What does clashing column mean?

Zikes• 11 years ago

Two commits touching the same file, represented by the identifier at the end of the rebase's commit line. If you look at each file as a column, you can see which commits would clash.

fit2rule• 11 years ago

This is beautiful, and goes a long way towards making rebase more intuitive and useful .. I feel that there is so much power in Git (and other tools) that would be unleashed if only someone put a little more thought into the text user interface .. just seeing the columns on the right immediately explained to me what is going on, and I find this incredibly useful. Thanks!

nailer• 11 years ago

True, and there's nothing stopping that power also being exposed in the graphical user interface. Sourcetree in particular has an excellent rebase UI.

blakeyrat• 11 years ago

It... it does?

I think we have very different definitions of the word "excellent". I'd call SourceTree's UI "barely adequate".

richardwhiuk• 11 years ago

Surely this starts to fail if a series of commits hits more than 26 files, which is inevitable in a large codebase?

andrewla• 11 years ago

Technically, 10 + 26 + 26 = 62 files, since it uses string.ascii_letters and chains on digits.

koreno6• 11 years ago

The characters cycle (wrap-around), but since you have the columns intact that shouldn't be an issue... :)

MBlume• 11 years ago

This is an awesome hack, thanks =)

When I tried rebasing my Clojure fork against upstream I got

Traceback (most recent call last): File "/Users/michael.blume/bin/git-rebaser", line 96, in <module> write_todo(file, first, last, comments) File "/Users/michael.blume/bin/git-rebaser", line 61, in write_todo f = "[%s] %s" % (SYM[i], f) KeyError: 62 Could not execute editor

I'm guessing this is a case of the commits touching too many files?

To reproduce, check out master at https://github.com/michaelblume/clojure and rebase against b8607d5870

junkblocker3• 11 years ago

See my quick python2 edit at https://gist.github.com/junkblocker/c4b7f2417e62f0893021 . It needed os.path.expanduser(...) since my editor was set to ~/bin/vim and ~ is only expanded by shell without that.

wnoise• 11 years ago

Shouldn't it be expanded by the shell when it is first set?

FOO=~/bin/vim export FOO env | grep FOO shows it as expanded.

koreno6• 11 years ago

couldn't find that specific commit for some reason... But I found the bug (indeed too many files, but I coped with it earlier...)

junkblocker3• 11 years ago

Quick python2 conversion: https://gist.github.com/junkblocker/c4b7f2417e62f0893021

koreno6• 11 years ago

At the request of some users, this is now a proper github project: https://github.com/koreno/prebase

I also renamed it 'git-prebase' so that it's easily added to git's autocomplete behavior and does not interfere with 'rebase'.

Show HN: 'rebaser' improves on 'git rebase -i'

Related Stories