Command-line git Vs IDE+plugin?

Hi,

I'm normally an Emacs+command-line user, but I also use Eclipse or Netbeans on some projects. I tried using EGit and the Netbeans plugin for Git, but found the GUI both more comlex and less powerful than the command-line. I end-up using command-line git in a terminal, outside the IDE (and do a refresh in the IDE after commands that modify the worktree). Obviously, being a long-time command-line user, I'm rather heavily biaised ;-).

I was wondering whether others had similar (or not) experience. In particular, as a teacher, I'm wondering whether I should push my students towards the GUI in the IDE, or advise them to keep using the command-line (we teach them git with the command-line first anyway, but after a year of practice, we may want to show them the GUI equivalent).

Thanks,

Did you give magit a try? It's really an awesome emacs plugin, which gives me pretty much the same control as the command line experience without the pain. Ask me more about if if you're interested.

In my experience, most people prefer the GUI version, simply because to them it's more intuitive and stuffs like visual diffs tools are integrated, which makes them quickly realise the benefits. That said, because it's "easier" they tend to not dig deeper and are lost at the first little problem, e.g a simple conflict becomes difficult to solve.

In my opinion to *learn* git it's useful to learn with the console first, just like when you learn C++ it's useful to start with simple exercises and not jump straight to GUI programming. When they become familiar with the basics, I think it's nice to show them about `git log --graph --all --decorate` and the gitk/gitg equivalent, or "git diff" and the vimdiff/ediff/visual merge/kdiff equivalent.

When they understand git reasonably (or if they are not lazy people and willing to learn), then show them full integrations like TortoiseGit (or probably the Netbeans plugin), which are nice when everything works but you have to know console git to fix things or simply to be aware of their limitations.

TL;DR, I think both are necessary, the command line to understand git and the integrations/wrappers to add sugar to your daily workflow. Visual tools are great, especially visual diffs for merging.

Philippe

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

I've used the Git backend for DVC in the past. I gave Magit a try very long ago, and found DVC superior at that time (I was the main author, so I was once again heavily biaised). But I got used to the command-line more and more (within an ansi-term window inside Emacs most of the time), and ended up abandonning DVC (both as a user and contributor).

Maybe I'll give it another try.

On Mon, 18 Nov 2013 18:42:26 +0100 Philippe Vaucher <philippe.vaucher@gmail.com> wrote:

[...]

When it comes to Git on Windows with a GUI front-end, I would recommend to take a look at Git Extensions [1] as well.

1. http://code.google.com/p/gitextensions/

On Mon, 18 Nov 2013 18:11:54 +0000, Matthieu Moy wrote: ...

Similar. When I used eclipse I didn't even try to use the plugins and just stayed on the command line. (Well, almost, but back then jgit couldn't deal with submodules which I needed.)

I have the same experience with the few git GUIs I tried - none stuck to me. Even 'git gut' hardly made the cut, I stay with the command line except for gitk which is very useful to see what you've done.

For people that live in the IDE anyway the mileage will vary, but for me there is always some extra mismatch to overcode - I know what the CLI is doing and think in terms of these operations, and I'd need to understand what the GUI is thinkig to be good for me (i.e. how operations are implemented there); for me it always fells like a mist over the repo.

And I know that I'm missing on some features - the integration of history examination into codebrowsing schoould be a good thing.

Still, if you show them eclipse, I'd also show them the git integration in there. I dread the moment I have to show someone how to merge a pull (or any merge) in eclipse though. :-(

Andreas

On Monday, November 18, 2013 06:11:54 PM Matthieu Moy wrote:

I'm a software engineer now with an education as a high school teacher. From a theoretical point of view it's preferable to avoid any abstraction done by a GUI and use commandline Git. Only gitk is useful to have a visual _feedback_ of the actions done on the commandline.

But also from experience I can tell that without exception everybody whom I teached Git understood it only after being introduced to the basic concepts of Git and how to inspect and operate them on the commandline. Others told me from similar experiences.

Those concepts are:

- hashes
- content adressable storage
- blops being referenced by trees being referenced by commits

