4 ms·

under a version control system as beautiful as git? I'll grant that git can be useful and it's certainly unavoidable, but "beautiful" is not a word I would use

by jordigh 11y ago

under a version control system as beautiful as git? I'll grant that git can be useful and it's certainly unavoidable, but "beautiful" is not a word I would use to describe it. Git is ugly and best hidden underneath GUIs, WUIs, and frontends. Indeed, this is how most people use it. Very few of the thousands or millions of git users know more than basic usage and most do not rely on the CLI. So, in a similar vein to static blogs under version control, we have blohg for hg: http://blohg.org/ http://blohg.org/

imron 11y ago
> Git is ugly and best hidden underneath GUIs I guess I'm one of those 'very few', because every GUI and frontend I've used that tries to hide what's going on underneath has been far more cumbersome to use than the command line. The only thing I'll use a Git GUI for is to check the history/revision graph.
- jordigh 11y ago
  The HN "random" sample of git users is also very skewed towards the git power users. Here is some usability research from Google et al about VCS usage: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf https://static.googleusercontent.com/media/research.google.c...
- cowpewter 11y ago
  Git GUIs terrify me. On the command line, I know exactly what was run and how to get back to a known good state if I muck it up (or at least where to start googling for the undo!). I have no clue what some GUI is running behind the scenes when I click some theoretically innocuous button. Or at least that is how I felt when I was a beginner to git. Now I'm confident that I could fix anything a GUI screwed up but the command line is just easier and faster for me.
nchelluri 11y ago
On the topic of git... For the first 6 months I used git, which was because I started a new job where it was used, I stuck almost exclusively to a coworker's wiki page, "<name>'s git cheatsheet". I remember re-cloning the repo so many times when chances are there was a way I could have fixed the mess I'd created. I didn't know what I was doing and it was very complicated. It had a steep learning curve. Now, some six years later, I still only use a handful of commands regularly, but really, aside from the painful-to-read man pages (they are very clear, but contain so many flags and other tidbits), I find it very simple to understand and to use. I rarely ever get confused. I'm not a big fan of `rebase` but I can see where it would have its purpose in merging feature branches back to the trunk/master (and if I can find a coworker using it in a nice, clear way, I might adopt it myself). I never use `--force` and recommend that everyone everywhere avoid it once they've pushed. But really, and there may be some "survivor bias" involved here, I think it's a very well done system for what it does, and I am generally able to reason pretty clearly about what's going on and help others figure out what their issues are. It's quite possible that bzr/hg/darcs is a better and cleaner way of doing the same tasks, and I still have no idea about many commands and I am sure there are things that I have glossed over thinking that I understand them... but it makes sense to me; I don't like any of the GUIs (though I tend to like to "live" in the terminal as much as possible, I've seen things I don't like in both Tower and Sourcetree), and it just seems right to me. Sorry to go off on a tangent there...
- rakoo 11y ago
  Some people say you have to understand how git organizes its data internally to be able to use it. It was even more than that to me: the way git organizes its data internally is awesomely simple and powerful, and anything you want to do with git is just finding the right incantation. And when you find it, you don't really care how ugly it is, because you know how all things really are underneath and you find peace in knowing all is right.
