5

I was going through some tutorials on TortoiseHg. Despite having a rich GUI, the first examples are given using command line options. Does the ideal usage involve command line or it was started that way so one has idea of what is happening under the hood and GUI internally uses this command anyway.

4
  • This question might be relevant Jun 7, 2011 at 7:13
  • 6
    The question in the title has a very definite answer: Yes. VCS should be used. Whether it's CLI or GUI doesn't really matter. Jun 7, 2011 at 13:45
  • 7
    Who cares? Why would it possibly matter? Pick whichever one you want. Jun 7, 2011 at 16:14
  • 1
    I'm voting to close this question as off-topic because it is about the use of a tool. It should be addressed by the support of the tool itself. Jun 21, 2018 at 8:19

12 Answers 12

35

Use what you want. Use what makes sense for what you are doing now.

While I'm mostly a command line guy (I use the GUI only to get a graphical representation of revision graph), I've trouble to understand why you think using the command line gives you a better understanding of what happens behind the hood (well excepted for GIT :)), usually there is a clear mapping between the two even if CL may give you access to some little used features.

Now in my opinion, automating what can be automated in the process is part of the job and for that, CL is mandatory.

2
  • I was thinking of the point mentioned in VonCs post. Jun 7, 2011 at 7:32
  • 4
    +1 for the comment about automation requirements. I'm too lazy to learn (en too old to remember) little used, esoteric command line things, so prefer a GUI, however I would not touch a tool that did not have a CL at least as feature rich as the GUI.
    – mattnz
    Jun 7, 2011 at 9:27
14

It's easier to write tutorials using the CLI. All you need is text! Trying to demonstrate workflows in a GUI means screenshots, and circles and arrows and a paragraph on the back of each one explaining what each one is.

Use whichever you want. There is no "right" way.

3
  • 1
    This answers an implied question in the OP: "Since TortoiseHg is a gui, why do the first few tutorials use the command line?"
    – jhocking
    Jun 7, 2011 at 16:09
  • I personally found it easier to understand tutorials using the GUI - possibly others are the same?
    – fostandy
    Jun 2, 2015 at 8:47
  • Note that I said write, rather than read. GUI tutorials are often much easier to understand! Jun 2, 2015 at 17:12
11

I prefer a mix of both.

The GUI is fine for day-to-day use of the core functionality.

However, it is very useful to know how things work "behind the scenes" on the command line -- especially if you want to make use of more advanced features, or write scripts to automate some common tasks.

10

Ideally, you'd want both.

Generally, the commands are implemented as a command line, which means that you have the following benefits:

  1. You can put any number of GUIs on top.
  2. You can integrate it with whichever tool you like.
  3. You can use it in scripts.

The latter is extremely important. Want your build server to checkout your code, and it doesn't have a direct API to the system? Well, with a command line interface, it will be able to work. The same applies to everything.

1
  • 1
    Why is this "ideally"? If you're comfortable with the CLI alone, then I don't see where you could perceive a loss of some sort.
    – tripleee
    Jan 23, 2013 at 9:16
5

It started as a command line. Look at svn, bzr, hg, git... Some needed GUI, because they were to lazy to remember commands and wanted buttons there fore most of existing GUI's are juts overlay for command-line interface, although there are some such systems that are GUI only (those are usually unseen and are implemented in some text editors).

Sure both are needed. In windows its bit hardcore to use cmd to make commits and use VCS while in Linux i personally use command-line mercurial every time since i get things done faster and cleaner.

Where it should be used from (GUI vs command-line)? You got the choice. Learn both (you'll need it) and then use the better one in your personal opinion.

More on topic: http://en.wikipedia.org/wiki/Revision_control

3

Whatever works for you. I have seen GUI masters that are so fast it puts a lot of command line users to shame and vise-versa. The only thing that matters is choosing something and learning the ins and outs of it. Once you're very good what you chose, learn the other way.

2

I think it is the general answer for types of software people use regularly: Initially GUI and once someone has mastered the concepts, then more and more command line. I am currently using a specific version control tool in a once per month basis. It would be impossible for me to remember any command line syntax. So only GUI.

On the other hands after some months of using subversion, it became a command line only affair, no need for visuals.

1

You'll see that most answers, refer to use both. Learn to use both, and use each method acording to the situation.

The G.U.I., is usually more easy to use, but, there are scenarios, wheter you have to stick to the command line version. Some programming I.D.E. include or can be extended with a G.U.I. for the C.V.S. of your choice.

Sometimes, you may need to use a C.V.S. for files that aren't applications, or aren't supported by your programming I.D.E.

I worked once, in a VB6 project where the VB6 I.D.E. included it own C.V.S. included with its G.U.I., unfortunately it didn't work well, and sometimes, corrupted files, or lost some versions. We had to install an Open Source C.V.S., that we had to use from the command line.

1

Use whatever makes you most productive, but learn the CLI regardless. It's the lingua franca of the VCS, so you'll need to know it to ask and/or answer questions on places like stack overflow. Also, the most advanced features are only available on CLI, so chances are you will eventually end up wanting it, even if only rarely. You can also mix and match clients. I personally am most productive using a GUI for history visualization and manually resolving merges, and the CLI for everything else.

1

TortoiseSVN for SVN on Win32/64, because of the icon overlays for visual feedback.

Otherwise: GUI for less-frequent operations (superior discoverability & better affordances), command-line for most common operations (increased parsimony, fewer keystrokes).

0

The GUI is mandatory when you have any tool deployed to a large set of users.
If that tool has some multi-step operations (workspace creation, multiple files merge, ...), a wizard dialog is welcome.
If that tool can present a graphic representation of some state (history, version tree, branches and merges, ...), a user will appreciate a graphic window instead of a wall of text in a shell.

But a CLI is also mandatory every time any GUI operation fails: the same operation done from a CLI often generate an error message much more precise and complete than the error dialog box displayed by the GUI.
And any scripting can use of course a CLI for automation purpose.

16
  • I assume you mean CLI in "the same operation done from a GUI often generate(s) an error message much more precise..."
    – DrAl
    Jun 7, 2011 at 8:11
  • @DrAI: true, I fixed the... "typo".
    – VonC
    Jun 7, 2011 at 8:13
  • 2
    Only if the GUI is crappy and hides details...the bulk of the SCM systems I use end up dumping the same error message to console or to the GUI, for exactly this reason. Jun 7, 2011 at 13:31
  • 1
    GUI is never mandatory unless it is something graphical. VCS is not graphical. Jun 7, 2011 at 14:19
  • 3
    @mathepic: believe me, with a large set of users, you want a GUI. And VCS can be graphical. Tortoise(SVN or Git), or the ClearCase version tree are a clear illustration of that.
    – VonC
    Jun 7, 2011 at 14:47
0

If you have a lot of repeated operations, such as adding some but not all files

git add file1
git add file2
git add file3
...
git add fileN

then GUI with checkboxes is definitely better.

If you need to enter hashes as command arguments, then GUI is definitely better (allow to select and no need to remember the hashes)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.