Comment by ackalker | Hacker News Reader

Comment by ackalker | Hacker News Reader

Parent Full thread

Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details?

Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings.

Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details.

Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.

That's why I said it was a "reminder" and not a perfect illustration. Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.

Even then, I personally find Git's interface confusing and inconsistent -- there are various examples of that with how you request help (usage) for various commands.

The only way I can personally tolerate using Git at the moment is via SourceTree or the GitHub web interface.

That's just my personal opinion of course and isn't necessarily a factual reflection of Git itself.

I've used various source code control systems over the years: sccs, perforce, bitkeeper, cvs, svn, bzr, mercurial, and so on to various degrees if that means anything. The one I've finally settled on for personal use has been mercurial, which I've generally found fits my own workflows the best and generally has an interface that seems to work without me having to think about it too much.

Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.

This perspective has root in Fred Brook's observation "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."

With that usage, you don't need to understand the implementation. But in my experience of using Git without really understanding it, there is about a 90% chance of destroying your repository when you try to revert something. I have never had this problem with any other VCS.

I'm sure simple reverting is super easy once you know what you're doing, but you need to know what you're doing.

Reverting a commit is trivial. There is zero opportunity of destroying a repo. From my notes,

# revert a commit

git revert dd61ab32

And yet every time I looked at the docs for git in the two or three years I was using it heavily I happened upon these dire warnings about destroying and losing work. I understand why git is so powerful, and to manage something as complex as the Linux kernel that power matters.

For what I do for a living it isn't, and Mercurial is a nice alternative that for whatever reason doesn't have any scary warnings in the docs about how I can destroy everything if I revert or rebase inappropriately, or whatever. Mercurial also seems a lot more aggressive about checking if I'm doing something stupid or dangerous and warning me about it, whereas git takes more of the traditional Unix "You Asked For It You Got It" philosophy.

Again: I understand why this is the case, but it's not the optimal tradeoff for me.

Well that does look simple, but first of all, it doesn't really revert a commit. It makes a new commit to cancel out the old one, or something. Not intuitive, unexpected results if you don't know what you're doing.

But the situation I got into was when I did something stupid and just wanted to undo it. Let me go back to an hour ago before I screwed up my project. That's not revert, it's reset, but reset only reverts the commit history, you really want reset --hard. And of course you need to be pointing to the right place for this to work, and there are other ways for it to go wrong. It might be hard to imagine if you're at all competent with Git, but trust me when I say you can get yourself into some very frustrating scenarios if you just Google "undo push" and blindly follow the instructions.

Here's another simple scenario: I'm working on a bug, my friend fixes it first and pushes his version. I just want to pull his changes and throw away whatever I was working on. Ok, so I find this: http://stackoverflow.com/questions/1125968/force-git-to-over...

Look how many different methods there are. Look how many warnings of "THIS WILL DELETE ALL UNTRACKED FILES" there are. Why is this necessary? I could rant for a while longer, but this stuff is so incredibly unfriendly and frustrating to newcomers. I don't want to think about this stuff, I just want to go back to the code.

Reply on news.ycombinator.com