the_fury 11y ago
Very few of the thousands or millions of git users know more than basic usage and most do not rely on the CLI. I'd be interested to know where you get these numbers, as this doesn't match my observations at all. I generally see people move quite quickly from a GUI to the command line.
- jordigh 11y ago
  I don't think a study on this specific point exists, but here are some Drake-equation-like ways to estimate this. Microsoft estimates tha there are 8 million .NET users in 2012: http://www.quora.com/How-many-NET-developers-are-there http://www.quora.com/How-many-NET-developers-are-there Let's say the number is in the same range today (I don't see a reason why the number of Windows developers would have drastically grown or dropped since then), and let's add a couple more million Windows developers who do not use .NET. Total, 10 million Windows developers. Let us say, half of all Windows use git for source control (non-git usage is still huge in private corporations). I am probably underestimating here. So, very roughly, that's about 5 million git users on windows. Let us also estimate that 90% of all Windows users never use a CLI. I have personally met very few Windows developers who do. Windows is very much anti-CLI. So that's 4.5 million git users who do not use a CLI and 0.5 million Windows users who do. For Mac OS X, we know that there were 1.2 million apps last year, let's say that there are, I don't know, three developers per app on average: http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-2-million-apps-has-seen-75-billion-downloads-to-date/ http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-... Since Apple steers developers to use Xcode and Xcode has git integration, let's say half of all Apple-based developers do not use the git CLI regularly. We shall assume that Apple-based developers are a bit more familiar with a CLI than Windows users. So this is 1.5 million Apple users who use git without a CLI and 1.5 million who do. That's a total so far of 2 million CLI git users and 6.5 non-CLI git users. Finally, let us say that nearly every git user has a github account. Let's say, 25% of them don't. Github has reported 3 million users in 2013: http://thenextweb.com/insider/2013/04/11/code-sharing-site-github-turns-five-and-hits-3-5-million-users-6-million-repositories/ http://thenextweb.com/insider/2013/04/11/code-sharing-site-g... http://redmonk.com/dberkholz/2013/01/21/github-will-hit-5-million-users-within-a-year/ http://redmonk.com/dberkholz/2013/01/21/github-will-hit-5-mi... Exponential growth suggests it should be around 5 or 6 million now, and if 25% of all git users do not use github, that roughly matches my estimates for how many of them are spread out across Windows and Apple. So yeah. I am very confident that most git users do not use the CLI, at least not regularly. I am almost certain that of those git users who primarily use a git frontend, they only ever drop down into the command line when they need to do something very specific and they google that specific thing and copy around the magic git incantation that they find. I know you can wiggle these numbers around a lot. But I also think we forget how big the non-HN developer crowd is, and how large the number is of people who are averse to a CLI.
nevster 11y ago
Beautiful is way overused. I hate it. Whenever some new website/app uses it to describe their UI, I feel rage!
isaacremuant 11y ago
when one knows a command line tool it often feels much better, much faster, much more powerful than any GUI command. Do you use linux? (If not, that would explain it) Do you claim the same thing for all the other gnu tools (grep et al)? Git might have some esoteric flags and commands at some points but is not ugly at all and, when understood, it really feels beautiful (and safe, oh so safe to use knowing I know how to recover from practically anything, git has my back). edit: looking at your other response... using Windows devs who are unfamiliar with GUIs as a metric is not really a good point. If you're going to use Argumentum ad populum then bad programming practices are better than good practices.
- jordigh 11y ago
  I'm hardly alone in thinking the git CLI is difficult to use. It is in fact one of the most frequently criticisms against git. I think the best evidence for that is that there is no shortage of blog posts about how easy it is to learn git, and here, these are all the easy things you should do in order to learn git. If it's so easy, why is Git Explained its own genre of blog post? I can only think of Monads/Haskell Explained as another blog post in a similar genre. It's not about how often we use it: for example, we probably use ls and cd a lot more than git, yet we don't write endless blog posts about how easy ls and cd are. If git really were that easy, it wouldn't need so much explaining.
  - scarecrowbob 11y ago
    "If git really were that easy, it wouldn't need so much explaining." Well, on one hand, I like the git cli better than guis, but on the other, I don't really disagree. However, to your question: it might just be the case that it's an easy thing to explain, or an easy thing to learn, or made easier by writing... there are a lot of other possibilities than there is a big demand for these articles.
flippinburgers 11y ago
Spoken like a true mercurial enthusiast? :) I have used git on the command line since day 1. It really isn't that hard.
rakoo 11y ago
It's funny because I fail to see the value of having a blog version controlled (maybe because I don't have a blog myself, but still). We use version control because sometime we mess up, so we want to go back in the past and compare values of the same file at different points in time. I don't understand how this kind of problem ever arises when you have a blog: You never need to compare multiple versions of the same post, and if you use files, you always use a different file for each post. We also use version control when we want to have parallel development (ie keep a stable, working master branch, and toy around in a dev branch). When you have a blog, you just use a _drafts folder that is configured so that what is inside is never published; when your post is ready you move it to the _public folder or whatever. Another worthless feature in that use case. What _is_ useful from a version control, and more specifically from git, is its ability to replicate everywhere: push to your personal backup, push to github, ush to your webserver. It is used both as a backup and as a way to have your content be where you distribute files. But git is not the only option availale to sync content, and far from the only one. A HTTP POST is more common, and a Dropbox sync is even easier (you don't have anything to do, and the content is automatically synced and distributed for free by Dropbox)

