Git is the most appropriately named piece of software, ever

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

 

[D H]

That's a lot of old technology!

Not really. I used RHEL, but I should have used CentOS. RHEL, CentOS, and Scientific Linux are pretty much the same beast. All ship with outrageously outdated software, and a sane sysadmin will often reject requests to update. The problem is that version a of one piece of system software will rely on a "feature" of version b of another piece of system software. Developers of that other piece of software later deem that "feature" to be a misfeature, or even worse, a bug, and remove it. Linux distros are carefully choreographed selections of specific versions of open source software. Updating one piece of system software may break something else, which is why sysadmins oftentimes reject update requests.

CentOS, Scientific Linux, and a host of other Linux distros all derive from Redhat Enterprise Linux. Redhat by choice takes a conservative approach, which makes their system software (and that of derivatives) oftentimes be quite old. That's fine for server farms that need extremely high reliability and very, very little downtime. That's not so fine elsewhere. We're looking to migrate our server (which doesn't need international banking level reliability) to Ubuntu.

It turns out our sysadmin intentionally downgraded git to 1.7.1 because another requested piece of "free" software for project management and issue tracking initially didn't support anything beyond that version of git. That constraint has gone away; we should be upgrading git "any day now".

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.

Underneath the hood, there's very little difference between Mercurial and git. Both are free, both are distributed version control systems. They differ somewhat in presentation to the user. There's a lot to be said for a distributed VCS, even in the case where the "official" version of the software is at some central repo. There almost always is a central repo, even with open source. As a linux distro developer, are you going to use J. Random Hacker's version of the linux core, or are you going to pull from https://www.kernel.org?

Subversion is nice in that it's interface is simple, and it is easy to use. Mercurial tried to emulate this ease-of-use. Ease-of-use (or lack thereof) isn't an issue with linux (do "man ls"), and hence it isn't an issue with git. That's my main gripe about git. Subversion isn't nice in a number of ways. It isn't a distributed VCS, it has these nasty things called "tree conflicts", and a move is a copy, add, and delete. (Aside: Even git occasionally reverts to subversion's stupidity in this regard. I recently moved a file in git, but instead of a rename I got a copy, add, and delete.)

 

[jim mcnamara]

Thought I would join in throwing stones at git by proxy:

http://xkcd.com/1597/#

 

[FactChecker]

Thought I would join in throwing stones at git by proxy:

http://xkcd.com/1597/#

Hitler uses git:

 

[DaveC426913]

Hitler uses git:

Aahahaha! That made my day.

And made me feel much better about myself.

 

[lox_and_whiskey]

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.

I don't know how you use it, but I've never had a problem.

1. git init
2. git add .
3. git commit -a
4. (repeat 3 as neccessary)

 

[JorisL]

I don't know how you use it, but I've never had a problem.

1. git init
2. git add .
3. git commit -a
4. (repeat 3 as neccessary)

That part is not very useful in a professional software development environment.
You need to be able to change a part of the code without pushing it to production. You still want to commit if you are working on something big (for a website you can think of rewriting the entire back-end this takes a lot of time). Then you want to test/beta the code.
Finally you are going to put it into the main branch when you are as sure as possible that nothing will break down.

 

[lox_and_whiskey]

That part is not very useful in a professional software development environment.
You need to be able to change a part of the code without pushing it to production. You still want to commit if you are working on something big (for a website you can think of rewriting the entire back-end this takes a lot of time). Then you want to test/beta the code.
Finally you are going to put it into the main branch when you are as sure as possible that nothing will break down.

Pretty sure git and all version control programs can do all of that.

 

[JorisL]

Pretty sure git and all version control programs can do all of that.

The issue is that git sometimes gives throws pretty vague to outright nonsensical errors.
Then you need to add some very specific options to fix the error which stopped you dead in your tracks.

 

[lox_and_whiskey]

The issue is that git sometimes gives throws pretty vague to outright nonsensical errors.
Then you need to add some very specific options to fix the error which stopped you dead in your tracks.

Well, if someone doesn't care about performance, easy merges, or not needing a server, I don't know exactly why they're using git. If you don't write a lot of code, and someone else does your merges, and someone else has a server for you, why don't you use cvs or something? If git has what you want, then I'm sure you can get used to a few vague error messages. Which google will make unvague anyway.

 

[PeterDonis]

I don't know how you use it, but I've never had a problem.

1. git init
2. git add .
3. git commit -a
4. (repeat 3 as neccessary)

First, a nitpick: the -a in 3 is redundant if you've already done 2 (since the -a option just does what git add . would do). Or you could leave out 2 altogether and use the -a in 3.

That said, if this is the only workflow you ever use, you don't really need git; any DVCS will do. (I actually find Mercurial easier to use for simple workflows like this.) Git is optimized for projects with workflows much more complicated than this: projects with multiple lines of development and maintenance going on in parallel, where different feature branches might need to be merged during development before ever touching a production branch, where there might be multiple "production" branches getting different subsets of fixes, etc. The Linux kernel, of course, is the archetypal example, since it's what drove the development of git in the first place. If you haven't worked on such a project, it's extremely difficult to imagine how useful git's powerful features are, since you've never experienced the situations for which they were designed.