3 ms·

I think different tasks are (more) suitable to different interfaces. CLIs are great when the space of actions you could perform is large (to nigh uncountable),

I think different tasks are (more) suitable to different interfaces. CLIs are great when the space of actions you could perform is large (to nigh uncountable), but the range of subjects is small (the file paths, etc are known). Since you know the subjects, a programming language like `sh` is the most concise way to express a complex action. GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Many complex tools like VCSes contain both kinds of situations. I think sometimes a CLI is more appropriate, and sometimes a GUI is, depending on the context. IMO a fully mature VCS should make it as easy to invoke a gui for complex tasks as it is to do them from the command line.

Sir_Cmpwn 10y ago
>GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Those examples are not only possible, but easy to do in the CLI for an advanced user. I do that sort of thing every day. I agree that some tasks are better suited to a GUI and some are better suited to a CLI, but your VCS is firmly in the latter camp imo.
- warbiscuit 10y ago
  As a semi-concrete example, say you have a VCS checkout with 40 edited chunks across 15 files. You want to commit 20 of 40 chunks (spread across 6 of 15 of the files). When you're halfway done, you notice a typo needs correcting in chunk 16, and fix it. You then proceed to commit your selection. From the command prompt, invoking thg and doing that took me about 18 seconds. I'm reasonably good on the command line, but I certainly don't see how to beat that time using just the cli. I think saying it's "easy for an advanced user" is a little loaded, but I'm still interested to know how to do that task faster. And if such a cli process could only be done with git, I'd consider switching.
  - Sir_Cmpwn 10y ago
    git add -p
    - warbiscuit 10y ago
      That's a good example of where I think a gui has an advantage. For the example I gave, unless the hunks were asymetrically distributed, `git add -p` would require pressing "n" 20 times to skip through the excluded hunks (among other things), even when the user could visually see all the hunks, and know which ones they wanted. Where as gui would only require the clicks to select the "y" hunks. I realize this is arguing a difference in the efficiency, not capability, of the UIs; but that's basically my point. The use-cases where one or the other is optimal are too closely situated together in the problem space to say one is inherently the better choice, even for VCS tasks. While command line interaction may allow the user to receive a whole screen's worth of information at once, it forces them to interact with it in a serial fashion, regardless of whether out-of-order interaction with on-screen elements would allow them to complete the task faster.
      - jcrites 10y ago
        I tend to use Git primarily at the command line as well. I recently saw a colleague use an advanced IDE (I think it was IntelliJ IDEA) to perform a complex `git add -i` with staging individual hunks in multiple files. He did it quite a lot faster in his GUI than I could at the command line. His IDE displayed the files he was staging, with full syntax highlighting for the programming language, and background highlighting showing the lines being modified. He quickly paginated through the file and just by clicking with his mouse was able to stage and unstage hunks. He had a neat side-by-side view with two panes of text showing the current text and staged commit, if I recall correctly. The IDE instantly showed if this would result in syntax errors, and could even automatically run the project build and tests. `git add -i` and `git add -p` can do this, but it's much more clunky and serial and modal. For example, my colleague could easily scroll up and down the files, staging and unstaging hunks as needed. He could easily see which files in his file explorer needed this processing and switch between them. This information was all displayed on the screen at the same time, contextually, and the GUI enables navigation to any point in this workflow instantaneously with a click or scroll. I don't tend to have to do this kind of operation very much, and I'm comfortable doing them from the CLI, so I haven't bothered to set up this GUI tool. But I've seen that GUI tools for tasks like this are faster. Anything involving editing the actual text of files or diffs of them will likely be faster in a GUI.

Sir_Cmpwn 10y ago

>GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...). Those examples are not only possible, but easy to do in the CLI for an advanced user. I do that sort of thing every day. I agree that some tasks are better suited to a GUI and some are better suited to a CLI, but your VCS is firmly in the latter camp imo.

warbiscuit 10y ago
As a semi-concrete example, say you have a VCS checkout with 40 edited chunks across 15 files. You want to commit 20 of 40 chunks (spread across 6 of 15 of the files). When you're halfway done, you notice a typo needs correcting in chunk 16, and fix it. You then proceed to commit your selection. From the command prompt, invoking thg and doing that took me about 18 seconds. I'm reasonably good on the command line, but I certainly don't see how to beat that time using just the cli. I think saying it's "easy for an advanced user" is a little loaded, but I'm still interested to know how to do that task faster. And if such a cli process could only be done with git, I'd consider switching.
- Sir_Cmpwn 10y ago
  git add -p
  - warbiscuit 10y ago
    That's a good example of where I think a gui has an advantage. For the example I gave, unless the hunks were asymetrically distributed, `git add -p` would require pressing "n" 20 times to skip through the excluded hunks (among other things), even when the user could visually see all the hunks, and know which ones they wanted. Where as gui would only require the clicks to select the "y" hunks. I realize this is arguing a difference in the efficiency, not capability, of the UIs; but that's basically my point. The use-cases where one or the other is optimal are too closely situated together in the problem space to say one is inherently the better choice, even for VCS tasks. While command line interaction may allow the user to receive a whole screen's worth of information at once, it forces them to interact with it in a serial fashion, regardless of whether out-of-order interaction with on-screen elements would allow them to complete the task faster.
    - jcrites 10y ago
      I tend to use Git primarily at the command line as well. I recently saw a colleague use an advanced IDE (I think it was IntelliJ IDEA) to perform a complex `git add -i` with staging individual hunks in multiple files. He did it quite a lot faster in his GUI than I could at the command line. His IDE displayed the files he was staging, with full syntax highlighting for the programming language, and background highlighting showing the lines being modified. He quickly paginated through the file and just by clicking with his mouse was able to stage and unstage hunks. He had a neat side-by-side view with two panes of text showing the current text and staged commit, if I recall correctly. The IDE instantly showed if this would result in syntax errors, and could even automatically run the project build and tests. `git add -i` and `git add -p` can do this, but it's much more clunky and serial and modal. For example, my colleague could easily scroll up and down the files, staging and unstaging hunks as needed. He could easily see which files in his file explorer needed this processing and switch between them. This information was all displayed on the screen at the same time, contextually, and the GUI enables navigation to any point in this workflow instantaneously with a click or scroll. I don't tend to have to do this kind of operation very much, and I'm comfortable doing them from the CLI, so I haven't bothered to set up this GUI tool. But I've seen that GUI tools for tasks like this are faster. Anything involving editing the actual text of files or diffs of them will likely be faster in a GUI.