Git is the most appropriately named piece of software, ever

[D H]

So why has it caught on so mightily?

Git is arguably the most popular revision control software out there. Why?

I have an occasionally like, but more often hate relation git. If there was a command "git make-salsa", it would tell me to open a can of tomato soup. Voila!

Git aficionados will tell me the problem is in me rather than the tool: "You aren't using the right workflow!"

In this case, the right workflow means using "git make-salsa --rebase chopped-fresh-tomatos --add chopped-onion --add squeezed-lemon --add chopped-jalapeños --add secret-ingredients". What about those "secret-ingredients"? "git help <command>" inevitable says something about those "secret ingredients". They typically involve words such as "default glob refspec".

As a user, I personally find it almost unusable. I have to ask others what the "--secret-ingredients" recipe is for this command, that command, and many times, they turn out get it wrong because they too aren't "using the right workflow".

And yes, this was a rant.

 

[nsaspook]

Git is one of those tools you love or hate.
http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds
http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/

 

[D H]

Git is one of those tools you love or hate.

Generally, it's hate, for me. The documentation is so bad, so very, very bad. For example, the one-liner summary for git push is "Update remote refs along with associated objects." Similarly, the one-liner for git rebase is "Forward-port local commits to the updated upstream head." Seriously? What in the world does that mean? Reading the details on any git command drives me even crazier. It appears to me that they didn't just out of there way to write gobbledygook; it's as if they mandated gobbledygook. I can envision the behind-the-scenes conversation: "Someone suggested we say that git push 'uploads changes from your local repository to the remote repository'. What do you think?" "Oh, no. We can't say that! That's plain English! We can't use plain English; it's against the rules."

 

[nsaspook]

It's software originally written by a systems programmer for other systems programmers where the documentation was the code base. The basic concept for git is different from most revision systems, there is in effect is not a remote repository that you check in and out files as you work.
http://git-scm.com/book/en/v2/Getting-Started-Git-Basics

 

[D H]

Of course there are remote repositories in git. You are perhaps thinking I wrote "central" rather than "remote". I didn't. I wrote "remote".

git is a distributed revision control system; it doesn't enforce the concept of a central repository. I like that basic concept of distributed revision control. That there can be multiple repositories is a central concept in git. That there are remote repositories is the whole point of git clone, git push, git pull, git remote, git branch -r, etc. Note that "remote" might mean anything from some other git repo on my local machine to a git repo on a machine at my antipode (the point opposite the Earth to me).

The problem I have with git is how they implemented the concept, not the concept itself.

 

[nsaspook]

I hear what you're saying about cryptic help and have had a few 'fast-forward' gotchas but in the end it works better than just about anything else for looking at revisions when tracking down some obscure regression.
You can always use a friendly front-end for the command line.
http://git-scm.com/downloads/guis

I'm currently using NetBeans IDE for most projects. The current version has integrated git support.
https://netbeans.org/kb/docs/ide/git.html

 

[D H]

There are some things that I dislike even more than git. GUIs and IDEs, for example.

I like descriptive words, descriptive commands. Icons don't speak to me, and when they do (e.g., via alt text), it's usually lousy. More often, it's nonexistent. I like to see what the system is going to do to me. GUIs and IDEs hide all that from me. I like to keep my fingers on the keyboard. I can type far faster than I can mouse, and just typing (no mousing) let's me keep my thought processes intact.

 

[nsaspook]

Coming from a command line/VI background I don't use the mouse much either but NetBeans has remote host compile capabilities that let's you develop on embedded Linux systems with limited power from a much more capable host, that's a big win for what I do.

 

[DaveC426913]

Hate.

I just quit my job over GIT.

I pulled my hair out one too many times over some stupid can't-go-forward-can't-go-back logical nonsense, and got written up for it.

I had to get out of that stupid environment. Started my new job on Monday.

Still hate GIT.

 

[nsaspook]

Hate.
...
Still hate GIT.

Can I put you down as undecided?

 

[FactChecker]

I am curious about what the git haters prefer to git and why. I like git, but my only other option for version control (due to company policies) is creating a new directory structure for each version. So I was thrilled a month ago when we were allowed to install git. I only use it for my individual work. I don't put it to much of a strenuous test.

 

[TheDemx27]

