Hacker News new | past | comments | ask | show | jobs | submit login
Sourcehut welcomes Bitbucket refugees (sourcehut.org)
412 points by Sir_Cmpwn 29 days ago | hide | past | web | favorite | 211 comments

When you register, you notice that:

> Notice: sr.ht is currently in alpha, and the quality of the service reflects that. As such, payment is currently optional, and only encouraged for users who want to support the ongoing development of the site.

Caveat emptor.

For more details on what the alpha entails, see also:


Is that page in a repo somewhere? There’s a typo or two to fix.

They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS?

There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.

To be fair, not having any of those technologies is just a side effect of deciding to make a dead simple, spartan UI (which isn't a bad thing).

You can get away with very fast, very maintainable front-end code that doesn't need any special frameworks when you say no to modern tastes and features. More websites should really consider doing so.

One of the things that breaks my heart just a little is visiting these sites that load in 30ms and thinking that the Internet of 2019 could be largely like this and how amazing that would feel. Sure, there's lots of complex features we cherish having online, but those could all be hidden behind the main pages that are dead simple. Makes me think about how google.com is the gateway to a massive conglomerate of capability, web apps, features, etc. but the main page itself loads almost instantly.

> To be fair, not having any of those technologies is just a side effect of deciding to make a dead simple, spartan UI (which isn't a bad thing).

That's also why google.com was originally so simple, in stark contrast to their competitors of the day.

And it would kill them to write a decent CSS file?

I love the design and wish a sufficiently large part of the web looked like this... Incidentally, it's a bit like HN.

Their page was done in 114ms.

Where are the PBs of javascript, the YBs of uncompressed images in 128x320 res?

Clearly they've messed up their CDN and we're missing content.

All that really matters is the entry point size in modern application. I built an admin console for our company in react and it's downloaded and rendered in 220ms. People can make performant SPA's they just choose not to.

> for our company

Is that in a single location? If so, then it's not really impressive. A good website loads fast even when the client is on the other side of the globe.

It goes out to all the cloudfront edge locations so that generally isn't an issue. That being said anything under 300ms is not going to be very noticeable to most people.

Contemporary fancysites might pull up a skeleton in that time, but it'll (often) take multiple seconds for every div to be populated and third-party request to return, juggling the page the whole time.

"Initial request to clickability" is definitely longer than it used to be.

Same, but users think it's ugly and doesn't look "right" or "modern" :/

Lesson learnt: don't listen to all users, have confidence in some of your decisions...

Haha who do you think makes the final call? Executives (i.e. users) or the IT Department?

Which users?

The ones that usually flock to platforms. Course then you have classic reddit and 4chan which had pretty simple designs.

I changed back to old Reddit recently, and hell yeah the site is a lot more usable. The new version often had severe lag when loading comments, but I don’t have this anymore.

Its an unecessary single page abomination. Reddit will always be popular it doesnt need a new design. The best part was that different communities could style their subs.

I also remember when you could register without an email.

There’s not even any analytics or trackers. The shame!

Perhaps one could use greasemonkey to inject Google analytics into arbitrary sites. (And load some font, and perhaps have a 20 second timeout somewhere.)

Reverse-reader view! Isn't there a bookmarklet that Geocities-ifies pages somewhere, same idea.

No worries the snakeoil antivirus suites already does that for you ;-)

Don't forget Facebook like buttons, those really need to be front and center on every page.

And no non-standard fonts on some random CDN.

My eyes are bleeding

OMG! A web server serving raw HTML! The horror!

Excuse-me but you're supposed to call that Server-Side Rendering now.

My bad.

The interface does not seem fast and simple to me, it's more like primitive and unfinished. Using minimalistic SPA library, like, for example, Preact, adding some feedback for stuff like form validating and data loading would make ux more smooth. I dont want to say that SPAs are best for everybody, but I can't agree that they are always evil.

Monthly operational costs: $783

Maybe there is a relation?

Are you going to say there is not even a distributed no-SQL cluster behind this? Well, I can understand the UI part, but there are limits...

Local config for static stuff and postgres yes-SQL.

I assume it doesn't scale extremely easily but seems to work good enough for now.

YesSQL. Perfect. I'm going to steal that.

YesSQL scales just fine to enterprises like VCS repo hosting. All you have to do is shard correctly (along the lines where you least need the power of SQL, preferably).

I guess this boils down to the classic: No approach is universally better.

You can write a client-side application and distribute it through some CDN (like Netlify) and have no administration duties or server cost. However, your app will end up not working without JS (and your tech stack could possibly be a mess, depending on your choices). Or you can generate pages on the server which requires you to have, well, a server.

Both approaches have benefits and drawbacks.

Are you calling this high or low, and are you snarking or praising?

We're in way too deep here.

Where did you get that from?

Not sure about that figure but there's https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CBVRVZEWYB30Q..... Looks like their monthly expenses were around $1,200 going in to Q2.

And that's for an offering including a CI build farm. Not just a website.

I just took 640+129/3

Anyway, few hundred dollars added or subtracted doesn't really change the point. This is a fairly cheap operation given what it provides.

I'm sorry, sarcasm is not the best way to communicate an important point here at Hacker News. I appreciate the attempt at humor, but, it's not funny.

Before people downvote Clarkevans, please consider that this itself might be sarcasm and this is some new form of meta humor.

The downvotes are sarcastic as well.

HN is often accused of being humorless but it's not true. The community simply has higher standards. Deadpan is your baseline, build from there.

Don't be so bloodless. :^)

The downvotes on this sadden me greatly.

Don't worry, they're sarcastic downvotes. ;)

