Go’s Version Control History | Hacker News Reader

Go’s Version Control History

research.swtch.com

179 pointssmasher16438 comments

While I have learned to be mostly competent when it comes to git day-to-day tasks, I still miss hg for it's clean interface design and simplified workflow.

Oh yeah, hg was way easier to learn, and IMO to understand. I'm very happy that I learned hg first and then picked up git; I think learning hg first was "easy mode" and then extending to git was easier to learn in turn.

Agreed. It was a version control system for humans. Unfortunately the Hg people decided that the only stable interface would be the CLI, which made it infeasible to build the likes of GitHub around Hg, and GitHub (not Git itself) is what drove Git's success.

Can we stop with "github" narrative? I remember choosing git vs hg back when github wasn't a thing yet. We chose git on its own merits - it was much faster and had much better support for editing commits (it mattered for our code review processs). I am sure our org was not the only one.

(FWIW, I think hg may have caught up in those areas.. But this is too late now.)

Well, I don't think it's mere "narrative". I'm sure Git has its merits--performance, for example--but I seriously doubt this factored into most orgs' calculus considering most orgs probably wouldn't have hit any serious performance issues with hg. I strongly suspect that Git's popularity has a lot more to do with GitHub (and to a lesser extent, the popularity of the Linux kernel) than it did to any actual merit, but I don't think there's any evidence one way or another.

Mercurial had its own GitHub, though. Was it bitbucket? I don’t remember, but it had an equivalent, I think. I really think Linux and performance was a key factor.

Edit: I preferred hg, too, for the record.

BitBucket eventually came to support Mercurial (in addition to Git and maybe others) but it was quite a long time after GitHub had been on the scene.

You misremember:

The version control software market has evolved a lot since Bitbucket began in 2008. When we launched, centralized version control was the norm and we only supported Mercurial repos.

https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...

Github was launched in April 2008 [1]. Bitbucket is harder to find, but was definitely around by June 2008 [2]. Mercurial vs git was definitely the defining difference between the two initially, though the Rails ecosystem exploding onto Github made a huge adoption difference. git being faster + built in support for rebasing was big was well.

[1] https://web.archive.org/web/20160409191635/http://www.startl...

[2] https://web.archive.org/web/20110317200833/http://code.djang...

Fair enough, bitbucket hit my radar years after GitHub despite me using hg and not git.

Sourcehut (https://sr.ht) seems to have support for Hg projects, though I've never tried it.

Probably, but the git vs hg debate was definitely settled by the time sr.ht hit the scene.

> Unfortunately the Hg people decided that the only stable interface would be the CLI

Citation needed for this.

Mercurial has the best VCS GUI I have ever seen, TortoiseHg. And there are quite a few web UIs supporting Mercurial, namely Kallithea and GitLab’s fork heptapod.net.

I suspect you're confusing API with (G)UI, but in any case here's the citation you requested:

https://www.mercurial-scm.org/wiki/MercurialApi

> Mercurial's internals are continually evolving to be simpler, more consistent, and more powerful, a process we hope will continue for the foreseeable future. Unfortunately, this process means we will regularly be changing interfaces in ways that break third-party code in various (mostly minor) ways. For the vast majority of third party code, the best approach is to use Mercurial's published, documented, and stable API: the command line interface.

Hg in itself is alive and well. Interacting with git repositories works well with hg-git.

But it is true that, for the mindset of the general public (or younger developers), it might well be nonexistent.

It is a shame, since life with mercurial is still so easier.

I'm curious what makes you consider it clean? I'm specifically not claiming otherwise; I just don't know what that claim means.

Mercurial is much more straightforward to work with for most common workflows (but can still be extended for other, less common, workflows). I found that I can use mercurial effectively just by reading the built-in help. With git ... not so much.

Not that the documentation on git is bad necessarily, there's just so much of it. A simple demonstration of this might be something like:

  % git help commit | wc -l
  622
  % hg help commit | wc -l
  59
  % hg help commit -v | wc -l
  98

And some of the CLI syntax is rather arcane, too.

It's been years since I last used mercurial, so I'd have to go back to find more specific examples, but I struggled a lot more getting started with git than with mercurial.

It's odd, to me, as I remember not being able to figure out mercurial back in the day. Guessing I had just already made the mental shift to git?

That said, size of manual doesn't seem compelling. The men page for ls, as an example, would make that seem a very tough command to use.

Some people have said they found git more intuitive and easier; its not something objective.

> That said, size of manual doesn't seem compelling. The men page for ls, as an example, would make that seem a very tough command to use.

Sure; it's just indicative of complexity, and therefore, ease-of-use.

TIL it is possible to add arbitrary "headers" , like 'golang-hg' to commit objects in git.

Don't think of git as a version-control system. Think of it more as a distributed content-addressable object store database representing an acyclic directed graph[1].

...with real-world applications! https://stackoverflow.com/questions/20151158/using-git-repos...

[1] That's a lot of post-2010s buzzwords for a system written in 2005.

You forgot to replace database with blockchain.

I'm getting more and more convinced that git is way too powerful/complex for most people.

Some tools get unhappy - maybe they are fixed now. There is a reason golang-hg was last!

Recent and related:

The Go language's first commit (1972) - https://news.ycombinator.com/item?id=30329279 - Feb 2022 (45 comments)

That Brian Kernighan guy is really ahead of his time. He invented Go before writing the book on C!

And then writing the book on Go.

> And that’s the end of the story, until we move to a fifth version control system at some point in the future.

Is this a hint, or just leaving the door open?

Probably a joke. Unlike most other mentioned version control systems, Git doesn't seem like it's going anywhere any time soon. But neither is Git eternal, heh.

What a sad world it would be if Git were the end of the story, if no one ever built a more compelling version control system. :-)

These two are quite interesting:

- https://github.com/martinvonz/jj

- https://pijul.org

Not necessarily sad.

For example, we will likely use Ethernet until the end of eternity. That's not because Ethernet is perfect. Far from it. But because whenever we come up with new networking technology, instead of coming up with a new name, too, we keep calling them Ethernet and just increment the version number.

I've been using git for twelve or so years. In the last few years I've been working on more projects with non-programmers and more projects involving media and it has made me dislike git more and more with every passing day. I really hope git is not where version control stops seeing innovation; there are a lot of projects for which it is ill-suited.

> In the last few years I've been working on more projects with non-programmers and more projects involving media and it has made me dislike git more and more with every passing day.

I think you give yourself an answer. Git is used by myriads of wannabe data scientist which only have a faint of CS understanding, create artifacts others have to clean after them.

Replace wannabe data scientist with whatever describes your situation.

This could be the History of Version Control itself.

Only if it also mentioned SCCS, heh.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...

With Go, you'd probably also need to mention versioned filesystems of Plan9 :)

SCCS was real??? I thought it was just something parents told their kids at night to scare them!

> SCCS is an abbreviation for Source Code Control System. It is a maintenance and enhancement tracking tool. When a file is put under SCCS, the source code control system maintains the file and, when changes are made, identifies and stores them in the file with the original source code and/or documentation. As other changes are made, they too are identified and retained in the file.

> Retrieval of the original and any set of changes is possible. Any version of the file as it develops can be reconstructed for inspection or additional modification. History data can be stored with each version, documenting why the changes were made, who made them, and when they were made.

Nope. Nope nope nope.

Reply on news.ycombinator.com