Show HN: Komet – Native commit editor for macOS | Hacker News Reader

Show HN: Komet – Native commit editor for macOS

github.com

32 pointszZorgz31 comments

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/ [1] Original: http://gitx.frim.nl/

Last commit: "Nov 10, 2014" https://github.com/rowanj/gitx/commits/master

Haven't really checked it out but if it's like git GUI, then it's probably too heavy weight to my liking to use on a daily basis.

(personal nitpick: I'd love if the app showed me how to use it rather than having to consult to online instructions)

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

Uh... `:wq`?

`:x` may be useful, if "save-and-close" is a problem.

Or normal mode ZZ

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

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.

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.

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

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 ;)

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

: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'

On xubuntu the default for git is nano, or it was for me at least.

"ZQ" to quit without saving, "ZZ" to save and quit. In normal mode ,if course.

Not currently in my muscle memory but this does interest me since I use vim sometimes for other ocassions. I'd prefer if shift wasn't necessary though... so I'm not sure I'll commit to this :).

Still, these are worse than Mac shortcuts that Komet uses IMO, and I dislike escape (and control to a lesser extent) :-).

Also you sometimes want to quit with an exit failure status on canceling, and why have two different operations for that when your editor is smart enough to have one.

Arguably having to use a mouse is too much action, because you have to move away from the keyboard, unless there are undocumented keyboard shortcuts.

Yes, very arguable :). Komet has keyboard shortcuts. I don't mention them on GitHub because they're shown and I believe natural to figure out after opening the app.

I spend a lot of time on my computer not having at least one of my hands on the keyboard. Say I'm about done writing a commit message but I get a message on my phone I want to quickly check. It may be more convenient for me to use the mouse to hit commit later and then do some browsing tasks, or so. The other day I was doing some refactoring work while eating food in my other hand..

Nonetheless I believe having the option to use the mouse is better than not being able to.

`echo "set mouse=a" >> ~/.vimrc` ?

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.

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.

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

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.

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

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.

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.

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

Doesn't macos have vim then?

What don't just use GitKraken?

editor = subl -n -w

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

Reply on news.ycombinator.com