What a healthy dose of sarcasm on top of a healthy dose of gui layer.

Insightful and hilarious sarcasm delivering a unique perspective!

You know, libertarians often watch train wrecks and wonder how people can so clearly report problems and commiserate but the obvious solutions never seem to come up.

Refugees... from a third party service... because things changed since they began there

Some other third party service welcomes them, but has bad front end...


1. Mercurial and Git are decentralized! They have been designed to be so. Make your back end decentralized also. Why rely on a centralized site?

2. We used to run front-end programs on our computers! What a concept. We thought desktop computers were far better than mainframes and “fat” clients were far better than “thin” ones. Now we are all back to mainframes.

3. End to end encryption! I mean wow half of all humanity has their accounts in an epic database of 3-4 billion people from many breaches. All their private information is now out there. And you trust GitHub, Facebook or whoever to host your group’s private data?

MaidSAFE, MetaMask and other projects do 1,2,3. You should be in control of your keychains. We have plenty of desktop apps for managing eg git. Why let GitHub do it?

At the very least, run GitLab on your own in-house servers. But there are other alternatives.

And frankly, think about the speed and environmental impact of shipping all those bits to Google where you are “renting” Google Docs / Drive software to collaborate on something. You can have a lightning fast network in the Brazilian Favelas or a village in Namibia. Dating sites, ZocDoc, OpenTable, GrubHub can all be local open source apps running on local mesh networks. But nooo, we need project loon to send our signal to california in order to talk to our neighbor or coordinate dinner plans. And in Kashmir, etc. the government can simply turn off our internet and suddenly BAM — can’t even stock drugs locally for people??


You're replying to a sarcastic comment which is actually intended to praise Sourcehut's good frontend, hope that helps.

Further, it's a completely open source product which strongly encourages self-hosting; the main reason to subscribe to the hosted instance is to give money to the dev.

For #1, yes it's decentralized but when running a team of people having a central clone is ideal. Yea I get it you can push and pull all day long but in reality people want to have a centralized location.

The big appeal for moving to mercurial for us was better merging than svn. Our team worked a certain way already, the tool handle this workflow and that's one of the reasons we chose mercurial. Decentralized was just nice for full backups in a lot of ways.

It's written in Python so as soon as they have enough users it will be as slow as any webpage with tons of JS. Thankfully, that CPU load won't be on the client side... so it's still an improvement

I recommend you relax your convictions about Python performance a bit.

Server-side bottlenecks are more often than not database reads/writes and other IO. And the few CPU-intensive operations can be delegated to libraries written in C.

Pure Python is slow for CPU-intensive tasks, but that doesn't mean that a Python webserver is necessarily slow.

So what you're saying is that the author of Sourcehat is expected to rewrite Flask, Jinja2, etc in C?

As an example, https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht takes 600-800 ms to generate, and it's probably heavily cached already. What will happen when they get more users? The site will be unbearably slow, unless the guy starts spending thousands in servers.

I imagine that the CPU-intensive parts of Flask and Jinja2 are already written in C. Much of Python's standard library is.

800ms is a reasonable response time, and if they scale up according to their userbase, they will hopefully maintain that time.

