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.

 

[D H]

Not sure about that. Did technical writers review much of the gnu tools or other linux documentation?

Actually, yes, they did. We programmers get too caught up in our own code. The people who can write code well and the people who can describe in clear terms what that code does are very different classes of people. The GNU Foundation and linux.com want and need technical writers to help them with their documentation. For example, see https://www.linux.com/learn/docs/682542-careers-in-linux-technical-writing. There are many, many more such examples of calls for help from the technical writing community.

Moreover, the authors of the GNU and Linux documentation had a great example, the POSIX documentation. It's not perfect (nothing is), but a great deal of technical writing effort went into making that POSIX documentation very, very good.

 

[Carno Raar]

If you are not liking git and need a distributed VCS, the only mainstream alternative is mercurial (or possibly bitkeeper). What do you feel about it?

 

[D H]

Here's an interesting git problem. The machine on which we store our repositories uses an ancient version of git, git version 1.7.1. My machine has a modern version of git. When I make a clone of a certain repo and cd into the clone, git status says that a boatload of files have been changed.

I haven't changed a thing.

The repo was populated from a machine that uses CRLF line endings. My machine natively uses LF line endings, but the checked-out files are true to the source: They have CRLF line endings. That's what's in the repo, that's what's in the checked-out files. So why does git say everything has changed? How can I fix this?

Note well: Those CRLF line endings need to be there. The target is an industry that only uses machines that use CRLF line endings.

 

[Borg]

Here's an interesting git problem. The machine on which we store our repositories uses an ancient version of git, git version 1.7.1. My machine has a modern version of git. When I make a clone of a certain repo and cd into the clone, git status says that a boatload of files have been changed.

I haven't changed a thing.

The repo was populated from a machine that uses CRLF line endings. My machine natively uses LF line endings, but the checked-out files are true to the source: They have CRLF line endings. That's what's in the repo, that's what's in the checked-out files. So why does git say everything has changed? How can I fix this?

Note well: Those CRLF line endings need to be there. The target is an industry that only uses machines that use CRLF line endings.

http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf
Check out the section starting with "Git has two modes of how it treats line endings".

 

[D H]

http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf
Check out the section starting with "Git has two modes of how it treats line endings".

I've been there. Didn't work.

Apparently I'm running into an Eclipse bug, https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372. From what I've read, the Eclipse git plugin bypasses git attributes and forces files with CRLF endings to be checked into the repo with those CRLF line endings intact. This massively confuses git. When I clone the repo, git status tells me every text file has been changed.

 

[Carno Raar]

Eclipse is the IDE that puts people off IDEs. It's terrible and you my sympathy if you have to use it.

http://imgur.com/eA0qDjO

Now you say Eclipse doesn't work with git properly. I am not sure whether to laugh or cry.

 

[Borg]

I've been there. Didn't work.

Apparently I'm running into an Eclipse bug, https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372. From what I've read, the Eclipse git plugin bypasses git attributes and forces files with CRLF endings to be checked into the repo with those CRLF line endings intact. This massively confuses git. When I clone the repo, git status tells me every text file has been changed.

I'm using IntelliJ 14 and it looks like it might have similar issues. When I checked the available settings, it only has a checkable warning to "Warn if CRLF line separators are about to be committed". I couldn't find anything other than that one setting. IntelliJ does allow you to specify the git program rather than to run the one that comes with it. Maybe that's an option in Eclipse?

 

[D H]

Maybe that's an option in Eclipse?

I don't know. I'm not the one who used Eclipse to push to the repo. I don't like IDEs, so I don't use them.

 

[Borg]

I don't know. I'm not the one who used Eclipse to push to the repo. I don't like IDEs, so I don't use them.

Ah. I misunderstood when you said that you were running into an Eclipse bug.

 

[Carno Raar]

Back to topic, I am not sure this is a problem with git itself. It seems to be Eclipse being Eclipse.

 

[D H]

Back to topic, I am not sure this is a problem with git itself. It seems to be Eclipse being Eclipse.

I would argue otherwise. git is trying to be smart, but in the end that makes it is worse than dumb.

My puppy analogy: When you have a puppy that's just a few months old (think subversion), it's going to make messes on the floor. It's inevitable, and you need to learn how to deal with those puddles (and worse) that your puppy (or software) deposits on the floor. In contrast, a five year old dog will hold its bladder and its bowels forever. The dog would rather almost die as opposed to doing something that displeases its master. It will *not* make messes on the floor. Your nine month old puppy: You've house-trained it, and it hasn't left a mess on the floor for months. This lulls you into a false sense of security. That nine month old puppy well let loose when you least expect it to do so.

Git is a nine month old puppy. It behaves nicely almost all the time, but suddenly, blam! You've got a mess to clean up.

 

[Carno Raar]

I would argue otherwise. git is trying to be smart, but in the end that makes it is worse than dumb..

It works from the command line. The syntax of the command line might be arcane, but it's well documented. From memory you want to look at core.autocrlf.

How it can not be an IDE issue if the IDE messes it up?

 

[D H]

It works from the command line. The syntax of the command line might be arcane, but it's well documented. From memory you want to look at core.autocrlf.

The repo is on an RHEL server (RHEL = right out of HEL? Yet another aptly named piece of work), which ships with git version 1.7.1. That's a rather archaic version of git, one that is fundamentally broken as far as I'm concerned. It doesn't recognize lots of things (apparently including core.autocrlf) that are handled by more modern versions of git.

 

[Carno Raar]

That's a lot of old technology!

I am wondering why git was chosen. Generally one picks git when everyone is able to branch and pull and you don't have a single centralised repo. Your organisation, along with many commerical outfits, sounds like it would be happier with a centralised system and single release manager. Something like SVN or Mercurial. Do you have a tech lead with full authority over the project (yay!), or is there a non-technical manager (time to find a new job!)?

Git is indeed hard to learn, but it only takes a few hours (read one book) and it does work when everything's up to date and your technology stack is sane. You shouldn't have to learn that workflow, but practicality beats purity. Try learning how to build docker images if you want to see something hilariously broken. :-)

 

[PeterDonis]

Your organisation, along with many commerical outfits, sounds like it would be happier with a centralised system and single release manager. Something like SVN or Mercurial.

Mercurial is a distributed VCS, just like git. But a DVCS can still be used in a centralized workflow; you just need to control access to the "official" copy of the repository. Python does this using Mercurial. For that matter, the Linux kernel does it using git.