Hacker News Reader

If I want to contribute to a project I don't expect them to accommodate my workflow. I expect to be asked to comply with their workflow.

Let's say that I were the maintainer of a project in which we did not want to use named branches. If I got a pull request from someone that had created a named branch I would just kindly ask the contributor to remake his pull request, using bookmarks rather than a named branch.

The fact that they made a mistake _on their repo_ does not mean that that same mistake must end up on _my_ repo.As I said this is just a social problem.

You say that mercurial is unforgiving of mistakes. I say that mercurial makes sure that your _shared_ history is not lost. You can edit unshared history as much as you want.

As for MQ... I would say that it is an acquired taste :-> If you don't like it there are some good alternatives, such as histedit (also a built-in extension) and the new evolve extension which is still a work in progress but which already lets you safely edit _shared_ history.

> Mercurial's main benefit is that it's much easier to use and understand than git

That's really only true if you're a beginner and you weren't properly taught how git actually works. Fundamentally, git's data model is really simple and transparent. The commands are somewhat arbitrary, but no moreso than Vim's or Emacs's. As with Vim and Emacs, you don't need to know most of the commands anyway, except for convenience.

The simplicity of git's data model is the root of the problem; that is the reason it is hard to learn and hard to use. It operates at a lower level of abstraction than the level we are thinking at when we are actually developing code. Git is less of a version-control system and more of a library one could use to build one, but in absence of any canonical high-level git wrapper, we all end up implementing and running one in our heads. This is a waste of brain-power.

Um, no. I think the git data model is perfectly good for real life version control. It turns out you don't need a higher level of abstraction. The problem IMO is that the UI doesn't map cleanly onto the natural operations on the data model. It might just be my ignorance, but the fact that I can have an operation in my head in terms of the git data model (which is fairly automatic) but not automatically know how to translate it into a git command is problematic.

To say I disagree is a massive understatement. I've seen teams try to use wrappers and just mess everything up because they don't understand what's actually going on in the underlying system.

Git has the concepts it has because they're all important. It shows them all to unfiltered because to do so is vital.

HG seems to manage the same problem with less complexity.

Can you give some concrete examples? It sounds to me like you haven't used git in an awfully long time, and are repeating things that were only true in the git 1.4 and early git 1.5 days.

I use git daily and have done so for years, but it's true that it has been a long time since I've actually tried to understand it. I gave up on the documentation, which seemed to be written in such a way that it would only make sense if you already knew what it was trying to tell you, and just memorized the handful of recipes I need to get my work done. It's not pretty; it's one of the bad tools, which I occasionally have to wrestle with, and not one of the good tools, which fit onto my brain like extensions of my body.

That's interesting. My experience was the opposite: I've also been using git since 2008, and I find it to be the most intuitive, friction-free VCS that I've ever used.

I think the difference is that I didn't start with the official documentation. I watched a video of an introductory talk given by a local Linux kernel developer. The talk started with an explanation of the underlying data model, and then showed how each command manipulates the underlying data structure and how that's useful for version control.

The talk is a bit long and a bit dry, but to date, it's the best introduction to git that I've ever seen. I highly recommend it:

http://excess.org/article/2008/07/ogre-git-tutorial/

> you weren't properly taught how git actually works

I'm using git (well, forced to, in fact) since 2009 and I've learned its' guts. And I still can't see why should I care of .git contents unless I'm git developer.

Ask yourself this: how come mercurial/bzr/fossil/veracity users aren't aware of those DVCS' internals?

You're confusing knowing the contents of the .git directory with knowing the semantic model of the revision history.

All DVCS systems involve creating and editing a series of changes to a directory tree, including metadata about each change. Those changes and their metadata are basically just a shared document that you're collaborating on with other people.

On other words, the revision history is a document that you're trying to edit. Git's document format it a bit like HTML: you can edit it blindly using a WYSIWYG editor, but it's going to seem confusing unless you at least understand concepts like elements, attributes, and entities, and maybe some CSS. Those concepts map directly to the HTML wire format, so in practice, you'll end up learning that, too.

Mercurial and bzr (I can't speak about fossil and veracity, since I haven't used them) are more like Flash or MS Word: They're easier to use for beginners, but they're more fragile and their internal formats are more obscure.

I'm pretty much aware of semantic model of distributed version control. Problem is git introduces new concepts (useless outside of git) which are widely used with and without cause.

Check out various short descriptions of push command:

* git — "Update remote refs along with associated objects"

* mercurial — "push changes to the specified destination"

* bzr — "Update a mirror of this branch"

* veracity — "Push committed changes to another repository instance"

* fossil — "Push changes in the local repository over into a remote repository"

As you may want to see, all of them except first one, are easily readable even by person used some VCS before. But not git — to understand what push command does, you have to have gitglossary opened in front of you.

> All DVCS systems involve creating and editing a series of changes to a directory tree

git is not — it stores only snapshots and changes are calculated every time you want to see them.

> the revision history is a document that you're trying to edit.

It is revision history, not "a document". To be precise, in DVCS it is directed (except darcs) acyclic graph, aka DAG of source code revisions.

> Those concepts map directly to the HTML wire format, so in practice, you'll end up learning that

One and only VCS (of 7 I have used) I've ended up learning guts was Git.

> They're easier to use for beginners, but they're more fragile and their internal formats are more obscure.

Which way are they fragile exactly? Could you please back this statement up with some examples?

And why one should care about VCS internals unless he's VCS (plugin) developer?

> As for MQ, I've really tried to understand it, but it's just profoundly awkward IMHO. Mercurial's main benefit is that it's much easier to use and understand than git, so if I'm going to need to fire up the extra brainpower, I might as well learn git where these advanced patterns are extremely commonplace. I've almost never seen anyone using MQ or rebase with mercurial.

I believe the GP's reference to mq is for the strip command (to delete unwanted revisions), which for some odd reason that I've never understood is part of the mq extension.