(Also, we don't know how much of that 800ms is Python vs. IO)



0% C

Also 800 ms is NOT a reasonable response time to generate what basically is a bunch of text, that is absurd, but I guess this is the baseline in 2019.

I trust all IO is cached. The author can confirm it. This is just how slow Python is.

Almost none of the IO of that page is cached actually[0]. The only thing I'm sure that is cached is the templates themselves. I'm pretty sure that neither git lookups, nor DB accesses are cached, where you can save time. And mind you, this is served from a single data center in USA, and the latency can already eat up a lot of that. I in Europe have 300ms ping to it, so it might be that you are simply far away from the physical location.

[0] https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht/bl...

Switching to PyPy is likely to improve the overall performance if it's not database or I/O bound.

This. There are also several optimized versions of python, other that stock, allowing you to increase performance based on your needs. I've shipped with many of them over the years.

I used to run an image board written in Python with around 15m PV/month on a Pentium 4 machine in 2004 or so. The first bottleneck I found was the database. Some query optimization and caching fixed it very quickly. It goes a really long way until Python become a bottleneck, of which can also be fixed relatively easily (image processing in my case, which is fixed by moving the whole thing to a worker).

Are you sure? Looks like static pre-generated page to me:

  $ curl -s https://sourcehut.org/|egrep 'meta.*gen'
  <meta name="generator" content="Hugo 0.57.2" />
[0] https://gohugo.io/

The website/blog (https://sourcehut.org) is static, the Sourcehut app itself (https://sr.ht) is Python-based.


Python isn't slow. Running a lot of Python is slow.

If it shards well and you have the capital to buy hardware, there's nothing wrong with using python

I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.

Our company use mercurial and we are very happy with it. Mercurial has evolved and it's UI is still better than git. We use it due to following reasons:

1. Very easy to use and very well documented with a book.[1]

2. Mercurial good python philosophy of "explicit is better than implicit". This means every merge also needs to explicitly committed preserving history. Our team likes it.

3. Better multi-platform support.

4. Easy to extend to fit specific workflow.

5. Just run hg serve and access a beautiful web interface to review code. No need of external tools. In this aspect though fossil-scm [2] is ahead of both git and mercurial.

[1] http://hgbook.red-bean.com/

[2] http://fossil-scm.org/home/doc/trunk/www/index.wiki

In my limited experience with Hg, I thought it had a well designed, human-friendly interface. After a decade with git, I still feel like it's an ugly, awkward tool that just gets the job done and I still occasionally make weird mistakes with it. I'm not sure that's the case with other tools I've been using this long.

Git has a pretty gross interface, such that people have struggled to make it nicer to use with GUIs for as long as I can remember. I also feel as though every junior developer has panic inducing moments with git where they think they've lost work or something terrifying like that. It's like a hazing ritual in programming. Wait for git to give you a heart attack. If you survive, you're one of us.

Hg didn't really give me that impression at all and I was excited to begin using it more, but like with most technologies I want to adopt, work and family won and I stuck with git at work and otherwise had no time to use Hg more. It seems like git won largely because it has the right buy-in from the right people.

...and because Atlassian let Bitbucket's Hg support wither and die.

I would say GitHub was the deciding factor. Atlassian at least supported hg, though BB never impressed me.

Java OpenJDK development has been on Mercurial, and ponders moving to Git. In typical OpenJDK-fashion, the process is thoroughly examined and discussed. More information in for example

* https://openjdk.java.net/jeps/357

* https://github.com/openjdk/skara

* http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019....

Last time I tried to pull down the JDK source it required me to install mercurial (fair enough) but then to install a "forests" extension which no longer appeared to be available (or at least not from the documented location).

Not strictly a Mercurial issue, but using the platform that your audience is already familiar with has a lot to recommend it.

I have been using mercurial for more than a decade now. I just install hg-git, work on my local mercurial repo, push & pull to git, without any friction with anyone in my team.

Mercurial simply stayed my secret tool for version control, without anyone noticing.

- the command line is unsurprising and coherent - the UX in the terminal is nice (with tweakdefaults=true, you have colored word diffs, and nice curses interface for commit, uncommit, amend, --interactive) - integrated web ui via "hg serve" - compatible with git. There are margin for improvement here: hg-git can do everything but you have to be an advanced user. - advanced workflows are not only possible, but easier and safer, due to non destructive history editing - TortoiseHg is a honest GUI. Most advanced workflows are even easier there. Works on windows, so it's a good way of introducing less advanced users to version control.

Serious questions...

What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

Technically I think Mercurial would be better for engineering wise in the long term.

Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation.

Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change).

It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).

> Mercurial has better hooks in place

We use the hell out of this at my company. Mercurial's hooks have made a wide variety of automatic tasks much easier to systematize across all our repos for any repo-related action that any dev makes.

Here's one of our use cases. Mercurial, at least in the early days, had much better support (IMHO) for large/binary files than git (perhaps git is on-par now, not sure). We needed some of the projects in our repos to be fully compilable against any binaries/assets at any point in time in the repo's complete history. We implemented this with a combination of Mercurial's first-party "largefiles" extension, high compression of our binaries/assets (via 7z), and a variety of scripts/hooks to (de)compress the relevant files whenever `hg commit`, `hg up`, `hg revert`, etc. is performed.

Sure, you greatly increase the size of a repo on whatever machines are serving it, but storage is cheap these days so who cares. Devs also have to deal with more disk space being used, but a) storage is cheap and b) it is trivial to clear old binaries/assets from their disk on an automated schedule. Whenever they update/revert to another revision/branch the binaries/assets download automatically anyway.

> Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change).

The file system changes were extremely low level and likely couldn't have been handled with extension hooks in Hg either (some of it, from what I read of it, would be more like the equivalent of changing the Python standard library, specifically the OS and file-system-specific bits, underneath Hg than changes to Hg or its extensions). It was also a relatively short-lived fork as it did merge upstream.

> It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).

Since Microsoft has taken an active role in git development, and especially since the Windows team itself switched to git, the official Git for Windows install and support for that install has been really good. While git will likely always need some bits of Linux abstraction because how much of it's "high level" is written in Bash shell scripts and random bits of awk / sed / perl, it certainly seems that the low level stuff is less reliant on Linux abstraction than ever and is increasingly cross-platform-intended C. (Just about every major performance boost across the board has usually included rewriting to directly cross-platform code.)

Python will always generally be "simpler/stabler cross-platform" for Mercurial, but git has done a remarkable job at catching up on the cross-platform space over the years.

> Technically I think Mercurial would be better for engineering wise in the long term.

I don't see why. I've seen companies switch from Mercurial to Git even though many employees loved Mercurial -- the driver was the fact the new employees were much more likely to prefer Git or not even know what Mercurial is. Mindshare matters.

> Mercurial has a single implementation (Git has 5),

