The impetus behind the branding clarification seems to be this HN thread . For more history, see the the debut announcement  and its corresponding HN thread .
 https://news.ycombinator.com/item?id=18929709#18930413  https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...  https://news.ycombinator.com/item?id=18458908
It seems 'sh.rt' will continue to be the service domain while the software (but not the identities of the artifacts) have been renamed for ease, and it's all being done in a way to maximize benefit and minimize breakage.
Looking back at the thread, it looks like the new name was suggested back then by neuromanc:
I like how the proposed name fit with the existing one. Good example of backward compatibility, but with project names. ;)
Funny to see it came from reddit, thanks.
There is already:
By adding more "Source", you are just diluting value of source brand.
It will be interesting to see how many more "Source" untill we stop using Source at all?
Same is the thing with "Git" and Docker escaped this issue by prohibiting use of "Docker" in non docker owned companies.
"Source" is not the brand, it's the literal description of what most (all?) of these products and services deal with.
The prefixes/suffixes make the brand. Having a very relatable/descriptive term like "Source" in that brand adds clarity.
So yeah, there's more to branding than a single word of the name.
This is the killer feature for me.
Here’s a list of Mercurial features that I think are really cool:
Revsets – a domain-specific language for querying your commits
Templates – a domain-specific language for altering the output of almost every command. Putting together these two you can do things like this: http://jordi.inversethought.com/blog/customising-mercurial-l...
Evolution – a distributed and safe way to share rewrites (think automatically recovering from upstream rebase without any git reset --hard and no git push --force).
Absorb – automatically amends an entire stack of WIP commits at once by picking the right diffs from your working directory based on which commits’ contexts they fit best.
Curses interface for hunk-picking – a unified interface for splitting diffs for any purpose: whether to revert working-directory changes, write a new commit, uncommit parts of a commit, or amend a commit with more diffs. Just add --interactive to any of those commands and start picking hunks!
A fairly rich built-in web interface – hg serve and point your browser to http://localhost:8000 and you’re good to go.
Lots of support for monorepos – indeed, this is the main reason that Google, Facebook, and Mozilla are all pouring work into hg and are using it.
A consistent UI – this one is more subjective but often-touted feature of Mercurial. If a command accepts a revision/hash/tag/bookmark; it always uses the -r/--rev flag for it (and you can also always use a revset for any command that accepts a revision). If a command allows hunk selection, it always uses the -i/--interactive flag for it. The help for every command fits in about a screenful.
Give it a try! Mercurial is neat!
Meanwhile I google "how to print commit history git" for the 100th time...
hist = log --graph --pretty=format:'%Cred%h%Creset %s%C(yellow)%d%Creset %Cgreen(%cr)%Creset [%an]' --abbrev-commit --date=relative
They are improving mercurial, but are they using it ?
Also works properly out of the box for ad-hoc sharing.
I literally never managed to get `git daemon` to work to share stuff between two machines or with colleagues, I've no idea what is wrong and it doesn't provide any human-readable let alone actionable information, all I know is that even from the same machine the git client can't connect to the git daemon. That's it.
In the end, it is nicer, but not as nice to miss it that much over git (granted, i do know by heart all the dances to make git bearable, since I have to use anyway)
Or perhaps they're reflecting GitHub's dominance in the forge space and the fact that they only offer git, so a whole lot of people are more-or-less forced to learn something about git, so searches...
Or perhaps they're reflecting something about hg users preferring other search-engines than Google...
Drawing any sort of conclusive correlation between those Google search trends and actual usage or desire to use one or other distributed VCS is a fool's game.
I'm well aware that everything is git.
This doesn't mean that everything should be git.
Projects like pijul interest me, since they work in a fundamentally different way. Pijul is a "nicer" version of darcs. Git killed darcs not by being nicer but by being faster, and pijul is also faster than darcs, so maybe there's hope ;)
(Of course, most of git's momentum came from huge projects using it, like Linux and Xorg; yet being huge is precisely what forced those projects to favour speed at the cost of "niceness". If a "nice" system existed that was fast enough to handle Linux, Torvalds would probably never have written git).
Git UI is just terrible. I am sad that Microsoft chose git for VFS and not mercurial. Mercurial would have worked great for their windows mono-repo
I signed up as a paid user when it was last on hacker news. Got an email invoice. Then for the life of me could not remember what the service was called. Finally gave up trying to use it.
sourcehut on the other hand is one of too many source somethings. It's more prefessional for sure and if it is the official name we can still keep sir hat as a nickname I guess.
It's written in Python, using Flask, https://drewdevault.com/2019/01/30/Why-I-built-sr.ht-with-Fl...
For example: https://git.sr.ht/~sircmpwn/sourcehut.org/tree/master/conten...
But everything is designed to work well without JS first.
This style of UI reminds me of something different... a late 80's/early 90's simplicity. Yet it's still stylish. I am hesitant to call it retroism because it will cheapen the movement to do that. It's refreshing and unique.
If you don't want an account, there's some donation information here: https://drewdevault.com/backers
Please update with either
`ssh-keygen -t ed25519 -a 100`
`ssh-keygen -t rsa -b 4096 -o -a 100`
One of the main things I don't like is the email focus. I think one of the best things the modern git websites have done is replace email with merge requests which are just so much easier to use, tag, and search. I get that this is a tool made for those old devs who still want to do everything from mutt though.
I agree that email is good for notifications.
Surely "checking Web sites to see what's new" was solved with RSS/ATOM?
(Again, once the data's out there, the UI is your choice; e.g. I convert RSS/ATOM to maildir so I can use my preferred email client for everything; I put HackerNews (HNRSS and HNNotify), subreddits, youtube channels, etc. into the same folder as my mailing lists)
That patch page is pretty indecipherable.
I've opened the homepage, didn't see any obvious links, went to sr.ht, saw just a login/register screen. I went back, continued scanning for a usable link on sourcehat.org, and ended up leaving the whole thing in frustration.
Still curious, I took my laptop and only then have I figured out that images link to example repositories on click. As a result, my first impression can be summed up as "unintuitive".
The official logo is this :)
(which is just a circle, like the favicon)