HN Explorer

20 comments

[ 0.18 ms ] story [ 50.6 ms ] thread
koreno
'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
What does clashing column mean?
Zikes
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.
pimlottc
Potentially clash; the commits may touch completely different parts of the same file without conflict.
koreno
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...

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

fit2rule
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
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
It... it does?

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

richardwhiuk
Surely this starts to fail if a series of commits hits more than 26 files, which is inevitable in a large codebase?
andrewla
Technically, 10 + 26 + 26 = 62 files, since it uses string.ascii_letters and chains on digits.
koreno
The characters cycle (wrap-around), but since you have the columns intact that shouldn't be an issue... :)
koreno
Actually, there was a bug there, but now it's fixed.
MBlume
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

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

junkblocker
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 .
koreno
couldn't find that specific commit for some reason... But I found the bug (indeed too many files, but I coped with it earlier...)
koreno
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'.