Eh? I very much like that there are multiple Git implementations. Besides choice, this means there are more people who really understand its guts and can support it and its implementations.

> and they greatly discourage anyone from implementing a second.

That's not a good thing.

> This gives them a single source of truth for the implementation.

That gives them too much power to make changes the users might not like.

> Mercurial has better hooks in place.

Sounds like one of the ways in which Git implementations might differentiate from each other.

> It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).

MSFT is doing amazing work on Git on Windows, making it scale in ways no other distributed VCS is likely to any time soon without adopting similar ideas. If you want Windows support, then Git is going to rock your boat more than Mercurial soon if not already.

There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient than anything on the command line. And picking source and destination commits for a rebase is much easier visually on the commit graph than making note of hashes on the command line. Plus, at our company we do have a few people who use version control but are a bit less compsci focused.

Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.) I tried GitKraken and it failed at the first thing I tried to do with it (I wanted to stage a file I had just created, but it didn't have a way to display untracked files).

I know you said GUI, but this single-line git alias that goes in ~/.gitconfig changed my life and I don't look for a git GUI anymore:

 l = log --date-order --date=iso --graph --full-history --all --pretty=format:'%x08%x09%C(red)%h %C(cyan)%ad%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08 %C(bold blue)%aN%C(reset)%C(bold yellow)%d %C(reset)%s'
Next, go to one of your git project directories and type "git l"

If you don't want to learn rebasing and other Git fun, I'm not sure how much this will help you, but for me it's invaluable when it comes to identifying the base of my branch and where I would like to transplant it to.

Along with the basic "git pull --rebase" I also frequently use "git rebase --onto" and "git pull --rebase=merges" or "git rebase --rebase-merges" in my projects in order to manage branches that were created in an order other than what I want them to merge in. This keeps the history nice and linear, so I can avoid having any commits with two or more parent commits.

I don't find there's much else I would want to have a GUI to help with. But without a git graph that I can scroll freely, I feel as if I could not do my day-to-day work with such ease. This makes the most usable git graph with colorized edges and may be all you need. That, along with a nice PS1 setting so you get some branch status information right in your terminal status line without asking for it every time.

If you liked that alias, check out tig, which is a very simple TUI for git. It gives you a browsable graph, and other nice things. It also does "tig blame" with going back to revision before a specific line with a single key shortcut.

Finally ended with such a modification:

  glog = log --date-order --graph --all --date=short --pretty=format:"%x09%C(auto)%h  %C(cyan)%ad  %C(green)%<(12,trunc)%aN    %C(reset)%<(50,trunc)%s    %C(auto)%d"

How on earth did you create that format string? That alias generates really nice output!

It appears to have come from this guy, here is the original gist: https://gist.github.com/msroot/6206676

Finding a decent GUI is definitely the biggest pain point in switching to git for us. It's not just that git GUIs are lacking generally, it's that there's fragmentation - the best ones on one OS don't necessarily work on other OSs. Tortoisehg was so universal that it practically was mercurial, for the purposes of many users. We are scientists and wanting to attract contributions to our code from other scientists and grad students who can code somewhat but are unlikely to have used version control before interacting with our project. Having a universal GUI was excellent for mentoring people and spreading the knowledge around. It's going to be much harder with git (since we are moving to github - I like what sourcehut is doing for devs, but email-based pull requests will mean we get very few contributors who aren't already seasoned devs, so we have decided against it for now).

From my experimenting, I'm liking Sublime Merge as my favourite git GUI so far. It's nagware (i. e. no time limit evaluation period) like sublime text, and costs US$99 to remove the nag and enable the dark theme. It is pretty and functional without being overwhelming in its interface.

Am I the only person who uses gitk and doesn't have any real problems with it?

I used it previously. But it doesn't support a lot of operations, it's mostly good for visualising what's happening while you do your work in the command line.

I've been using SourceTree in Windows. But it's slow and I really hate that they put the staging area and the file tree into the same control.

Heard of Fork [1] and switched in a heart beat. Works like a charm and looks great. Unfortunately only for Windows and Mac. I fall back to the command line on Linux.

[1] https://git-fork.com/

> And picking source and destination commits for a rebase is much easier visually on the commit graph than making note of hashes on the command line.

In git branches are more comparable to hg bookmarks and used so heavily it feels very rare from the command line where you would directly use a hash rather than a branch name.

> Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.)

If you are happy with the Tortoise family there is a TortoiseGit [1]. I think the Tortoise "family" still shows its roots in SVN much too often to be a "great" Git GUI, but it should certain feel comfortably familiar. Though like TortoiseSVN, TortoiseGit only supports Windows. It's interesting that TortoiseHg was the only one in the "family" to invest in cross-platform.

GitHub Desktop can be a useful cross-platform GUI sometimes, especially for somewhat less code-focused folks. While it puts GitHub front and center, it's still a general purpose enough tool.

Git has an "okay-ish" cross-platform GUI that is almost always bundled with it called "Git GUI". I don't know a lot of people that recommend the main interface for Git GUI, it's an ugly Tk-based throwback, but it does cover almost all of the basics of TortoiseGit without as much direct shell integration. (It has some bare shell integration into the right-click context menu as an optional checkbox buried in the Windows install at least.) On the other hand, while almost no one uses the main commit-oriented parts of Git GUI, its commit graph viewer `gitk` (which is almost always available in the PATH by that name) is almost an almost indispensable power tool, and I think still the commit graph tool to beat for git. `gitk` is great, and years ago became my muscle memory over `git log` for a lot of situations.

