Git is the most appropriately named piece of software, ever

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

 

[lox_and_whiskey]

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.

I suppose I prefer to use one VCS, and git can do anything. In addition to making massively parallel development much easier, as you say, simple workflows are easy too. And someday I might work on a huge project and i'll already know git.

 

[nikkkom]

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

The point is, revision management IS surprisingly hard.
First attempts at writing revision control tools were disasters.
Attempts which followed were disasters.
Attempts which followed *that* were somewhat less disastrous disasters.

Git was the *first* revision management tools which is not a disaster. (Maybe because it was initiated by a brilliant programmer, who also waited some five years using other revision control systems to understand what are the problems).

In this thread I see legitimate complaints that documentation is somewhat cryptic and in other places too terse.

The rest looks like venting, not trying to pinpoint problems.
"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)."
Thanks for the ranting, how is the functionality which you don't need and don't use, a problem?
"Not user friendly"
This is not informative.

 

[lox_and_whiskey]

Git was the *first* revision management tools which is not a disaster.

 

[Lord Crc]

Git has a horrible user interface. I never feel Git works for me. Using it is tedious and error prone.

I don't find that surprising given its heritage. I'm just hoping someone will fork it and think about the users, like Mercurial has.

 

[MarneMath]

I've used GIT and SVN and out of those two I heavily prefer Git. SVN while initially easier to get up and running builds up errors the longer you have something in production. Merges in SVN across multiple sources has always been a pain for me. Git is rather good at this. With that said, Git is painful to learn if you have to learn it on your own. The people I've encountered who hate Git the most are also the people who tried to the read the man pages(if one can even say Git has man pages.). It's pain to learn on your own and easy to get lose in the flexibility that Git offers. Unfortunately the flexibility tends to give people headaches because it's extremely annoying to chase down all the possible problems with your actions. Git is my go to version control when I need to manage the workflow of 10-20 developers on production level code.

As a side note, Mercurial seems pretty cool for most task, but is a bit to inflexible for my needs. Also I can't for the life of me understand why deleting a branch took me an entire day. I later found out that the preferred method is by tagging instead of branching. Other then that yay for Mercurial :).

 

[lox_and_whiskey]

Git has a horrible user interface. I never feel Git works for me. Using it is tedious and error prone.

I don't find that surprising given its heritage. I'm just hoping someone will fork it and think about the users, like Mercurial has.

I've never had any error that google didn't tell me the answer in a few seconds.

 

[lox_and_whiskey]

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.

Do you understand the following?

Basic syntax of git pull is, and the first line of the manpage:

git pull [<repository>]

Or you can put a default in the config.

 

[PeterDonis]

I've never had any error that google didn't tell me the answer in a few seconds.

And as the saying goes, "Everyone generalizes from one example. At least, I do."

 

[Lord Crc]

I've never had any error that google didn't tell me the answer in a few seconds.

Yeah, except by the time you get the error you might have messed up bad.

My point is there is no good reason why git could not have a nice user interface, like Mercurial has. This would also make it less error prone.

 

[D H]

Git was the *first* revision management tools which is not a disaster.

This is very incorrect. Good version management tools existed long before git was created. What can be said in favor of git is that it is the first distributed version management that was popular. VHS was popular. That does not mean it was good.

My point is there is no good reason why git could not have a nice user interface, like Mercurial has. This would also make it less error prone.

Exactly.

git plays a large role in why stackoverflow.com is such a popular website.

That git questions rank so highly on stackoverflow.com does not mean that git is good. It means that git is VHS. Mercurial, unfortunately, is the easier to use and higher fidelity but much less successful Beta.