Comment by swagonomixxx | Hacker News Reader

Comment by swagonomixxx | Hacker News Reader

> A Git-compatible DVCS that is both simple and powerful

We all know the dig here - Git is not simple.

Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago.

Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly because version control _is_ complex.

I also don't agree that Git is hard to use. I feel it is an odd goal to try to make everything - even tools that experts use - simple to use, when they are fundamentally not simple. I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.

> I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.

Perhaps the biggest mistake (IMO) was to expose the index to the user. I happened to just watch https://www.youtube.com/watch?v=31XZYMjg93o (by the person behind Gitless). They explain the issues well there.

I haven’t watched that video, but I agree — the index is one of the biggest hurdles to making git easy to understand and use for newcomers. It’s not hard to explain the fundamental model of how git works — it’s hard to explain the UI, and it’s hard to explain the index. If you remove the index, you’re only working with commits, and that simplifies the UI enormously.

I'm gonna watch this video. What's been bugging me for a long time, as someone who didn't quite get to see all of the supposed ugliness of Subversion (which by description alone sounds an awful lot like the rerere situation with Git, which I have).

It really feels to me like a commit identifier should be the combination of a monotonically increasing number and a hash of the content, rather than an either-or. If I merge or rebase branches in git, I lose the index, just as I would in subversion. But at least in svn I have some notion of how far back commit 12345 is in the tree. ac4def2 could be HEAD or four years ago.

> They told me offline use was a big advantage of git over svn. But, how are you supposed to use git without Google?

Shots fired.

I am by all accounts the SME on git at my company. I often am the VCS expert at my company. I don't like using tools I don't understand, and my brain is pretty good at handling problems that look like graph theory.

After using git for 6 years git still terrifies me. After 9 months of svn I performed open heart surgery to remove a 1GB zip file that some dummy merged before anyone thought to stop him. It was at least 18 months before I tried something similar with git and I made copies of my copies to make sure I didn't fuck it up. And I still almost needed a do-over.

The level of dread I have using git is pretty close to how I feel when using a newly sharpened chef's knife - hypervigilance. And that feeling gets stronger when I hand that knife to someone else. Be very careful, that's super sharp... hold still, I'll get you a bandaid. Now you get a mini lecture on how to hold a knife without cutting yourself next time.

It's not that hard man. Really isn't. Your anecdote sounds like someone who thinks they're awesome at git setting a noob up for failure and then mansplaining when they fuck up.

It's not hard to be better at git than 85% of people, most devs I've met don't understand the basics beyond pull commit push.

You don't get to work on a git repository by yourself.

It must be admitted that if merges are involved, it becomes somewhat harder to do something like this, as you can no longer use the easy and safe path of an interactive rebase to edit the commit and remove the file, and must reach for filter-branch or similar, which are generally a good deal scarier and easier to make difficult-to-identify mistakes with. (Fortunately, the man page git-filter-branch(1) deals with this specific case as its first example.)

But it’s certainly not the easiest thing to mess up a Git repository to the point of losing data; the reflog keeps it all intact for at least a month unless you very deliberately tell it not to (see the “CHECKLIST FOR SHRINKING A REPOSITORY” section of git-filter-branch(1) for sample invocations after such an edit), and I’d be much more comfortable about open heart surgery on Git’s model than on SVN’s.

Almost all of the complexity of VCS is in or around merges. Take away accidental complexity and there is a lot of inherent complexity in merges.

First git project we had a guy who was bad at merges, and his solution was to avoid them as long as he could, which just made things worse. He also disliked another engineer. That engineer was definitely making mistakes but at the end of the day his Dunning Krueger was causing me less trouble than merge boy’s. Also suspect a little ageism, but would not have been able to defend that suspicion.

So one day merge boy was loudly exclaiming that old guy had written a terrible bug and the hit history proved it. Only the bug in question was something I specifically looked for in the code review, and had been happy to find that he had gotten it right. But here in git annotate it shows he got it wrong. What the hell?

So I step through the commit history one commit at a time, sure enough the code was initially correct… until merge boy did a merge and fucked up the three way. Again. And got old guy’s name to show up in annotate. I didn’t even know you could do that.

I hear you, definitely can get tricky. But again, it isn't that hard.

Reply on news.ycombinator.com