
Show HN: Komet – Native commit editor for macOS - zZorgz
https://github.com/zorgiepoo/Komet
======
andruby
Do you know GitX? It's perfect for quick git commits with line-by-line staging
and unstaging.

[0] Up to date fork:
[https://rowanj.github.io/gitx/](https://rowanj.github.io/gitx/) [1] Original:
[http://gitx.frim.nl/](http://gitx.frim.nl/)

~~~
okket
Last commit: "Nov 10, 2014"
[https://github.com/rowanj/gitx/commits/master](https://github.com/rowanj/gitx/commits/master)

------
OJFord

        > Not being stuck in a save-and-close model, applying a
        > commit takes only one action
    

Uh... `:wq`?

~~~
zZorgz
"<escape> colon w q <return>" is _too_ many 'actions' for me personally (and
anything that needs me to reach to escape is really asking for it), and I
sometimes even mess that combination up (I used vim before using Komet). I
learned about :x recently which is only just slightly better, but not in my
muscle memory yet. Then one may need to decide when to use q! or cq to
discard..

I also prefer using a native editor and am more productive with spell checking
and auto correction, surprisingly.

edit: I'm also not a user that uses the keyboard _all_ the time. After using
Komet, I am surprised how often I actually used the mouse to hit commit
instead.

~~~
OskarS
I use Vim for regular development and has mapped <Space> to colon in normal
mode, so for me it feels very much like a single action to just tap those
three keys in quick succession with different fingers on one hand then tapping
<Enter> with the other hand. It's like executing a fighting-game combo, the
muscle memory makes it feel like a single action even though you're hitting
several keys.

But it's arguably true that Vim is the wrong choice as the default commit
editor since the majority of users probably will not feel very comfortable in
that environment. In hindsight, nano would probably have been the better
choice for default.

However, since I'm already a heavy Vim user (and have the vim-fugitive plugin
installed), I would never go for anything else.

~~~
zZorgz
I have invoked '<escape>:wq<return>' many times; it should be in my muscle
memory but it's still something I get wrong on occasion. I can definitely see
<space> being better than colon (it gets rid of shift!), although I still have
beef with escape. I don't want to play the fighting game :).

What about canceling commits? Sometimes you want to quit without saving, and
other times you want to exit with a failure status (which has little
application elsewhere). A "commit" editor should be smart enough to decide
which to do under a single action.

I acknowledge this isn't intended for those heavily invested in their CLI
editor of choice.

~~~
ibizaman
Btw you can cancel a commit if when issuing :wq the whole file is only
composed of either blank lines or lines beginning with #

~~~
zZorgz
Sure, but why would one remember that if they could just do :q! regardless if
there's new unsaved content or not.

Relatedly, why would one remember to do :q! or :cq depending on if there's
pre-existing content if they can just cancel in Komet and have it do the right
thing ;)

~~~
OJFord

        >  they can just cancel in Komet
    

What is `:q!` if not "just cancel[ling]"?

I'll take four keystrokes over <move hand to mouse>, <move mouse to button>,
<click button> (and a debatable <move hand back to keyboard>). Even if you
count that as 3v4, the keystrokes are quicker than the mouse movements.

I get that not everyone wants to deal with vim, and may use a GUI editor for
other stuff - but for something as small and specific as git commits, I really
don't understand why you'd want to install something new; for what, a button?

~~~
zZorgz
:q! quits without saving the text file which only aborts a commit if the
message is empty, meaning it's not sufficient if the message has pre-existing
content when you open it.

And you largely misunderstood. Komet has a shortcut for making the commit
(command return). The mouse is just a supplemental possibility....

Having a more convenient shortcut is not the only reason I use Komet.

[edit]: and to address for "something as small as commits" \-- well, I write
commits pretty often. So it matters a great deal to me to have an aiding tool,
and definitely not for a task I'd consider 'insignificant'

------
stephenr
Isn't "macOS 10.10" an incorrect name? It's OS X up to 10.11, and then macOS
from 10.12 onwards.

Regardless, this app is quite nice.

~~~
aaronbrethorst
You're absolutely right, but I think that saying "requires OS X 10.10 - macOS
10.12," or "requires OS X 10.10 - 10.11, or macOS 10.12 or higher" sound
weird.

~~~
stephenr
I would simply say "requires OS X 10.10 or later"

~~~
zZorgz
Apple docs have references to eg: "macOS 10.8+" regarding SDK version. This
may still be up in the air, but I predict it will be natural eventually to
just use macOS everywhere.

~~~
stephenr
Wow really? I've never seen that in user facing information (eg they kept
using "Mac OS X" for older versions when they dropped the "Mac" a few years
ago

~~~
zZorgz
I was referring to technical developer documentation, but I don't think user
facing info will be that much revealing until after 10.12 is released.

I say that I predict using macOS will be "natural", although that doesn't
necessarily mean it'll be "technically correct" for older versions.

------
the_mitsuhiko
Not sure how that is better than rendering the editor in the terminal. It's
not like you can use that terminal for anything else anyways because it's now
waiting for that GUI editor to close.

~~~
zZorgz
On the contrary, I've found keeping the terminal history visible while making
commits to be a useful reference.

------
jbb555
Doesn't macos have vim then?

------
maksymddd
What don't just use GitKraken?

------
dsego
editor = subl -n -w

~~~
zZorgz
Tried this before making Komet but from what I tested I found this to be slow
(stuck in save-and-close model) and obstructive (can bring other sublime
documents active).

