Hacker News Reader

Comment by dcre | Hacker News Reader

I love Git, but I'm pretty sure there's no way to explain it simply.

I don't get this attitude. The DAG is exceedingly simple and I think can be taught reasonably in only a few minutes. From there you really only need to teach a very minor amount of the UI, and teach the user how to perform "I want to do this to the DAG"=>"This is what I type" translations on their own. I've seen all of this done well in sub-hour presentations.

Mercurial on the other hand has a pain in the ass datamodel (so much so that most introductions to it that I have seen do not even approach the topic), so you actually do have to learn all of the UI commands to get an idea of what can be done and what cannot be done. It is far more complex than git.

I really cannot think of a simpler VCS than git. I've used plenty, but never got off the ground faster with anything else.

Git is simpler than any other VCS, but VCS itself is not simple concept to understand. That's what he's saying, and I agree. I use git all the time, but it's not easy to understand the whole version control thing as a beginner. Also Git is not just about DAG, you need to be able to understand the decentralized nature, etc. In that sense, some people may find SVN easier to understand.

Exactly what I meant. If you're working with people who need to learn what a DAG is in the first place, that adds some overhead. After that you still need to understand that your working directory is just a scratchpad, and branches aren't actually like real-life tree branches but instead they're pointers to the ends of those real-life branches, etc. Not exactly simple.

Conceptually speaking, a centralized VCS -- one where you check out files, make changes, and check files back in when you're done -- is vastly simpler than Git. Sure, it's also much less powerful (and I would choose Git a million times over such a system), but it's definitely simpler.

I agree with the model being great. The git command itself is abominably baroque in its user interface (inconsistencies and strange defaults abound), but I've gotten over that with more effort than I'd like to admit.

I love Git's plumbing; I just hate its porcelain.

Eh, I guess I just sort of see hating the porcelain like hating the parens in Lisp.

One of the great reasons to use Haskell instead :D

People who refuse to see the ugliness in git are the same people who think it's manly to live on the command line. Using git through Eclipse looks a lot like using SVN through Eclipse. If I right-click on a file and go Team > Replace With > Remote and select 'origin master' is saves me from trying to remember the obscure list of flags I need to pass to the command line to do the same thing.

Refuse to see the ugliness? No, I really don't see it. Sure, a few flags could be cleaned up, but the beauty of the rest of git more than offsets a few weirdly named flags.

Meanwhile git through eclipse causes nothing but trouble as far as I have seen. Making it seem like SVN is exactly the problem, git isn't like SVN so if it seems that way, something is going wrong. Pretending git is something that it isn't will bite you in the ass sooner rather than later. The disappointing part is that there isn't any technical reason why git integration in eclipse couldn't be good, it just isn't currently.

The fact that I can select files to add/commit with checkboxes and permanently check a box that will push every commit is exactly what I want 99% of the time. I know that isn't the "git way", but the "git way" has no value for the kind of projects I work on.

The "git way" is just whatever way you want. If you want a central server that you always push to, that is fine; there is no problem with that.

The problem is with that particular tooling. That tooling presents a workflow that is perfectly fine (though it is problematic that it does not facilitate alternative workflows, which becomes particularly problematic when working on a team with other users), but it obscures what is actually going on and executes that workflow imperfectly, generally falling over in rather novel ways. When it fucks something up, and it eventually will, you will need an understanding of the basic concepts underlying git to figure out what went wrong. I'm not saying you need to know how to use the default git porcelain, I'm saying you need to be aware of the concepts underlying git.

As soon as you understand that git is just a DAG then it becomes simpler to understand and reason about than any other VCS I have used.

I find that your comment about mercurial's data model a bit ridiculous.

The reason why most introductions to mercurial do not mention its data model is because it is _not_ important. You really do not need to care about it at all on your day to day use. I've been using mercurial for years and I've never had to ask myself what is mercurial's data model.

IMHO the reason why git forces you to understand its data model is because its UI is terrible. It is a failure of the tool when you need to understand how it works internally to use it. If git's UI were better its awesome data model would be something that only git devs would need to understand.

I have a much easier time explaining Mercurial. And I will keep using Mercurial and keep improving Mercurial until we all realise how much better it is than git because it's easier to explain, it's just as fast, and no less powerful.

really? its not that complicated, it just has lots of bad defaults in my experience

(i use mercurial when i start new projects, not because its fundamentally better - but because it has sensible defaults and i don't need to configure it our get bitten by gotcha x for the nth time - e.g. i can revert a merge without reading a document or configuring anything - a vital feature of source control imo)

There's a tree with branches and that's about it.

Reply on news.ycombinator.com