Git is the most appropriately named piece of software, ever

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

 

[nikkkom]

This is very incorrect. Good version management tools existed long before git was created.

So please name one.

 

[nsaspook]

https://arstechnica.com/information...ing-git-creating-1760-windows-builds-per-day/

Back in February, Microsoft made the surprising announcement that the Windows development team was going to move to using the open source Git version control system for Windows development. A little over three months after that first revelation, and about 90 percent of the Windows engineering team has made the switch.

 

[nikkkom]

So please name one.

Nothing?

 

[FactChecker]

Which version management systems are "good" is not well defined and is very debatable. But there have been dozens of systems that were much, much better than nothing.

 

[nikkkom]

I grant you than, for example, CVS is better than nothing. It does not make it "good" by any measure.

 

[Lord Crc]

I wouldn't label SVN "a disaster". We use it at work, and I've used it in several open source projects over the years, and while it can be a bit slow at times I've never lost code or anything like that due to SVN.

Git has too many internal implementation details leaking up into the user interface, and the user interface is obscure and error prone. Unlike with SVN I have lost code with Git. I'm pretty sure the core is better than say SVN, but it's draped in a thick layer of dang.

 

[DaveC426913]

Git has too many internal implementation details leaking up into the user interface, and the user interface is obscure and error prone.

The way I look at it, GIT is the implementation layer (analogous to DOS of yore). It does what it's supposed to do quite well. But it was never meant to be user-friendly.

It was always meant to have a user-friendly layer on top of it. It's just that no one seems to have come along and created one that gained sufficient popularity.

 

[onoturtle]

Sounds like I managed to dodge the bullet on difficulties with git :) I used it in my previous job for about 3 years. But I was a data scientist rather than a software engineer so it was likely other people who had to deal with the larger issues of our repos. It was easy enough to do the basic things of push, pull, create/switch branches. I did merge two branches once and that was successful. I was nervous about that because I recall how the engineers in a different previous job dreaded doing merges with Perforce (granted in their case they were merging several dev branches rather than my measly two).

But I agree the documentation is poor and I often just looked for tutorials online that are written more naturally. That's good enough for basic usage but I imagine there might not be much written for corner cases. I also thought undoing a push was a little wacky.

 

[FactChecker]

Git is very helpful for my personal use. If I limited myself to basic operations provided by the GUI, gitk, and a set of basic commands, I didn't get in trouble with Git. But any time I tried something new, I had to copy everything to a safe place.