Oh Shit, Git?

I learned a long time ago never to invade Russia in winter and never to use git submodules.

Git doesn't compose.

Few things give me such a wonderful sense of a achievement than removing a git submodule from a repo, however.

I started using them again and it seems fine. You're ok as long as you use it for things like external library projects and not splitting your project repo into smaller bites just for the sake of doing it.

This please! Submodules are the only time I ever have real issues with git. I manually edit .gitmodules more than I care to admit, naturally this causes its own set of issues.

Hmmmm.... I think the main problem with git submodules is that if you google 'git submodule' you don't find anything useful. When you somehow discover how they actually work they are... uhm... let us say... 'usable'... Maybe someone should write a tutorial about git submodules that is actually informative.

> are people using git without frequently pushing to remote? I feel like having a remote backup of my work in progress is the killer feature.

I use git without a remote pretty often. When doing personal projects or exploratory work, the problem is either so trivial that I don't care about backup, or already backed up using something like Nextcloud/Syncthing. But having the commit history allows me to easily look at old code, revert changes, and make big structural changes without having to back up the entire project folder in case I end up disliking the new structure.

I guess you're just not working on many things at a scale where version control is useful but setting up an online repo doesn't seem worth the time.

A git remote is not a backup. I could make a mistake, force push the wrong thing to the wrong place and lose a bunch of stuff.

Not having a remote is the killer feature of DVCS.

I used to use local-only git often. But now that private repos on github are free and take two seconds to create, I keep online backups of everything.

There's a reason commit and push are two separate actions. That said, most people commit+push in the same keystroke.

git revert is my best friend.

It's not that it's hard or complex, it's that I really don't care about it and am not at all interested in learning. It's a weak attitude, I know, but I just can't help it.

So like most other developers, I go about my day totally not understanding git at all and when something weird happens, I talk to that co-worker know understands get (there's always at least one such psychopath on each dev team in existence) and ask him to fix it. He invariably talks about how easy and elegant git is and then finally gets around to giving me a couple commands with non-sensical names and options that fix the problem.

I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.

The problem with git is not that it's particularly hard to understand, it's that it's the wrong level of abstraction for day to day dev tasks. Git is a great data structure with an arguably bad CLI wrapper. What's missing is a layer of workflow rules specific to each repo. What names should branches have? What are the rules of engagement for PRs? Are rebases preferred over merges? Git doesn't care, nor should it. Yet there's more to creating a branch in a structured dev team than merely typing `git checkout -b new-branch`

Git might not be hard, it might be easy, but for someone who has not spent enough time trying to understand it, it gives options to royally F up if you don't know what you're doing. So I make it a point to never use any command other than cherry-pick. Everything else I use GitHub desktop for. Its a simple ui that only lets you do the bare minimum of git actions thats less F up prone.

Thats my personal story. The other problem I see is a large number of engineers who say git is not hard, it's very straightforward and they understand it very well, but actually they don't. And every once in a while they royally F up the entire repo and cause issues in deployment because of that. So git's main problem from my perspective is that it's an extremely advanced, unforgiving tool that gives a false sense of expertise to many mediocre programmers.

In some grand sense i think you're right, but your comment fails to appreciate the economics of the issue. I put computer algorithms to work on problems I want to solve; it advances my goals. On the other hand, Git puts me to work on problems that are a necessity of some external requirement or some other purpose in the category of "distraction": I get paid for the computer algorithms part, not the understanding Git part.

You are right it's not hard, it's complex. My problem is that my actual problems can be both hard and complex... and putting a complex distraction in the way detracts from my goals: not enhances it.

I think many in technology fail to appreciate this distinction. I often hear open source advocates respond to complaints about software quality jumping up to suggest opening issues or contributing fixes... which is fine in its own right: but if those issues/fixes aren't reasonably in line with my own goals in trying to use some class of tool... and some other solutions such as a closed source solution meet the goals more readily... I'm probably not going to spend my time advancing someone else's goals at the expense of my own.

" constantly trying to dispel the idea that git is too difficult "

If that's the case, why wouldn't you concede that it is?

"The problem has always come down to the missing attempt to understand the issue"

Isn't that always the case with misunderstanding something?

That 'it's common' and 'people misunderstand the issue' is essentially proof that at least from a certain level, 'git is hard'.

- Git is very powerful. Nobody doubts this. - Git is sometimes easier to understand when the model is well understood - yes, this is a common refrain.

But - it's still a very complex model, and the UI is bizarre + counter intuitive and as a command line, without a lot of visual reference.

Even standards and practices are not well established as there continue to be wars over idiomatic usage, arguments on HN often by 'experts' who actually make some mistakes in their argumentation.

I suspect a lot of people who think they are 'good at git' 1) don't realize how much they don't know and 2) maybe lacking in self-awareness as to how much trouble if often causes.