First off, I'm so glad I'm not the only one who feels befuddled by the more complex functions of git. If I ever start doing anything more complicated than a simple push, I pull out the GUI, simply because I don't feel like learning all the command lingo.

"Someone suggested we say that git push 'uploads changes from your local repository to the remote repository'. What do you think?" "Oh, no. We can't say that! That's plain English! We can't use plain English; it's against the rules."

Best thing I've read today.
I once tried reading the official documentation, then I started wondering why I was wasting my time on that rather than writing code. Maybe I'm not proficient enough at "computering".

tbh I don't really code too much, but when I do, I find the source control part the most tedious.

Relevent:

 

[fluidistic]

Hopefully this can help: http://resrc.io/list/10/list-of-free-programming-books/#git.
I use github mostly as a back up and quick share between my desktop pc and laptop. I'm slowly self learning programming and to me the git system is easier than programming itself even though it is an extreme pain to learn.
I probably misuse it sometimes. For example when I want to contribute to one of my repository that I started on my deskptop pc, from my laptop. I write a file, then git add nameoffile.extension, then git commit -m "x commit", git push origin master and bam I get an error, I must first pull... And pulling means downloading the whole repository on my laptop while I don't want to do this at all since my repository is a bunch of non related random data/stuff. So I pull and then push and then I delete all the files on my laptop but the one I just uploaded. I'm guessing it's a bad habit and that I'm misusing git here...

 

[DaveC426913]

I am curious about what the git haters prefer to git and why. I like git, but my only other option for version control (due to company policies) is creating a new directory structure for each version. So I was thrilled a month ago when we were allowed to install git. I only use it for my individual work. I don't put it to much of a strenuous test.

There's no question that it's powerful - pretty much the most powerful tool there is for version control.

But is all that power worth the crushed souls of users it leaves in its wake?

 

[FactChecker]

There's no question that it's powerful - pretty much the most powerful tool there is for version control.

But is all that power worth the crushed souls of users it leaves in its wake?

Well, when you put it that way, no.

 

[DaveC426913]

My Facebook wall, not 25 days ago (10 days before I quit):

In a thousand million billion years, I will never understand GIT.

> GIT push
"Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. 'git pull ...') before pushing again.

> GIT pull
"There is no tracking information for the current branch."

These are actually CONTRADICTORY.

 

[Psinter]

Ugh, tell me about it . The words it uses are not intuitive. They are more like counter intuitive. Anyhow, the best tutorial I found for extremely slow people like me is:

https://www.atlassian.com/git/tutorials/

Very good tutorial, I recommend it. Simple and to the point.

Hate.

I just quit my job over GIT.

I pulled my hair out one too many times over some stupid can't-go-forward-can't-go-back logical nonsense, and got written up for it.

I had to get out of that stupid environment. Started my new job on Monday.

Still hate GIT.

I was told at uni: "Put all your projects at GitHub. Employers like when you show them that you've worked at teams with someone and have the evidence there" and I replied with: "Guess who's not getting a job then."

 

[D H]

I am curious about what the git haters prefer to git and why.

I've used so many different revision control systems. The very first one I used, SCCS, had a widespread pronunciation. Just add a "U" after the "S" and pronounce. RCS, well it SCCS RCS (just fill in the missing vowels). Progeny of SCCS and RCS such as CVS and subversion -- each of them also offered some hateful "features". Clearcase is a very nice tool from IBM's perspective; it earns them a nice chunk of change. Most others have a rather different perspective of clearcase.

In short, every revision control system I've worked with SCCS RCS in one way or another.

I've played a bit with Mercurial (hg), and I liked what I saw. That wasn't a real test. The rock sucking commences only after deploying a revision control system on a real project with multiple authors. And then it's too late.

My biggest problems with git:
- The documentation SCCS.
- Almost every command needs just the right --secret-sauce option to make it work.
- Sometimes git just says "no". No amount of coercion, no --force option works. And you are stuck.

 

[FactChecker]

In short, every revision control system I've worked with SCCS RCS in one way or another.

I've played a bit with Mercurial (hg), and I liked what I saw. That wasn't a real test. The rock sucking commences only after deploying a revision control system on a real project with multiple authors. And then it's too late.
.

It sounds like you would currently recommend looking at Mercurial, but you are not optimistic. Thanks for the input.

PS. It's just an academic question on my part. I'm only allowed to use git and I only use it for my own work. I can't stand using nothing.

 

