
Show HN: 'rebaser' improves on 'git rebase -i' - koreno
https://gist.github.com/koreno/5893d2d969ccb6b8341d
======
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.

~~~
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".

------
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](https://github.com/michaelblume/clojure)
and rebase against b8607d5870

~~~
junkblocker
See my quick python2 edit at
[https://gist.github.com/junkblocker/c4b7f2417e62f0893021](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
At the request of some users, this is now a proper github project:
[https://github.com/koreno/prebase](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'.

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

------
junkblocker
Quick python2 conversion:
[https://gist.github.com/junkblocker/c4b7f2417e62f0893021](https://gist.github.com/junkblocker/c4b7f2417e62f0893021)