I've seen very smart people with very strong git skills befuddled far too often for me to believe the tool does not have problems.

The fact that 'Oh Shit Git' even exists, is in some ways problematic - because it's obviously not clear to many how to truly 'undo' things they've done. OSG could be 100x longer, easily.

Have a look here:

https://stackoverflow.com/questions/4114095/how-do-i-revert-...

This is really scary. It's not a complicated question necessarily, maybe a little specific - but - there are just so many answers, so many variables, incredible complexity in the answers.

Git has a kind of 'unbounded complexity' that allows for so, so many situations and uses cases. There really wasn't much 'Product thinking' rather, just a decade long cadence of 'let's add this feature with this flag' over and over again.

It's such an interesting case study from a Product perspective.

I think git is a very useful tool.

That said, the syntax is a little arcane, and it could benefit from a smoother user interface. (like most package managers)

As one example, I think the common commands could be separated out from the sort of back-end commands that only experienced users should use.

Code repository tools should be transparent, unfortunately Git very often stands between my changes and the repo. It's funny how other utilities (build pipelines/dependency management/deployments) became more user-friendly in all languages yet the step from SVN was a step in the wrong direction and all thanks to the 'cowboys' with an attitude of "let's use it as if we are a facebook/google or if Linus is using it - it's super cool" without understanding the context where they operate. I can hardly think of a dev tool that became mainstream yet brought so much inefficiency on such a scale into our everyday lives. And when they say 'oh just use these beautiful GUI tools' - oh, wow, we got the same set of tools we had 15 years ago - what an innovation, indeed!

The issue is that many developers don't care about learning to use version control effectively (as a biased git user would see it). They just see it as a means to an end, necessary evil for team projects, but overhead, mostly. They certainly don't want something they need to learn how to use (despite the fact that it's still relatively easy for novice users to do basic things).

Its not that it's conceptually hard, the interface just sucks. Like how is "checkout" both for switching branches and also for reverting files? And also it's completely counter to what a "checkout" means in every other VCS. It's just bizarre stuff like that. (I love git, but mercurials interface makes way more sense)

I think it's more that you have to know git "reflog" instead of some easier non-cryptic command

Git cannot fail, it can only be failed.

> One thing I hate is the pesky .DS_Store on Mac. No matter how many times I ignore it, it just wants to be a part of my commit.

Try a global gitignore: https://stackoverflow.com/questions/7335420/global-git-ignor...

Sounds like you already committed it before adding it to the gitignore. Here's a fix:

https://stackoverflow.com/questions/13541615/how-to-remove-f...

...but this shouldn't be a problem with a good git client such as Fork (git-fork.com) or SourceTree. They show you the changed files and let you select which ones to commit.

I would never commit anything without at least skimming the changes first.

.DS_Store is mostly a problem for me if I do my first commit without a .gitignore file, on a machine where I don't have a global .gitignore. In those cases you have to explicitly remove already-committed .DS_Store files from the repo before your new ignore settings will take effect.

Note that the two commands are not in general equivalent. Try `git add some-modified-file`, then change some line of the working file just "added". `git diff HEAD` will show the new change, whereas `git diff --staging` will not.