[D H]

It sounds like you would currently recommend looking at Mercurial, but you are not optimistic. Thanks for the input.

I'm not optimistic because playing around a version control system doesn't expose you to the real fun to be had with that system once it is used in a real-world setting.

I'm using "fun" a bit sarcastically here. In this sense, running into a concrete wall is "fun". When that gets tiring, one can apply newly learned karate techniques against said concrete wall. Even more fun! All of that pales in comparison to the real fun that can be had with version control software.

That applies to any and every version control system I've used. I have zero expectations that Mercurial somehow manages to avoid that "fun". In fact, I know that it hasn't. There's a very popular Q&A website that I won't mention by name (Greg doesn't like mentions of that website) whose popularity would be far smaller if it wasn't for all the fun that version control systems foist on their users. A huge number of questions at that site involve people having fun with git, but also a good share about fun with Mercurial.

A lot of the fun is self-induced (or team-induced), but it happens. For example,

• Someone once committed a test script that contains, in clear text, a user name and password to a secure site. This happened a long time ago; that file is in every user's repo.
• Someone didn't set their filters correctly and has been committing compiled and linked executables to a test directory. The official tests don't use that directory, so the problem wasn't noticed until someone complained about the many hours it takes to make a fresh clone the repo.
• Someone did a bad octopus merge that has turned the repo into a tangled mess.

You would like to completely erase those from the repo, each and every instance of them. Have fun!

I can't stand using nothing.

That's the real problem. While they're all bad in their own unique ways, not using anything is worse, much, much worse. The amount of fun to be had when one doesn't use version control at all is mind boggling.

 

[Arsenic&Lace]

Git is pretty nasty, but it's popular because Linus Torvalds is behind it. I've heard fossil is nice for smaller projects:
http://fossil-scm.org/index.html/doc/trunk/www/index.wiki

 

[jbunniii]

I'm about to change jobs. One of the best things about this change is that I will no longer have to deal with Git, as the new employer uses Perforce. It's like being bumped from a middle seat near the toilet in the coach section, up to first class.

 

[Carno Raar]

What are the specific problems people are having with git?

Are they covered in the enhanced documentation on the website? (https://git-scm.com/docs)

If not, I would be interested in building a list of issues.

 

[D H]

What are the specific problems people are having with git?

• Not user friendly (user hostile is a better description).
• Poorly written documentation.
• A large number of commands, made even larger by the fact that git foo --this-obscure-option does something very different than does git foo --this-obscure-option.
• Far too easy to get stuck in no-man's land.
• Far too easy to use it wrong.
• The primary use case (supporting linux development) drives a bizarre workflow.

The last item is key in why git is so reviled by some. Most software developers aren't working on a linux-like development project. This use case is what makes git so big, so hard to use. Even most open source projects don't follow the git workflow. Github certainly doesn't.

Are they covered in the enhanced documentation on the website?

No. As far as I can tell, the enhanced documentation contains exactly the same content as the man pages, just pretty-printed.

If not, I would be interested in building a list of issues.

Issue #1: Rewrite git from the bottom up with ease of use as the driving factor.
Issue #2: Have technical writers review the documentation.

 

[Carno Raar]

No. As far as I can tell, the enhanced documentation contains exactly the same content as the man pages, just pretty-printed.

What about the book (also on the website)?

So this is about the way it does things, and not that you can't do things?

 

[Mark44]

A large number of commands, made even larger by the fact that git foo --this-obscure-option does something very different than does git foo --this-obscure-option.

I don't see any difference between the two, other than that the latter has a period at the end, which I believe is just punctuation for the sentence, and not meant to be part of the git command. What am I missing?

 

[arivero]

It this the string theory of control version systems

 

[PeterDonis]

I think git is best viewed as an extremely powerful version control engine overlaid by a horrible UI. I prefer Mercurial, whose engine is similar to git's (there are ways in which git's is more powerful, but they probably don't matter for many use cases), and whose UI is much friendlier, at least for me.

 

[PeterDonis]

Rewrite git from the bottom up with ease of use as the driving factor.

I think this is better viewed as "rewrite the git UI from the bottom up with ease of use as the driving factor". I don't think the git engine needs to be rewritten. The problem is that the UI is basically a direct mapping of engine features to git commands; i.e., it's driven by how the engine is constructed, instead of being driven by what's easy for the user.

In fact, if you find the Mercurial UI easier, as I do, all of the hard work has already been done; Mercurial has a git plugin that let's you use the Mercurial UI to interact with git repositories.

 

[D H]

What about the book (also on the website)?

I'll admit: I haven't read the book. I don't want to read "the book." Revision management shouldn't be that hard.

I have read the documentation. Once again, revision management shouldn't be that hard.

I've also read (and compared) the online documentation and the command line documentation. BTW, there's a bug in the DISCUSSION section in http://git-scm.com/docs/git-reset. The presentation of the tables is all messed up. (Compare with git help reset on a unix command line.) There's a deeper bug in the the DISCUSSION section of the corresponding man page. It's gobbledygook. That gobbledygook is everywhere in the git documentation, and this is my key complaint about git.

So this is about the way it does things, and not that you can't do things?

Git can do lots and lots of things. It could probably shine my wingtip dress shoes. I wear those shoes once a year or so. I can live just fine without my wingtips. I can also live just fine without all the fancy stuff git can do for me (or in too many cases, do to me). Revision management isn't as hard as git makes it out to be.

I don't see any difference between the two, other than that the latter has a period at the end, which I believe is just punctuation for the sentence, and not meant to be part of the git command. What am I missing?

Maybe I wasn't explicit enough. There are a large number of git commands. Some of those individual commands are in fact multiple commands, disguised by distinct options to the command. The command arguments hide this duplicitousness. After accounting for this duplicitousness, there aren't just a large number of git commands. There are a huge number of git commands. Revision management isn't nearly as hard as git makes it out to be.

I think git is best viewed as an extremely powerful version control engine overlaid by a horrible UI. I prefer Mercurial, whose engine is similar to git's (there are ways in which git's is more powerful, but they probably don't matter for many use cases), and whose UI is much friendlier, at least for me.

To some extent, a good GUI can patch over the convoluted weaknesses in git. I don't like GUIs and IDEs, so that's no help to me. Even if I was to use a GUI, the GUI has to make certain assumptions regarding how to use git. For example, are merges done with the option --ff or --no-ff? Using --no-ff would be my preference. The default value, --ff, is broken (in my opinion). That's my opinion of course; there are religious wars over this particular issue.

 

[Borg]

I thought that someone had already mentioned it but apparently not. Several of our developers use TortoiseGit to deal with it and I've been told that it's very much like the TortoiseSVN version if you've used that before. I haven't tried it because I've been using my IDE to connect and I don't have to do anything advanced. However, the people who are using it have been very happy with it.

 

[PeterDonis]

Even if I was to use a GUI, the GUI has to make certain assumptions regarding how to use git. For example, are merges done with the option --ff or --no-ff?

You're assuming that the GUI is just a layer over the existing set of commands for the "git" executable. But the "git" executable is not the same as the git engine I was referring to; the "git" executable is just the (horrible) current UI for that engine. Building a new UI in no way requires you to use the same command set as the current UI.

In other words, a UI does have to make certain assumptions about how to use the git engine. But it doesn't have to make any assumptions about how to use the commands that are in the current "git" executable; it can implement a different set of commands altogether.

 

[bcrowell]

In short, every revision control system I've worked with SCCS RCS in one way or another.

Before git, I used CVS and subversion. They sucked. Git sucks less. Way less.

Git can indeed be confusing, especially its error messages. It helps if you understand the underlying model well, and there are books that explain it well. I only use git for very simple things, so my brain doesn't get enough of a workout to make it remember the underlying model clearly. However, when I get confused, I have a silly strategy that works quite well in practice. I google for what I want, and look for hits on stackexchange. There is always a question that asks exactly what I wanted to know, with multiple answers explaining it in different ways.

 

[rollingstein]

• Not user friendly (user hostile is a better description).

Which users are we talking about, is the key variable. My mom thinks the linux command line is user hostile. I love it. Different things delight different users.

Looking at gits adoption there does seem a set of people that love it? Maybe it's just a case of you using the wrong tool for your use case & taste?

 

[rollingstein]

Issue #2: Have technical writers review the documentation.

Not sure about that. Did technical writers review much of the gnu tools or other linux documentation? But it seems to have turned out fine. I sure like it much better than the manual that came with my car. And that *was* written by professional technical writers.