Git is the most appropriately named piece of software, ever

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