#107 feature
Florian Witteler

Feature request: keyboard-shortcuts for usual committing

Reported by Florian Witteler | February 25th, 2009 @ 10:14 AM

I'd really like to see gitx have shortcuts for the usual commit-tasks like

Command-A: select all files Command-S: stage the selected files (move cursor to the message field) Command-Option-C: commit the change.

Any comments on this one? I really like to use gitx for the 'usual' tasks, which is commonly just committing changes to the repo. Keyboard-shortcuts make me faster in using the app.

Kind regards from Germany, Florian

Comments and changes to this ticket

  • Johannes Gilger

    Johannes Gilger February 25th, 2009 @ 01:35 PM

    While I can absolutely understand your wish (I myself only like to use the keyboard as well), I don't think that Command-C and Command-S are good choices, since they are traditionally bound to "Copy" and "Save" and might disorient users.

    So, one should think of other shortcuts. I would image a Shift-Enter in the Commit-message to commit for example.

  • Pieter de Bie

    Pieter de Bie February 25th, 2009 @ 01:43 PM

    There's already command-shift-enter to commit.

    You can do command-a in the file list to select everything, but after that you're stuck. One of the problems is that the commit message thing eats tabs (which is desirable), so you can't tab to the file lists.

    I'd suggest something like:

    • Keyboard shortcuts to give focus to staged and unstaged file lists
    • Keyboard shortcuts to do something with the selected files.. Perhaps just enter, or command-down? That's similar behaviour to the Finder I guess.
  • Florian Witteler

    Florian Witteler February 25th, 2009 @ 01:54 PM

    Hi Pieter!

    Thanks for the hint. Haven't found a menu-entry for comitting. I like the approach of giving focus to the list of staged and unstaged files. Enter or command down would be great. Command-A for selecting all files in the list, would be helpful.

  • Pieter de Bie

    Pieter de Bie February 25th, 2009 @ 03:53 PM

    That said, you probably also want a shortcut to only select already tracked files.

  • Phil Crosby

    Phil Crosby May 10th, 2009 @ 01:20 AM

    For cmd+shift+enter, is this documented anywhere? It would be great if it was more discoverable. I wrote some applescript to do this because I didn't know about this shortcut.

    Also, why did you pick cmd+shift+enter instead of cmd+enter?

  • Josh Wand

    Josh Wand May 19th, 2009 @ 07:09 AM

    +1 for cmd-enter instead of cmd+shift+enter.

    cmd+enter is used in a lot of other apps for significant but frequent 'submit' type actions (e.g. browsers, various twitter clients)

  • Pieter de Bie

    Pieter de Bie May 20th, 2009 @ 11:24 AM

    • State changed from “new” to “open”

    I chose command-shift-enter because it's similar to Mail.app's command-shift-D to send an email. I didn't want you to be able to accidentally press it, as that'd cause confusion, so that's why I chose two modifiers instead of one.

    I guess I can change it though. However, I think TextMate for instance uses control-enter for commit (in the git / svn bundles), so command-enter isn't the industry-wide default ;)

  • Nicholas Riley

    Nicholas Riley June 2nd, 2009 @ 08:08 AM

    It's confusing that the Commit button pulses, as if you could use the return key to trigger it, but it doesn't work. (I realize that Cocoa is doing this itself; this is a bug in Cocoa). A way to get around it would be to change the button style, perhaps to the "Gradient" style.

    Either the shortcut should be added to a menu, or it should be labeled right in the button.

    Also note that enter (⌤) ≠ return (↩) on the Mac. The shortcut you've assigned is command-shift-return, not enter. It is a standard for the enter key to be used when you'd otherwise use the return key, except that you've got a multiline input box. (See Apple's HI Guidelines).

    Finally, a simple way to move between unstaged/staged/commit message would be with tab and shift-tab, but this doesn't seem to work - the tab order (i.e., nextKeyView) doesn't seem to be set at all.

  • Nicholas Riley

    Nicholas Riley June 2nd, 2009 @ 08:12 AM

    (Sorry, I missed your comment about eating tabs; I don't see why that is necessary?)

    For a keyboard shortcut being used in stage/unstage, I'd suggest adding explicit "Stage"/"Unstage" buttons, which become the default (i.e., triggerable by return) when keyboard focus is in their respective lists.

    If you're too busy I can see about implementing some of these changes myself... I love GitX!

  • Pieter de Bie

    Pieter de Bie June 2nd, 2009 @ 08:33 AM

    Thanks, I'd much appreciate it. I'm fighting off RSI daily now, so I
    can't spend too much time on it anymore.

  • Nicholas Riley
  • Nicholas Riley

    Nicholas Riley June 17th, 2009 @ 06:35 AM

    Sorry, I forget that not every URL recognizer is as good as ICeCoffEE :-) Try this:

    http://github.com/nriley/gitx/commits/master

  • Johannes Gilger

    Johannes Gilger June 17th, 2009 @ 12:46 PM

    Very cool, I'll have a look at them once I'm on my Mac again. If the patches are OK Pieter might want to squash a few of them.

    The patch about the typo-fix for "revert" will probably not be needed, I sent something to the ML this morning (which has the whitespace still in, so I'll repost after I get input on the other areas of the patch).

  • Johannes Gilger

    Johannes Gilger June 17th, 2009 @ 06:14 PM

    A few words about the patches:

          Reduce font size of staged/unstaged changes lists (better for smaller screens, deeply nested paths).

    (-) Hm, it looks ok, but still, having an extra font-size makes things chaotic.
      Don't disturb insertion point/selection when inserting "Signed-off-by" line.
        (+) Good one, should be merged 
      Remove extraneous space in "Are you sure you wish to revert changes?" message.
    (0) Not necessary anymore
      Indicate in the menu which view (history or commit) is being shown; use an enum for the view constants.
    (+) OK I guess
      Set keyboard focus reasonably when switching between commit and history views.
    (+) OK too I guess
      Permit tabbing out of the commit message text view. Option-Tab still works to insert tabs.
    (-) Should be the other way around IMHO. But then again, I don't use the commit-functionality.
      Add Stage and Unstage buttons with Return key equivalents when the corresponding lists are focused. 
      Focus the last-selected files or the first file when navigating into the Unstaged/Staged Changes lists via the keyboard.
    (-) This is just a third way to do it, and I'd rather have as little buttons as possible.
    (+) OK
      Truncate the middle of pathnames in the Unstaged/Staged Changes lists, not the end.
    (+) Could be useful
      Clean up UI and add keyboard support for create branch sheet.
    (-) This patch shows the same defficiencies as the rest IMHO. There's no way to review this.</code>
    
    
    
    
    In general I think your patches go into the right direction, but are really
    hard to review since they lack proper commit messages. The last patch just
    changes the XIB, and I didn't even find out what the key-combo is. You'll have
    to describe exactly what you did in some of these non-trivial patches (and why
    you did it that way).

    Also the first line of the commit should be <= 80 characters, because it is
    the subject.

  • Nicholas Riley

    Nicholas Riley June 17th, 2009 @ 07:15 PM

     Reduce font size of staged/unstaged changes lists (better for smaller screens, deeply nested paths).
    

    (-) Hm, it looks ok, but still, having an extra font-size makes things chaotic.

    Actually it looks fine; the font size matches the font size of the labels above them anyway (as well as the Xcode project window). You can see a screenshot:

    http://farm4.static.flickr.com/3552/3634937834_8c5698a783_o.png

    In general I think your patches go into the right direction, but are really hard to review since they lack proper commit messages. The last patch just changes the XIB, and I didn't even find out what the key-combo is. You'll have to describe exactly what you did in some of these non-trivial patches (and why you did it that way).

    The branch sheet was just normalizing a half-finished UI to Mac conventions (Return for Create, Escape/Command-period for cancel); I don't think it should be terribly controversial if anyone sees what it does.

    I have made the commit messages more verbose and fixed the first lines of commit messages so they're

  • JDS

    JDS June 18th, 2009 @ 05:52 PM

    I suggest Command-1 and Command-2 for giving focus to Staged/Unstaged changes, since arrow keys with modifiers will often be bound to Spaces. I also suggest "following" a file when it is moved in entirety from one side to the other, rather than showing "No File Selected".

  • Pieter de Bie

    Pieter de Bie June 18th, 2009 @ 05:59 PM

    Command-1 and Command-2 are already used to switch between
    commit/history view, so we can't use that.

  • Nicholas Riley

    Nicholas Riley June 20th, 2009 @ 01:59 PM

    I'm somewhat confused that I've posted an implementation and people are still speaking hypothetically.

    Perhaps a binary build would help:

    http://sabi.net/temp/GitX.zip

    If you actually use GitX's commit functionality on a regular basis, please download and try it out; let me know what works and doesn't for you.

    (In particular, JDS's suggestion about "following" a file doesn't work terribly well in practice because if you want to stage a bunch of files, you have to switch back to the unstaged list for each file.)

  • Pieter de Bie

    Pieter de Bie June 21st, 2009 @ 12:22 AM

    I'm sorry I haven't had the time to look at this more thoroughly. Most of the patches look fine, though I do have a few comments I can hopefully extend on later on.

    The smaller font size is logical, as it's often too large right now. In the future I want to change the views to use trees instead; that way we can display more information vertically and clear up room for the file names. I also agree with Johannes that the decreased font makes it more chaotic.

    I don't like the tabbing thing. Adding tabs in the commit message is much more common than tabbing out of the view. You can add an option-tab / option-shift-tab to tab in or out of it, but I'd like to keep the normal tab to add tabs to the view.

    The view state thing is OK, but you shouldn't implement this in the validateMenu: thing, but rather in the method that actually switches the views.

  • Nicholas Riley

    Nicholas Riley June 21st, 2009 @ 04:06 PM

    I don't like the tabbing thing. Adding tabs in the commit message is much more common than tabbing out of the view. You can add an option-tab / option-shift-tab to tab in or out of it, but I'd like to keep the normal tab to add tabs to the view.

    Mac users expect to be able to tab between text fields and lists; this is basic application behavior. Same for using option-tab to insert a tab (or option-return to insert a return) in a text box where those keys would otherwise trigger focus changing/button pressing. I'm not doing anything nonstandard here; this behavior comes for free with Cocoa.

    In 15+ years of using VCSes I can't remember a single time I've ever written or seen a tab character in a commit message. Obviously your experience is different, but I really find your assertion hard to accept.

    The view state thing is OK, but you shouldn't implement this in the validateMenu: thing, but rather in the method that actually switches the views.

    It seemed like a better place for it, as it means it only gets updated when you pull down the menu, but I realize it may be a bit too cute/nonstandard. Will fix.

  • Pieter de Bie

    Pieter de Bie July 7th, 2009 @ 01:09 PM

    I've asked around a bit, and most programs seems to support tab in text views. I don't see why commit messages should be an exception to this, and most people I've asked seem to agree. I understand this can be a point for debate, but it's really just bikeshedding.

    I've merged most of your patches into my master branch. The exceptions are:

    f313180 Permit tabbing out of the commit message text view with Tab or Shift-T

    fb8e555 Indicate in the menu which view (history/commit) is being shown.

    I like this in general, but not the current implementation

    b6ce116 Keyboard-only support for individual file staging/committing.

    I'm not sure I like the buttons. I don't really like how they get enabeled/disabled when you move from one list or another. Do we really need buttons? People can just double-click on the files, or click on the icon to stage them. We don't need even more GUI stuff to do that. I don't mind the key shortcuts for the lists though, perhaps you can implement that without adding buttons?

    Thanks for all the other patches! They make a lot of sense now, especially with the better commit messages.

    I've put your other commits in nr/commit_fixes on my local branch, as I've rebased stuff into another order. I also had to hand-edit the xib's, so I hope all went well :)

  • Elia Schito

    Elia Schito September 8th, 2009 @ 07:54 PM

    Textmate uses alt+tab in textfields eating tabs and the following key (I think it's bound directly to the keyboard) for commit in my git bundle:
    _
    ^

    +1 for using Textmate instead of Mail as a reference since git is about programming more than mailing... :)

  • Roach

    Roach October 7th, 2009 @ 08:48 PM

    • Assigned user cleared.

    I didn't see this mentioned anywhere, but you can ctrl+a to select all then double click on a selected file to stage all selected files. I do agree that a keyboard shortcut would help (git gui uses ctrl+t to stage selected to commit)

  • Ralf Ebert

    Ralf Ebert October 18th, 2009 @ 01:17 PM

    • Assigned user set to “Pieter de Bie”

    It'd be great if it would commit (or focus the commit button) when the Enter key (⌤, not the return key) is pressed in the commit message field.

    This would be congruent with the HIG: "The Enter key tells the application that the user has finished entering information in a particular area of the document, such as a text field.".

    Adium handles this in the same way and it makes perfect sense there: return = newline, enter = send message.

  • Dave Grijalva

    Dave Grijalva March 13th, 2010 @ 02:27 PM

    • State changed from “open” to “feature”
  • Hard Work

    Hard Work July 3rd, 2018 @ 01:12 PM

    If you need to have one of the best platform to sync settings so you need not to go anywhere as here we are going to share outlook sync settings windows 10 which will help you to have all prime information as I have visited last night was an great experience.

  • Anthony Hollowa

    Anthony Hollowa July 3rd, 2018 @ 05:23 PM

    happy wheels: Combining the staged / unstaged lists into one big diff is something I really don't like. It'll make it very hard to see what you're going to commit now (and which files you'll change). Having the clean separation between staged / unstaged is something that I personally use all the time.

  • bukatony

    bukatony July 18th, 2018 @ 01:24 PM

    I'd really like to see gitx have shortcuts for the usual commit-tasks like - y8

  • Suzanne Luce

    Suzanne Luce August 10th, 2018 @ 03:43 PM

    This is definitely the challenge most people should be doing right now. If you are doing the https://www.analyzedu.com/writing-services-reviews/ultius-com-review.html work, then this challenge will benefit you, and you need that right now.

  • agariogames

    agariogames August 14th, 2018 @ 11:00 AM

    Decent post. I was checking continually this blog and I am awed! To a great degree accommodating data exceptionally the last part I nurture such information a considerable measure. I was looking for this specific data for quite a while. Much thanks to you and good fortunes Drag Racer V3

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

GitX is the nice-looking gitk clone for OS X

Pages