Hacker News Reader

> This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is.

This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and clean and diamonds and countless other details that I feel should be encapsulated way better. git also has next to none documentation of these concepts.

I think that's a bit unfair. It presumes git is trying to abstract it's internals in the first place.

It's not.

Git is unapologetically a tool for manipulating a DAG, and puts that right in your face.

This has pros and cons. The obvious con is that it has an immensely steep learning curve and, for users who cannot develop a mental model for how it works, forces people to rely on cargo culting.

The flipside is that it's more powerful than any SCM I've worked with, as the lack of any abstraction means you can do nearly anything you like to that DAG.

Heck, let's take this example originally posted. The remote repo has changed. Okay, well, the common case is probably to pull and... wait, merge or rebase local changes? Git gives you the choice. Other tools might not.

All that said, git could certainly be made a lot less esoteric. The command set is inconsistent and poorly named (I'm looking at you 'git reset'). And the error messages leave a lot to be desired.

As for doc, I completely disagree. I've built git training modules and my primary sources are the git docs. They're quite thorough (though they have the fault of being heavily steeped in git jargon).

> They're quite thorough (though they have the fault of being heavily steeped in git jargon).

So you actually agree. To understand the docs you have to understand git jargon, and the docs aren't too helpful about that.

I certainly don't want to say that the git docs are bad. They're quite complete and written in mostly complete sentences, which is already pretty good as far as documentation goes. Doesn't mean that there is a lot of room for improvement.

> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c.

While I agree that there are those who take pride in how spartan tools they use, it's not correct to make blanket judgements about the whole suite of hackerware. Emacs, for instance, is not difficult to use, it is a different computing environment, which, when you get hold of it, can boost your productivity. I've written many little programs in it that I use every day which I'd never be able to write in other languages because a) I need to know at least one GUI framework and many other libraries, b) no other environment has the same use-hack-eval-use development experience, and c) the way you create GUIs in Emacs is so effective (mixture of special-mode, plain text and text with properties attached; all buffer-manipulation commands come in to your app out of nowhere, gratis) that one can set sth. working in their first hacking session, and then on improve their tools while using it, all interactive, whereas in all other GUI frameworks you're left alone with widgets and a dev cycle that's nearly always approximately write-compile-debug-compile.

Git, instead, is a plain tool for one purpose with an arcane user interface. I believe the patch theory school of VCS tools (e.g. darcs) will overtake in future when they'll smooth out their rough edges as they provide a very intuitive way to work with code as a series of related changes.

Emacs is not difficult to use?

In order to get it to do half of what Notepad++ or Sublime or Kate do, you have to spend hours and hours to learn it and configure it in the hope that the investment will pay off and that the productivity gain will make up for it. And despite what you might say there's no data you can point me to that actually proves those increased productivity claims.

> In order to get it to do half of what Notepad++ or Sublime or Kate do

Do they have anything remotely like Gnus or Org-mode? Tramp? Magit? VC mode? SLIME? EMACS IS NOT A TEXT EDITOR. It is a Lisp interpreter with many applications written in it which happens to have a text UI and a text editor in its standard distribution.

You are comparing Emacs with Notepad++. You are then not using Emacs as it's supposed to be.

The actual power of Emacs is realized once you learn elisp. Coding, documenting, commiting, blogging, browsing, file/dir manipulation, etc. all can be done efficiently using the same familiar buffer editing philosophy within Emacs.

Would you mind sharing what some of these little programs do?

A little thing to show a compact weather forecast [1], a basic fronted to FreeBSD pkgng, a frontend to zx2c4's pass, some other utilites.

[1] http://www.gkayaalp.com/emacs.html#forecast.el

> I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is.

Some of us never forget. And "esoteric" is way to kind a word for that thing, it is abstraction leak made software.

As a developer who hasn't learned git beyond the superficial, I second the notion that it is extremely esoteric.

Time to try Fossil :-)

> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs)

No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.

Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes) mean that git gets useful new features?

Yes?

Having checkout handle creating branches is strictly a shortcut. The other option for the shortcut would be for `git branch` to sometimes alter state in your working directory (it currently never does this). The non-shortcut version (which works today) is to only create branches with `git branch` and only checkout branches with `git checkout`.

If you look at it from the perspective of "checkout is the thing that screws with your local working directory", it is organized logically.

> Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes)

Branch management:

    # creation
    git branch foobar

    # listing
    git branch

    # renaming
    git branch -m barfoo

    # relocation
    git branch -f barfoo

    # deletion
    git branch -d barfoo

Working directory management:

    # change WD to branch
    git checkout foo

    # change WD to state of HEAD
    git checkout -- .

    # change WD to new branch forking HEAD
    git checkout -b bar

    # ...

As an aside, `--` is UNIX for 'end of options'; nothing git-specific. I mention this because that's another thing that seems to come up with people saying it's some mad git option that makes no sense and you just have to remember it.

> mean that git gets useful new features?

I don't really understand what you mean by this. Is something only 'powerful' if it 'gets useful new features'?

--

I'm not saying it's easy for newcomers, I'm just saying the difficulty is biased to the early stages of the learning curve (I certainly experienced it, I used to fear git - now I fear lack of it) and disputing the claim that it isn't powerful.

I think we're mostly in violent agreement that there's a pretty steep learning curve. That is also true for some other tools. I'm questioning the link between steep curve and powerful; it is true that many powerful tools have steep learning curves; but one can easily think of tools that have steep learning curves but are not powerful. So, the question is: is git's CLI just weird, or does it need to be weird in order to be successful as an SCM? (I think it's the former.)

It sounds like you are suffering from the problem yourself.