Community
Participate
Working Groups
Overall this UI is slower than command line (not counting user errors, which usually favors GUI). One improvement that would help a lot would be to enable the Commit message field as soon as the user submits a request for staging. I don't think the staging can fail in normal circumstances, so at worst the user enters some text that may be lost in a rare server fail or commit collision case. While the staging request is serviced, the user is typing. This overlap would dramatically speed up commits. The "Commit" button could be disabled until the staging completes. An improvement would include listing the to-be-staged files in the Staged area grayed out as soon as the user submits. That way the Commit box does not move when the Staging completes.
(In reply to comment #0) > Overall this UI is slower than command line (not counting user errors, which > usually favors GUI). One improvement that would help a lot would be to enable > the Commit message field as soon as the user submits a request for staging. Yes we should do this. Actually, to allow user to amend a commit at any time, we should always enable the message field now.(https://bugs.eclipse.org/bugs/show_bug.cgi?id=354264) > I don't think the staging can fail in normal circumstances, so at worst the user > enters some text that may be lost in a rare server fail or commit collision > case. While the staging request is serviced, the user is typing. With the message always enabled, now you can type at any time. > An improvement would include listing the to-be-staged files in the Staged area > grayed out as soon as the user submits. That way the Commit box does not move > when the Staging completes. As we are refreshing the staged and unstaged areas after the server request is completed, we can't make sure the commit message will stay at the same position. We can buffer the commit message while user is typing and put the message back. We will always set the focus on the commit message after stage/unstage request is done. Regarding the position of the commit message field, an option is to put it at the very top of the page but it will kind of mislead the work flow.
Just in case you misunderstood my suggestion: Before staging, during staging, and after staging the total number of files is constant. Thus in principle the UI could keep the commit box at the same vertical position. If a staging request started by removing the file from the unstaged list on the client and adding it to the staged list but greyed out OR left the file in the unstaged area and greyed it out, the total vertical space can remain constant allowing the user to focus on text entry.
(In reply to comment #2) > Just in case you misunderstood my suggestion: > > Before staging, during staging, and after staging the total number of files is > constant. Thus in principle the UI could keep the commit box at the same > vertical position. In most of the cases, yes. But if you modified a staged file and go to git status again, you will see the same file on staged and unstaged area but that is rare case. > If a staging request started by removing the file from the > unstaged list on the client and adding it to the staged list but greyed out OR > left the file in the unstaged area and greyed it out, the total vertical space > can remain constant allowing the user to focus on text entry. We will just "leave the file in the unstaged area and greyed it out".
fixed with c1b0b2d8db9badf4bf6765a9868cd2ec6862bd51. Now the commit message field is enabled as soon as you start to stage. You can type while the request is being processed and the commit button is disabled until the request is done by server.
Just another comment on the solution : the list of selected files are greyed out when your stage request is being processed.
