4 ms·

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. I think a lot of d

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. 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. Maybe this is to do with our desire for everything to be as flexible as the programming languages we write in. Most people don't view computers as blank slates ready to do their bidding, but as systems where the behaviour of a few facets is to be memorised without concerns for their mechanics or abstractions. This is probably one of the reasons that mobile software is seen as so easy to use, since it obscures/abstracts elements like the filesystem from the user. Glad to hear Fossil is friendlier. EDIT: I should say that I am a heavy user of Vim, Emacs, Git and Arch Linux, I am just saying that these tools often require a large up front investment, and this can be detrimental as well as sensible.

vkou 10y ago
As a developer who hasn't learned git beyond the superficial, I second the notion that it is extremely esoteric.
- rkeene2 10y ago
  Time to try Fossil :-)
deleted 10y ago
[deleted]
OJFord 10y ago
> 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.
- lvh 10y ago
  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?
  - __david__ 10y ago
    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.
  - OJFord 10y ago
    > 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.
    - lvh 10y ago
gkya 10y ago
> 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.
- oblio 10y ago
  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.
  - gkya 10y ago
    > 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.
masklinn 10y ago
> 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.
throwawayish 10y ago
> 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.
- zzalpha 10y ago
  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).
  - throwawayish 10y ago
    > 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.

vkou 10y ago

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

rkeene2 10y ago
Time to try Fossil :-)

deleted 10y ago

[deleted]

OJFord 10y ago

> 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.

lvh 10y ago
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?
- __david__ 10y ago
  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.
- OJFord 10y ago
  > 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.
  - lvh 10y ago

gkya 10y ago

> 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.

oblio 10y ago
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.
- gkya 10y ago
  > 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.

masklinn 10y ago

> 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.

throwawayish 10y ago

> 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.

zzalpha 10y ago
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).
- throwawayish 10y ago
  > 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.