At this point the most common cross-platform "GUI" I use day-to-day with git though is just VS Code. It's built in git support is sufficient for a lot of work, and there are some useful, optional power tool extensions like "Git Lens" that make it even better.

[1] https://tortoisegit.org/

The gui tools bundled with git for committing and browsing allow doing most things one would require and are cross platform

[1] https://git-scm.com/docs/git-gui [2] https://git-scm.com/docs/gitk

gitk is a bit ugly, though.

How about VSCode? Basic stuff like staging, committing, merging, stashing, pushing, pulling, are all baked in. Even staging parts of a file are straightforward, and resolving conflicts in VS code is more pleasant than any other tool I've used.

There are extensions that cover more advanced cases, too, such as creating/reviewing Github PRs, reviewing the commit graph, etc.

Magit is a good one. But its an emacs package and, well, I wouldn't want to shy over the fact that it may require some effort.

Magit is probably the most productive git client I've ever used. The only caveat is that some operations on certain repos can take a lot of time and CPU power, and lock up Emacs while they're going on.

Most of the people in my office use SmartGit[1]. It seems pretty powerful, it supports worktrees, and I like how it has a window that shows the actual commands that it's running.

[1] https://www.syntevo.com/smartgit/

We use it at work as well. It's a bit ponderous when starting, being written in Java, but has a very good conflict merge window.

I really liked SourceTree around version 1.7, but the new GUI is not so comfortable to me. I'm also looking for an alternative.

Now, I am not a programmer so I get to chose my tools all by myself without any peer preassure. In my early days I managed to destroy quite a lot (as in: counted in hours) of work with git. I switched to hg at the same time as my source control usage became more advanced, and I haven't managed to fuck anything up since.

Now, I last used git extensively in 2011, and I have heard things have gotten better on the UX front. But now I am used to HG and don't have many reasons to switch. I gladly pay 20 bucks a year for having a place for mercurial repos.

No offense meant, and I appreciate the anecdote, but I don’t feel that skill level in the technology should indicate the usefulness of the technology. I’m trying to understand more objectively than that.

Judging from other stories, I am not alone. It seems to be a fairly typical story, even with people that use git in a professional setting. I never got comfortable using git after that, and my use case has mostly been to pull, branch, merge, push and the likes. Whenever something happens I have someone to ask, which also seems to be a common thing. A "git guy" you contact when things go wrong.

With mercurial and darcs I never had that happen. Losing code is a deadly sin for a SCM should be behind at least 2 confirmation dialogues.

Whenever pijul reaches 1.0 I will probably switch to that. It seems like patch theory done right.

We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history.

After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and services is nonexistent. The move to git is allowing us to leverage a world of tools, as well as allowing us to skip bringing every new developer up to speed with mercurial.

I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics)

Not true.

Out of the box with no extensions required, Mercurial supports bookmarks, which are functionally the same as Git's branches. Also, Mercurial supports even lighter branching compared to Git using anonymous branches.

This blog post from 2009 explains it all: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

> Not true.

Mostly true. I've read the post you linked to; all of those approaches have significant disadvantages compared to standard git branches. We used the bookmark-based workflow for a while, and it's simply not as good as a git branch. The evolve extension and topics were build for this reason, and they finally approach a decent workflow that allows for things like cleanly discarding experimental "branches" that have been pushed to a remote.

Mindshare matters a great deal. Git won. (And thank goodness too. I don't like Mercurial's, nor Fossil's, opinionated UIs.)

Back when I evaluated Git vs Mercurial, Git would delete uncommitted changes when changing branch. Mercurial will instead merge the unsaved changes ... I don't like either, but Mercurial seemed more forgiving. And it was almost feature complete with Git, but with a slightly easier interface. The biggest factor was however that Mercurial was platform independent, while Git was developed for Linux. One nice feature in Mercurial is that you can make commands return JSON, which makes automation easier. If I was to choose today I would choose something other then Git or Mercurial, or if I had to pick one I would pick Git simply because it's more popular. I don't think either is better or worse, they're the same but different. Do Facebook still use Mercurial!? Last time I checked they had one big monoreop, and has put engineering hours into Mercurial to help make it fast.

For one thing it offers a far cleaner user experience than Git does.

AKA the commands actually make sense, and they have sane defaults so you don't have to remember 100+ random flags.

People always claim this in mercurial posts, but it's really hard to tell to what extent this is just that people who are using hg all the time are familiar with the hg commands and so don't notice the problems any more.

As a irregular hg user, I frequently run into (or help others with) issues with the ui, like "why does `hg log require `-f` to do something useful", "how do I refer to the current head commit (protip: it's not `tip`)", "how do I see changes relative to a branch (bookmark) on a remote" and "which set of commands am I supposed to use for history rewriting nowadays and how do they work?".

hg has some nice features, but the idea that it's got a fully intuitive and uniformly well designed interface is, in my experience, a total myth. Which isn't to say that git has a great CLI of course, just that the extent to which hg is better in this area is often overstated.

I think it's also at least somewhat the case that hg had a great CLI when it launched and git had an abysmal CLI when it launched, but over the years and counting "necessary" hg extensions, they've both sort of converged more towards the middle: git's has only gotten better (and really only had room to get better) and hg's has mostly stayed the same, if not slowly gotten worse from the additional "overhead" of extensions.

Which is that the difference between the CLIs in the early days were stark contrasts of good and bad, but now they both seem about equally mediocre, but in different ways, when directly contrasted. (Especially with the latest git release finally splitting checkout into switch and restore, they are really on increasingly similar footing.)

Same, but I don't really have that many different use cases as a developer. I wouldn't want to be the tools guy maintaining it all for 100+ developers though :)

