Here are the things every git client should have before opening up:
1) side by side comparison—seems like it only has vertical, which means for heavy changes it's basically useless.
2) conflict resolution.
3) search (it seems like gitkraken does this well from the screenshots)
4) Interactive rebasing, the bread and butter of clean git usage.
Without the above as a minimum, I might as well just use the git cli all the time. It's not worth using two git tools when the cli is already so powerful.
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>).
In particular, you really want a 3-way merge tool (which compares yours and theirs to the common ancestor) for resolving conflicts. Meld didn't used to have this, but it looks like it does now. FWIW, on OS X you can also configure git to use opendiff (which opens FileMerge). It does the job pretty well.
Source: my day job used to involve daily merging of Chromium with Rockmelt and I probably evaluated every merge tool that existed at the time.
A little off-topic: since 10.10 or so, FileMerge has started opening the bottom, free-editing pane by default—and at a random height, at that. Has anyone figured out how to disable that? It's driving me into the arms of a different, otherwise inferior diff tool.
Sure. I use kaleidoscope (or vimdiff if necessary). It's a little confusing to see git clients completely neglect this, though—how much time do you really use looking at pretty commit graphs as opposed to actually working with code?
1) side by side comparison—seems like it only has vertical, which means for heavy changes it's basically useless.
2) conflict resolution.
3) search (it seems like gitkraken does this well from the screenshots)
4) Interactive rebasing, the bread and butter of clean git usage.
Without the above as a minimum, I might as well just use the git cli all the time. It's not worth using two git tools when the cli is already so powerful.