by jordigh 11y ago

imron 11y ago

> Git is ugly and best hidden underneath GUIs I guess I'm one of those 'very few', because every GUI and frontend I've used that tries to hide what's going on underneath has been far more cumbersome to use than the command line. The only thing I'll use a Git GUI for is to check the history/revision graph.

jordigh 11y ago
The HN "random" sample of git users is also very skewed towards the git power users. Here is some usability research from Google et al about VCS usage: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf https://static.googleusercontent.com/media/research.google.c...
cowpewter 11y ago
Git GUIs terrify me. On the command line, I know exactly what was run and how to get back to a known good state if I muck it up (or at least where to start googling for the undo!). I have no clue what some GUI is running behind the scenes when I click some theoretically innocuous button. Or at least that is how I felt when I was a beginner to git. Now I'm confident that I could fix anything a GUI screwed up but the command line is just easier and faster for me.

nchelluri 11y ago

On the topic of git... For the first 6 months I used git, which was because I started a new job where it was used, I stuck almost exclusively to a coworker's wiki page, "<name>'s git cheatsheet". I remember re-cloning the repo so many times when chances are there was a way I could have fixed the mess I'd created. I didn't know what I was doing and it was very complicated. It had a steep learning curve. Now, some six years later, I still only use a handful of commands regularly, but really, aside from the painful-to-read man pages (they are very clear, but contain so many flags and other tidbits), I find it very simple to understand and to use. I rarely ever get confused. I'm not a big fan of `rebase` but I can see where it would have its purpose in merging feature branches back to the trunk/master (and if I can find a coworker using it in a nice, clear way, I might adopt it myself). I never use `--force` and recommend that everyone everywhere avoid it once they've pushed. But really, and there may be some "survivor bias" involved here, I think it's a very well done system for what it does, and I am generally able to reason pretty clearly about what's going on and help others figure out what their issues are. It's quite possible that bzr/hg/darcs is a better and cleaner way of doing the same tasks, and I still have no idea about many commands and I am sure there are things that I have glossed over thinking that I understand them... but it makes sense to me; I don't like any of the GUIs (though I tend to like to "live" in the terminal as much as possible, I've seen things I don't like in both Tower and Sourcetree), and it just seems right to me. Sorry to go off on a tangent there...

rakoo 11y ago
Some people say you have to understand how git organizes its data internally to be able to use it. It was even more than that to me: the way git organizes its data internally is awesomely simple and powerful, and anything you want to do with git is just finding the right incantation. And when you find it, you don't really care how ugly it is, because you know how all things really are underneath and you find peace in knowing all is right.

the_fury 11y ago

Very few of the thousands or millions of git users know more than basic usage and most do not rely on the CLI. I'd be interested to know where you get these numbers, as this doesn't match my observations at all. I generally see people move quite quickly from a GUI to the command line.