The consensus seems to be that mercurial has a cleaner UI (options and arguments). I also read that it can get slower than git on huge repositories but I don't have benchmarks.

I also read that it can get slower than git on huge repositories but I don't have benchmarks.

Not true. In fact, Mercurial is faster than Git on huge repositories; just ask Facebook--the entire Facebook application lives in a Mercurial mono repository, which wasn't possible without Git slowing to a crawl: https://engineering.fb.com/core-data/scaling-mercurial-at-fa...

Turns out it's been easier for Facebook and others to optimize Mercurial over the years due to it being 95% Python, which is easier to refactor.

And because of Mercurial's extensibility, it's easier to replace or optimize different components.

Honestly, years ago after I took a job that uses git, I converted a Mecurial repository to github. I don't remember what tool I used, but it preserved all my history.

Granted, this was a personal project and I didn't use much branching, but I remember the transition and history were pretty seamless.

I originally started with Bitbucket, and then transitioned to a small hosting service after Bitbucket had extended downtime. (I just had to update my Mecurial repository to push to a new host.) Then, the transition to github was almost as easy.

(If only I could remember the tool I used. Maybe my private Mecurial host allowed pulling with git? I just don't remember!)

What does git offer that mercurial doesn't? Of course, except a lot of popular hostings. Probably in some parallel universe mercurial could win, and people would ask same questions about git.

Looks better on the resume. Both are great tools IMNSHO

I am looking to preserve the pull requests and corresponding comment threads from bitbucket. I'm thinking the way to go might be to save static HTML of the pages and host them somewhere, modifying the links to issues to point to migrated ones, and links to PRs to the hosted pages. Anyone else thinking of trying this approach? Advice, criticism?

At some point it should be possible to adjust the import script to also generate an mbox of pull requests discussions and import it into lists.sr.ht, but that's a lot more complicated. Happy to talk over the details if anyone is interested in taking a crack at this.

It's not clear how to send you feedback and/or ask questions, so I created a new sourcehut tag on Stackoverflow and posted my first question: https://stackoverflow.com/q/57628020/14731

Looking forward to hearing more about your service. Thank you.

I believe Drew is responsive to email at his (work?) email address sir@cmpwn.com. You may want to send him a message directly.

Is it possible to reconsider the decision on status codes for unauthorized access to private repositories:



It's actually a drawback.

So what happened to Bitbucket? Don't got any opinion either way, just wondering about the "refugee" part

They're dropping support for Mercurial: https://en.wikipedia.org/wiki/Bitbucket#History

Starting using Sourcehut a few days ago for two repos and have had a good experience so far (being a new paid user is my only affiliation with sr.ht):

- Very clean, simple UI/UX providing deceptively rich feature set

- A build system among the easiest I've used

- Solid, straightforward documentation

Currently it's a little slow to push to repos but the creator says it's a known problem with ongoing regular improvements occurring.

I'm a long time GitHub user with many repos there and there are lots of GH features I like (like Org Mode READMEs). But I'm a big fan of this sort of business model: someone puts together a simple, solid, independent service; I pay a small amount monthly/yearly (I chose to pay voluntarily even though it's currently optional).

I hope this service thrives.

People seem pretty interested in keeping their pre-git source control system, even if it means switching repository hosts. I know the default attitude is "they're just curmudgeons who don't want to change," but Hg could have some advantages.

Mercurial shouldn't be considered a pre-git source control system.

It's initial release date was actually 12 days after git and it is far more comparable to git than it is to SVN and other pre-git version control systems.

I think he meant "the source control they used before using git" - not that it came out first.

But there really are people that purposefully went from git to hg. Calling hg a "pre-git" version control system makes some assumptions that just aren't true.

For me, I started using Hg before I started using Git, so I have about as many Hg repos as Git repos.

I also started using Bitbucket, back when that was the only option (they didn't have git support until Atlassian bought them).

I have no personal desire to transform these Hg repos into Git. That just seems like busy work.

Bitbucket is causing work for me (granted I never paid them a dime over these last 10+ years, so I have nothing to complain about).

My choices are to migrate these repos from Hg to git, or move hosts. I'm pretty sure I'm going to move hosts, seems like less work.

If you can avoid inflicting a painful VCS migration on yourself, you probably should.

This is how websites should always be. Great job!

I found Sourcehut extremely confusing to self-host so I went with RhodeCode recently.

Prior to this I tried cgit (I really like how it looks) and gitolite. I even bought a book on gitolite configuration and couldn’t figure that out.

Oh well.

On topic, it’s great that Mercurial users have an alternative that’s not Github.

I tried sourcehut a while ago but I found the pull request flow to be confusing. There aren’t actual pull requests but instead some sort of email flow that I didn’t have time to figure out.

If there was a video walkthrough for the process, it would help people like me get the ball rolling faster

There's no video (that I know of) but Sourcehut has put up a website with a set of steps/instructions for email based pull requests:


I honestly would have been surprised if Sourcehut shunned Bitbucket refugees. Water is wet, news at 11?

Doesn't it seems like a bit of an abuse of language to refer to former bitbucket users as "refugees"?

It's a commonly used figure of speech.

Lifelong english speaker, American. Never heard this one in software until today.

No I would say it's a little snarky but in a time of overuse of political correctness that every little bit of rebellion helps.

no, because like real-world refugees, we are left to flee Atlassian without an obvious place to relocate.

I so wish my company would ditch them and use opensource alternatives. I'm so tired of feeding of the beast, yet we just get deeper and deeper in.

why you would want to continue to use Mercurial at this point is beyond me. Pull the plug and just switch over to git already. People make a big deal out of it.

There are dozens of us who use Mercurial! Dozens!

…all five of them ;)

Am I the only one who can't find the source of this "open source software"? How they can beat Bitbucket while they hide the code under unusable UI?

> Where is the source?

The homepage links to https://git.sr.ht/~sircmpwn/?search=sr.ht (EDIT: which is now also the URL in the blogpost with the link text "100% open source software")

There are also Hg repos at hg.sr.ht; idk how easy it is to find git.sr.ht from hg.sr.ht.

> how can they beat Bitbucket while the code is unusable

Well, for Hg users, it's not like there's going to be much of a choice in a year (given BB is sunsetting Hg support), right?

Mercurial users can use their builtin Web UI unlike Git users

git has gitweb:


But in both cases, the user has to have a server to put it on, making services like Sourcehut and Bitbucket (may it rest in peace) useful.

gitweb requires server setup, while Mercurial web ui can quickly start locally without any configuration and that was the one of mercurial selling point until github and other services arrives.

I think the way you're using hg's web UI is slightly different to the uses I think of for sites like GitHub, BitBucket or SourceHut.

A web UI is fine for being able to see the different commits, and files at different points in time.

But people also make use of GitHub as a hosted repository for sharing code with others, as an issue tracker, and for doing code review etc. -- for sharing things outside a local network, there's the understanding that either you're paying someone else to host it, or you're making effort to host it yourself, so "requires setup" isn't much of an issue.

"sourcehut competes with bitbucket" puts more emphasis on the latter than the former.

`git instaweb` is sufficient to get a working gitweb stood up.

$ git instaweb

lighttpd not found. Install lighttpd or use --httpd to specify another httpd daemon.

Apparently, not.

You have to install the dependencies of a piece of software to use that piece of software.

Epic win response lol

Clicking the text "100% open source software" brings you to the following list of git repos which collectively contain the source code for sourcehut:


Can you make "sr.ht git services" the blue title of the repo "card" and "~sircmpwn/git.sr.ht" - the subtitle (with dimmed color)? This simple change will improve UI usability in 10x times.

I sort of agree about the confusion.

I think the proper UI fix would be to split the username (sircmpwn) from the repo name (git.sr.ht) and make them two separate links divided by a non-link " / ".

This is what github does and I feel like it's a standard people expect, similar to having the logo of a page on the top left.

Well, the former is the description and the latter is the name.

The former is a human-readable text which allow eye to easy understand and latter is a technical info which is not required to have space on the screen and makes UI "hard to use".

I wouldn't consider the repository name any more technical in nature than the name of a CD or film. I think it makes sense to have the title be more prominent than the description of what it does.

Think Craigslist - totally clunky UI that totally dominates its market

Bitbucket may have better styles, but its load times are atrocious.

Everything from Atlassian is slow. Tried Confluence lately?

Hmmm our confluence is pretty snappy I never notice any real lag. Especially compared to most web sites off campus. Jira on the other hand...

How was this upvoted so often without a single comment?

My guess would be because HN likes sourcehut's open source approach (I still read it as 'Sir Hat') since its announcement on here. There are some projects that HN as a community tends to like and upvote just for visibility without feeling the need to comment on it.

Beyond what sourcehut is providing, I would also upvote because of Drew (Sir_Cmpwn). I don't know him personally, but based on blog posts, HN comments and interaction via email, he seems to be very helpful and polite, my general impression is that this isn't the norm in open source.

That's a good sign. Comments usually signal quibbling to outrage; there's no culture of "me too" (in the AOL sense, not the sexual assault one!) here.

Commentary is not needed to be interesting. There may not be much to add.


I am one. Happy paying user, upvoted sourcehut's posts because I like to support independent services, but rarely commented.

Ok never mind then.

I'm a wanting-to-be paying user, fwiw. It goes against some of Sourcehut's fundamentals, but I'm waiting for a basic PR UI system, because frankly I just don't like email that much. (though strangely, I love the model of email).

Regardless, I adore the goals of the service and the approach, so my plan is to move all my public and private projects there once I can use a PR-UI/etc - and pay, of course.

I think you should give email its fair shake. There's a good tutorial here:


And the video on this website shows you how the maintainer side could work:


And remember, the email client you use for hacking needn't be the same as your everyday client.

Huh. That never occurred to me. To use a different client for workflow email. That was sort of one of the things keeping me from trying this out for real. I was just, "Ugh, I don't want all that mixed up together." Even folders don't help that much because my main email client is already managing a ton of email accounts.

I'll have to give this idea a shot now. Thanks!

I'm a paying user. Beyond the article there's not much to say.

Am I the only one who reads that as "source chute"?

Also - nice initiative, I guess, but I have to say their web UI seems to be stuck in the 1990s.

The goal is to be simple and easy to use. The UI should get out of your way ASAP - you're there to get things done, not to gawk at the pretty UI. As a bonus, it's very fast and small, easy on your web browser even on old computers or slow internet connections. And it's not spying on you!

That being said, I have been working on conservative improvements to make it a little bit more pleasing to the eye, without sacrificing the principles behind it. More color, for example, is not going to be added, or will be added cautiously, because color is used sparingly to attract your eye to the most common reason you would come to a page. Each element of the page should be intuitive and have purpose before it's pretty.

More power to you, I'm shifting today


I'm currently considering moving from bitbucket to sourcehut.

Another way sr.ht is stuck in the 1990s is that it doesn't bludgeon my browser with analytics and gazillion requests like a certain bucket was fond of doing.

In general, sr.ht seems simple, in a very positive way. AFAICT, it doesn't try to compete with the GitHub-ish web UI for pull requests and code review. Personally, I don't mind.

> their web UI seems to be stuck in the 1990s

To some of us decidedly a feature, not a bug. And:

> All features work without JavaScript

My endless upvote.

I just went for a look because of your JS remark and holy moses that's a fast site.

I still sometimes forget how slow stuff is relative to what's possible, even though I frequent HN.

This looks suspiciously like a spam campaign to fish for users desperate enough to go anywhere but bitbucket.

SourceHut / Sir_Cmpwn deserves all the support he can get. I don't know if you realize that this guy is earning 10 times less that what he could earn by accepting any of the job knocking at his door. But instead he chose to be a full time free & open source developer financed only by people donations and SourceHut (which is 100% open source too)

Moreover there is very frequently on HN "Github is introducing feature X" or "Company Y is announcing product Z" where those company are multi billlionaire making money by exploiting people data and abusing their monopoly. And all you find to do is be rude about SourceHut, developed by an independent, which is 100% open source, which contains no analytics and respects you

Obviously independent developers are supposed to slave away at big companies that pradvertise their products on HN, not make attempts to escape and work for themselves - at most they can work passionately for a VC-backed startup on some free product until that is bought by one of said big companies for reasons unknown. But working for oneself independently is immoral and something to be frowned upon.

That's... really rude. Sourcehut has been around for a while:


Doesn't mean you're not fishing for users there.

Isn't literally everyone fishing for users? Relax dude. People need somewhere to go and maybe they'll find Sourcehut suitable to their needs. I don't know what your definition of spam is but this definitely doesn't qualify for my (unusually strict) definition of it.

Well, the page contains nothing but a tool to import data from a competitor in order to get users of the competitor to sign up for your service. That meets my definition of spam to a certain extend.

The competitor is leaving the market, which hardly makes them a competitor at all. Any users who don't want to be left out in the cold need tools like this.

Then why not make the tool open source + standalone and compatible with other alternatives like GitHub/GitLab/Gitea/Gogs/etc. so the users can pick the competitor or tool they like?

OMG dude, just let it go. You've dug your heels in so much that HN won't even let me reply to your latest comment because you've hit a depth limit. This is just a marketing page. It wasn't sent to you as an email. Nobody erected a billboard outside your house. It's on the internet, where people are free to create and ignore stuff as they please. Do you really think you're bringing something to the table at this point or are you just trolling for fun?

I just don't like spam on the frontpage.

None of them support Mercurial. Everything is open source. You’re behaving incredibly weirdly.

The tool is open source, and none of the services you listed support Mercurial, so...

But it's not standalone so everyone can use it privately, it only works for your service.

If it's open source then surely you, or someone, could modify it for other services.

Moaning when someone gave you free apples because you want apple pie; maybe make your own pastry.

I'm moaning because someone wants to sell me their entire apple tree in order to get the free apple pie while I would be happy to get a few apple to make my own. The service is deeply connected to SirCmpwns paid service and an obvious spam bait.

You can run it privately: https://man.sr.ht/installation.md

It still only works for sourcehut.

Why are you stating that the tool is not open source? Did you even check that?

Open source + standalone, it's not standalone.

That’s the point. That’s the point for half of the Internet.

Doesn't mean we have to let spam campaigns on the frontpage.

BitBucket is discontinuing Mercurial, forcing users thereof to jump ship. Sourcehut is just doing a bit of marketing around their continued support for those needing new hosting.

Agreed on this. Opened the page and it immediately made me think of a phishing campaign or a cheap knock off site.

I can't quite put my finger on which design detail is contributing to that impression, but the page as a whole is definitely giving that feeling.

More power to him. This is hardly a social media blast.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact