> 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.
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.
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.
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.
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.
Perhaps one could use greasemonkey to inject Google analytics into arbitrary sites. (And load some font, and perhaps have a 20 second timeout somewhere.)
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.
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.
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...
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??
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.
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.
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).
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.
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.
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
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.
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).
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).
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.
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.
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.
> 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.
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 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.
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.
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.
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.
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.
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.
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).
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
> 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.
https://sourcehut.org/alpha-details/
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.
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.
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.
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).
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.
Anyway, few hundred dollars added or subtracted doesn't really change the point. This is a fairly cheap operation given what it provides.
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-...
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.
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.
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...
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...
https://git.sr.ht/~sircmpwn/?search=sr.ht
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
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?
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).
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.
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.
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).
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.
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.
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/
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/
[1] https://git-scm.com/docs/git-gui [2] https://git-scm.com/docs/gitk
There are extensions that cover more advanced cases, too, such as creating/reviewing Github PRs, reviewing the commit graph, etc.
[1] https://www.syntevo.com/smartgit/
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.
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.
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.
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!)
Looking forward to hearing more about your service. Thank you.
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C2019040716131...
?
It's actually a drawback.
https://news.ycombinator.com/item?id=20745393
https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...
- 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
https://git-send-email.io/
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.
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.
lighttpd not found. Install lighttpd or use --httpd to specify another httpd daemon.
Apparently, not.
https://git.sr.ht/~sircmpwn/?search=sr.ht
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.
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.
https://git-send-email.io
And the video on this website shows you how the maintainer side could work:
https://aerc-mail.org
And remember, the email client you use for hacking needn't be the same as your everyday client.
I'll have to give this idea a shot now. Thanks!
Also - nice initiative, I guess, but I have to say their web UI seems to be stuck in the 1990s.
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.
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.
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
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.
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.