jordigh 11y ago
I don't think a study on this specific point exists, but here are some Drake-equation-like ways to estimate this. Microsoft estimates tha there are 8 million .NET users in 2012: http://www.quora.com/How-many-NET-developers-are-there http://www.quora.com/How-many-NET-developers-are-there Let's say the number is in the same range today (I don't see a reason why the number of Windows developers would have drastically grown or dropped since then), and let's add a couple more million Windows developers who do not use .NET. Total, 10 million Windows developers. Let us say, half of all Windows use git for source control (non-git usage is still huge in private corporations). I am probably underestimating here. So, very roughly, that's about 5 million git users on windows. Let us also estimate that 90% of all Windows users never use a CLI. I have personally met very few Windows developers who do. Windows is very much anti-CLI. So that's 4.5 million git users who do not use a CLI and 0.5 million Windows users who do. For Mac OS X, we know that there were 1.2 million apps last year, let's say that there are, I don't know, three developers per app on average: http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-2-million-apps-has-seen-75-billion-downloads-to-date/ http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-... Since Apple steers developers to use Xcode and Xcode has git integration, let's say half of all Apple-based developers do not use the git CLI regularly. We shall assume that Apple-based developers are a bit more familiar with a CLI than Windows users. So this is 1.5 million Apple users who use git without a CLI and 1.5 million who do. That's a total so far of 2 million CLI git users and 6.5 non-CLI git users. Finally, let us say that nearly every git user has a github account. Let's say, 25% of them don't. Github has reported 3 million users in 2013: http://thenextweb.com/insider/2013/04/11/code-sharing-site-github-turns-five-and-hits-3-5-million-users-6-million-repositories/ http://thenextweb.com/insider/2013/04/11/code-sharing-site-g... http://redmonk.com/dberkholz/2013/01/21/github-will-hit-5-million-users-within-a-year/ http://redmonk.com/dberkholz/2013/01/21/github-will-hit-5-mi... Exponential growth suggests it should be around 5 or 6 million now, and if 25% of all git users do not use github, that roughly matches my estimates for how many of them are spread out across Windows and Apple. So yeah. I am very confident that most git users do not use the CLI, at least not regularly. I am almost certain that of those git users who primarily use a git frontend, they only ever drop down into the command line when they need to do something very specific and they google that specific thing and copy around the magic git incantation that they find. I know you can wiggle these numbers around a lot. But I also think we forget how big the non-HN developer crowd is, and how large the number is of people who are averse to a CLI.

nevster 11y ago

Beautiful is way overused. I hate it. Whenever some new website/app uses it to describe their UI, I feel rage!

isaacremuant 11y ago

when one knows a command line tool it often feels much better, much faster, much more powerful than any GUI command. Do you use linux? (If not, that would explain it) Do you claim the same thing for all the other gnu tools (grep et al)? Git might have some esoteric flags and commands at some points but is not ugly at all and, when understood, it really feels beautiful (and safe, oh so safe to use knowing I know how to recover from practically anything, git has my back). edit: looking at your other response... using Windows devs who are unfamiliar with GUIs as a metric is not really a good point. If you're going to use Argumentum ad populum then bad programming practices are better than good practices.

jordigh 11y ago
I'm hardly alone in thinking the git CLI is difficult to use. It is in fact one of the most frequently criticisms against git. I think the best evidence for that is that there is no shortage of blog posts about how easy it is to learn git, and here, these are all the easy things you should do in order to learn git. If it's so easy, why is Git Explained its own genre of blog post? I can only think of Monads/Haskell Explained as another blog post in a similar genre. It's not about how often we use it: for example, we probably use ls and cd a lot more than git, yet we don't write endless blog posts about how easy ls and cd are. If git really were that easy, it wouldn't need so much explaining.
- scarecrowbob 11y ago
  "If git really were that easy, it wouldn't need so much explaining." Well, on one hand, I like the git cli better than guis, but on the other, I don't really disagree. However, to your question: it might just be the case that it's an easy thing to explain, or an easy thing to learn, or made easier by writing... there are a lot of other possibilities than there is a big demand for these articles.

flippinburgers 11y ago

Spoken like a true mercurial enthusiast? :) I have used git on the command line since day 1. It really isn't that hard.

rakoo 11y ago

It's funny because I fail to see the value of having a blog version controlled (maybe because I don't have a blog myself, but still). We use version control because sometime we mess up, so we want to go back in the past and compare values of the same file at different points in time. I don't understand how this kind of problem ever arises when you have a blog: You never need to compare multiple versions of the same post, and if you use files, you always use a different file for each post. We also use version control when we want to have parallel development (ie keep a stable, working master branch, and toy around in a dev branch). When you have a blog, you just use a _drafts folder that is configured so that what is inside is never published; when your post is ready you move it to the _public folder or whatever. Another worthless feature in that use case. What _is_ useful from a version control, and more specifically from git, is its ability to replicate everywhere: push to your personal backup, push to github, ush to your webserver. It is used both as a backup and as a way to have your content be where you distribute files. But git is not the only option availale to sync content, and far from the only one. A HTTP POST is more common, and a Dropbox sync is even easier (you don't have anything to do, and the content is automatically synced and distributed for free by Dropbox)