Sourcehut welcomes Bitbucket refugees
sourcehut.org
sourcehut.org
> 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.
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.
My eyes are bleeding
Maybe there is a relation?
I assume it doesn't scale extremely easily but seems to work good enough for now.
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).
Anyway, few hundred dollars added or subtracted doesn't really change the point. This is a fairly cheap operation given what it provides.
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.
We're in way too deep here.
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.
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.
"Initial request to clickability" is definitely longer than it used to be.
I also remember when you could register without an email.
$ curl -s https://sourcehut.org/|egrep 'meta.*gen'
<meta name="generator" content="Hugo 0.57.2" />
https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/metasrht
https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht
https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht
edit: It is using flask according to this blog.
https://drewdevault.com/2019/01/30/Why-I-built-sr.ht-with-Fl...
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.
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.
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)
https://github.com/pallets/jinja
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.
[0] https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht/bl...
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.
That's also why google.com was originally so simple, in stark contrast to their competitors of the day.
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...
SOLUTION:
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??
https://www.nytimes.com/2019/08/14/technology/india-kashmir-...
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.
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.
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.
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.
* https://openjdk.java.net/jeps/357
* https://github.com/openjdk/skara
* http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019....
Not strictly a Mercurial issue, but using the platform that your audience is already familiar with has a lot to recommend it.
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.
What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
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.
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.)
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.
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.
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.
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).
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.
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.
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.
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).
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.
[alias]
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'
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.
[alias]
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"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-scm.com/docs/git-gui [2] https://git-scm.com/docs/gitk
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.
There are extensions that cover more advanced cases, too, such as creating/reviewing Github PRs, reviewing the commit graph, etc.
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!)
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.
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...
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.
Looking forward to hearing more about your service. Thank you.
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C2019040716131...
?
It's actually a drawback.
- 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.
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 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 there was a video walkthrough for the process, it would help people like me get the ball rolling faster
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.
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?
https://git-scm.com/book/en/v2/Git-on-the-Server-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.
lighttpd not found. Install lighttpd or use --httpd to specify another httpd daemon.
Apparently, not.
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.
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.
Also - nice initiative, I guess, but I have to say their web UI seems to be stuck in the 1990s.
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.
To some of us decidedly a feature, not a bug. And:
> All features work without JavaScript
My endless upvote.
I still sometimes forget how slow stuff is relative to what's possible, even though I frequent HN.
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.
https://hn.algolia.com/?query=sourcehut&sort=byPopularity&pr...
Moaning when someone gave you free apples because you want apple pie; maybe make your own pastry.
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
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.