My collegues meanwhile dumped their graphical Git tool because they learned that they have better control over Git when using it from the commandline.

Regards, Thomas Koch

Thomas Koch <thomas@koch.ro> writes:

Interesting.  I think any UI needs to fill three objectives:

 - make common tasks easy;
 - make complex tasks possible; and
 - help users build the right mental model.

As a tool from Linus school, we started from the second and the third point. Our UI (i.e. CLI) has long been notorious for lacking in the first department, and we have worked long and hard to improve on that front. While there are more work needed for CLI, your observation, and a similar experience by Noufal in the thread, hints me that the available GUI tools have concentrated primarily on the first point but are still lacking in the rest.

Perhaps I am being naïve, but I would expect that a GUI is a much better vehicle to help users build the right mental model. Unlike CLI, it has a canvas to draw pretty pictures and present the users what the user is really doing after all.

And I am sure GUI people will eventually realize that potential in the tools they are building, and the world will become a better place for both GUI and CLI users ;-). I found "ungit" an interesting experiment that goes into that direction.

Being forever hopeful...

Junio C Hamano <gitster@pobox.com> writes:

One thing the command-line does well is to give names to concepts (basically, command names, option names, ...). It's easy to write in a tutorial or an email "run the command 'git foo'". It's less easy to write "click on that red button, on the right of the green one". Then, it's clear to everyone what "commit", "rebase", "amend" & so mean, regardless of the colors of buttons (that's one of the reasons I use the english words even when I speak french).

That said, even when I teach the command-line, gitk is a very valuable tool to explain what the DAG is and how branching works.

On Tue, Nov 19, 2013 at 6:20 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

And it is also easier for many to press a button than writing a command. This is a bad thing, in my experience. In a GUI, people tend to take chances: "Oh, reset, that sounds like what I want. What, it did not work? Oh there is this option 'hard', let's tick it and see what happens."

Another thing GUIs do not (often) offer is history. I would be lost if I couldn't see what I was trying to do 5 commands ago (before someone interrupted me), or refer to a previous error message.

But if you cannot touch-type, buttons are going to be more attractive.

Thomas Koch <thomas@koch.ro> writes:

A great reference I always point people to for exactly those reasons is Sitaram Chamarty's "git concepts simplified":

    http://gitolite.com/gcs/

-Keshav

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

[...]

[...]

I teach git professionally and I do so using only the command line interface. This allows me to explain the underlying structures and how data is organised so that commands don't look like magic spells that solve problems. It helps people build a mental model of how the software works so that they can solve most problems themselves or atleast ask the right questions. I actively discourage people from using IDE plugins and graphical front ends for the training because they hide the details which I think are important.

I use gitk and some home brew scripts to show how the DAG and objects get created and their structures but that is purely for illustrative purposes.

I also mention a few git front ends in passing like magit (which I use) and tortoise (since many of the trainings I conduct are for Windows users) at the end of the course so that people are aware of alternatives.

On 19/11/13 06:11, Matthieu Moy wrote:

My $0.02 as someone who performs some part-time SCM admin tasks for a moderately sized group of engineers (~40) with varying degrees of experience.

Some people are scared by a command line and think poking buttons in an IDE is preferable (and somehow safer). As others have pointed out the first sign of trouble they shuffle over to my desk. I see the people that are comfortable with the command line far less frequently.

I think learning the command line first does help with peoples overall understanding. Once they have some working knowledge of the basics introducing some of the tools that integrate with those building blocks is much easier.

In some respects the gui/IDE is better for some tasks. For example I don't even bother telling people about 'git add -p' because 'git gui' provides the same functionality with an interface that is better suited to picking chunks/lines of code to stage. Another example is Eclipse's "annotations" which provides the same information as 'git blame' but it is right there with the code I'm editing.

Specifically about Eclipse; I've personally found that in the days of Ganymede/Helios the VCS integration built around SVN and the mapping of SVN concepts to Git was imperfect (impossible?). With Juno/Indigo the support for DVCSes in general and for Git specifically is greatly improved but I still rarely use Eclipse to actually make commits.

- C