Show HN: 'rebaser' improves on 'git rebase -i' | Hacker News Reader

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

gist.github.com

66 pointskoreno20 comments

'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.

What does clashing column mean?

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.

Potentially clash; the commits may touch completely different parts of the same file without conflict.

True that!

My original idea was to somehow show the actual conflicts, but then I figured this gets the desired 80% for 2% of the effort...

This is the main prize. Using emacs + magit I can rebase and look at per commit files whilst having a buffer open to re-order commits.

In fact magit could probably do some of this with a hook on reordering commits which would not require more git metadata.

I'm not sure I care about any of this though as if I do rebase, reorder and then hit a conflict I can't resolve I can always abort the rebase.

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!

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

It... it does?

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

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

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.

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.

You are running that in shell by hand. The python program running here is not shell. If you do a print(os.environ["GIT_EDITOR"]) in the python3 program you'll still see ~/bin/vim .

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

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'.

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

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

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

Actually, there was a bug there, but now it's fixed.

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

Reply on news.ycombinator.com