Hi, author of git-cola[1] here, and I completely agree that these features are key. I have a slightly different philosophy implementation-wise, though.
Maybe I'm a unix crank, but I've always tried to keep cola as more of a mediator over individual best-of-breed tools, whenever it made the most sense, rather than re-implementing things that already exist in better forms elsewhere.
For diffs we show inline diffs for interactive staging, one of our uniquely ergonomic features, while also making it extremely easy to launch `git difftool`. difftool itself can be configured to use the best tools for side-by-side diffing, so integrating tightly with it makes for the most cohesive Git experience.
For conflict resolution we defer to `git mergetool`, for the same reason.
With `git cola rebase` it's really easy to reorder lines in a rebase and swap through the pick/squash/fixup/... options using keyboard shortcuts. The advantage is you can't mess up the instruction sheet like you can when using $EDITOR -- cola ensures that the instruction sheet is semantically valid (e.g. "pick" must be first) and does not allow the user to create an invalid instruction sheet. Those little things make a big difference for usability.
What you didn't mention, though is one of the most important aspects to me: A Keyboard-Centric Design
I am a heavy vim/gvim user. I use the keyboard for everything, so cola is designed to augment the command-line experience. If you want to find some string in your codebase run:
$ git cola grep foo # or ctrl-g foo in cola
# hit enter
# navigate results using vim-style hjkl keys
# hit enter
# you are now in foo_bar.c at that exact line of code,
# in your favorite $EDITOR
Being able to do the most common operations, without touching a mouse, is one of my guiding design goals. Hopefully I'm not the only one that feels this way.
Hey! Love git-cola, and I'll hijack the thread here for a quick question. Maybe I am missing something but I didn't see anyway to easily mark which commits I want to rebase in the UI.
For example, in the command line I would have to open a git log and then see that I want to do something like git rebase HEAD~3, or any of the more complicated parameters needed for rebase (such as git rebase --onto <master> <next> <topic>).
Maybe I'm a unix crank, but I've always tried to keep cola as more of a mediator over individual best-of-breed tools, whenever it made the most sense, rather than re-implementing things that already exist in better forms elsewhere.
For diffs we show inline diffs for interactive staging, one of our uniquely ergonomic features, while also making it extremely easy to launch `git difftool`. difftool itself can be configured to use the best tools for side-by-side diffing, so integrating tightly with it makes for the most cohesive Git experience.
For conflict resolution we defer to `git mergetool`, for the same reason.
With `git cola rebase` it's really easy to reorder lines in a rebase and swap through the pick/squash/fixup/... options using keyboard shortcuts. The advantage is you can't mess up the instruction sheet like you can when using $EDITOR -- cola ensures that the instruction sheet is semantically valid (e.g. "pick" must be first) and does not allow the user to create an invalid instruction sheet. Those little things make a big difference for usability.
What you didn't mention, though is one of the most important aspects to me: A Keyboard-Centric Design
I am a heavy vim/gvim user. I use the keyboard for everything, so cola is designed to augment the command-line experience. If you want to find some string in your codebase run:
Being able to do the most common operations, without touching a mouse, is one of my guiding design goals. Hopefully I'm not the only one that feels this way.[1] https://github.com/git-cola/git-cola