Hacker News Reader

Comment by rebelidealist | Hacker News Reader

sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.

There are two ways things can be simple or complicated. One is to have a big button labelled "DWIM", which always does the right thing --- until it doesn't, and then you have to go out of your way to work around its assumption of what you want to do.

The other way is to have a number of simple concepts which can be combined in various powerful ways. Once you understand these simple concepts, you can compose them to do whatever you need. Git is simple the same way that RISC is simple, and having a manual transmission is simple. You can do a lot more with a manual transmission car than you can with an automatic --- but if you're not careful you can strip the gears. Yet a manual transmission is simpler to maintain, and more efficient (in the hands of someone who knows how to use it) than a automatic transmission. If you take a look at the post, you'll see that the various recipes only use a handful of git commands. Once you've mastered those commands, things are indeed quite simple.

That would be true if git's command line interface were not so inconsistent and obtuse. I agree the underlying concepts are simple, which is why the command line interface is so baffling.

The standard git porcelain has it's problems, but they are largely irrelevant to the question of git's simplicity. Issues like --all/-A, or the -b flag of git-commit are unfortunate, but they do not affect the underlying simplicity that tytso is talking about. That underlying simplicity is what makes git a pleasure to work with despite weird porcelain because it allows you to reason about operations in git without reasoning about what different commands are for or can do.

If you want to know if some operation can be done, you don't reason about git-reset, git-checkout, git-branch, etc.. you reason about the DAG. After you have a solid mental image of what you are attempting to do to the DAG, it is a simple matter to decompose that action into a few weird but ultimately simple incantations with the porcelain. If you are interested in optimizing how many steps you decompose operations into, then you can learn the esoteria of a few git operations, but all of the hard thinking, the real problem-solving, was done in the context of a different abstraction.

It's hard to know how elegant and simple something can be made. git is a nice tool, but we shouldn't assume that it's the last word and can't be improved upon.

Hg is working on a feature that is betaish right now:

http://mercurial.selenic.com/wiki/ChangesetEvolution

It's been brewing for some time. Basically, the idea is to be able to make it easy to safely edit history collaboratively, with a consistent UI. Facebook is pumping a lot of money into hg right now, and seems particularly interested in getting this feature off the ground.

A number of pieces have been falling into place for this to occur. The first was to have phases, indicators of which commits are safe to edit collaboratively or not, a feature that some git users have wanted:

https://github.com/peff/git/wiki/SoC-2012-Ideas#published-an...

Mercurial now has this feature and uses it as part of the logic for the evolve extension. With this in place, hg is able to transmit metadata that indicates automatically which commits need to be fixed up if you want to edit a commit that someone else has also edited, or if someone edited a commit on top of which you've based off other commits.

The idea is to make something like "git push --force" obsolete. History is safe to edit, and commits can't get lost, not even by accident:

http://www.infoq.com/news/2013/11/use-the-force

By the way, an epilogue to that Jenkins story is that it wasn't completely trivial to recover all lost history, and at least for some of the smaller repos, they never managed to figure out exactly which version was the canonical one.

I love this kind of attitude: something seems complex? Throw it out and start again!

Unfortunately, it's usually the problem domain that is complex and starting over just means you have to rediscover all of that complexity all over again. HG has more than its fair share of complicated tasks.

Git is designed for project maintainers, and a lot of the complication is necessary for them (that view helps me, at least)

Anyone unfamiliar with the most basic of workflows would find this needlessly complex. Just a couple of months ago, I would have.

Now that I have familiarity with local branching, remote branches, how the 3-way merge works (conceptually) and rebasing, this article comes off as a guide on how to do things that you wouldn't have to do to often anyways.

in many ways hg is superior, but you can't win with Linus blessing.

Reply on news.ycombinator.com