Sunsetting Mercurial Support in Bitbucket(bitbucket.org)
bitbucket.org
Sunsetting Mercurial Support in Bitbucket
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
366 comments
I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers.
I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back.
A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't.
I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.
I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back.
A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't.
I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.
Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system.
On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.
[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.
[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
git was deliberately designed around the "known fast" things in Linux.
One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache.
Since Windows doesn't have an equivalent, git is going to be slower there.
Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.
One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache.
Since Windows doesn't have an equivalent, git is going to be slower there.
Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.
>several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
That one at least is fixed now, by having an option to disable it.
https://github.com/git/git/blob/v2.23.0/Documentation/config...
That one at least is fixed now, by having an option to disable it.
https://github.com/git/git/blob/v2.23.0/Documentation/config...
That git setting is for `git status`, but I think `git checkout branch` still doesn't have a comparable option either on the command line or in a git configuration file. The closest you can get is to turn off all output with `git checkout -q`.
Oh yes, I just tested it out and you're right. Bummer.
Definitely sounds like a problem. Do you think an alternative source control solution would handle that situation better? At some point huge with a large number of small files takes its toll.
It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?
It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?
I believe the difference is that the Linux kernel itself is not that big a project. Windows is a lot more than just a kernel; it’s more akin to having the source code for an entire Linux distribution in one repo.
You mean like Gentoo (https://github.com/gentoo/gentoo) ? It's not that big either (around 700MB).
That only includes the ebuilds, which are instructions for how to build from source, not the sources themselves.
So the sources for, say, Paint or Edge are versioned within the Windows repository?
Yes, most of the components and files in a default Windows installation are built from sources in the main Windows OS git repo.
Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.
Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.
The Windows tree is unlike the Linux tree in that the Windows tree is the entirety of Windows, not just the kernel. Not having to check out the entire tree is why GVFS was made.
https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).
https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).
I read an article a while back about why git is slower on windows than on linux (probably linked from HN, but I can't find it just now) and the TLDR is that it's because the windows filesystem (not just NTFS, but everything around it) has many customization points, and for that reason git will always be slower on windows regardless of the particular underlying FS (as in, adding windows support for, say, ext4 wouldn't fix the problem).
I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM.
In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world.
Performance was never an issue.
Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made.
I believe the success of git is due to GitHub and for many it's synonymous.
In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world.
Performance was never an issue.
Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made.
I believe the success of git is due to GitHub and for many it's synonymous.
> I started with CVS then moved to svn.
When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :)
Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do:
* git clone
* vi repo/some/file/blah
* git add/commit/push
* rm -rf repo/
When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :)
Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do:
* git clone
* vi repo/some/file/blah
* git add/commit/push
* rm -rf repo/
I'm in the same camp of rm -rf'ing (and when I were a lad we did all our computing on relays...). A fun game to play when you have spare time is to Google for how to do some random thing with git then pour up a cup of coffee and read through the 17 contradictory answers on just one SO page...
As a sysadmin (as am I), you should know how git works so you can fix it when the devs break it. :)
What do you find difficult about it?
What do you find difficult about it?
The format of a command is `git <action> <options>`, and the <action> is completely baffling to the RCS/CVS/SVN habits I've built up for the decades.
For the little while that I sometimes used Hg I found it much easier to get my head around.
It's mostly a lack of practice/use.
For the little while that I sometimes used Hg I found it much easier to get my head around.
It's mostly a lack of practice/use.
I just use a bunch of aliases to make sense of things. eg "new-branch = checkout -b" and "branches = branch".
Order of my exposure to SCM
Shared windows mount
Visual Source Safe
CVS
SVN
Perforce
ClearCase
Git
Team Foundation Server
Throw in SCCS, on SCO Unixware, and Darcs, and you match my exposure too, mostly. Now I remember what an abomination VSS was - with the mandatory locking behaviour.
It wasn't mandatory, actually. It was possible to turn off the locking. But that was like entering a whole new world of pain. So most people didn't dare turn it off.
They called it "multiple checkout", and the manual strongly recommended you do not turn it on.
The software had issues with corruption due to operations not being atomic.
They called it "multiple checkout", and the manual strongly recommended you do not turn it on.
The software had issues with corruption due to operations not being atomic.
The lack of atomic commits in VSS, CVS and ClearCase caused absolutely horrific problems, even on small teams.
I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.
I can live with the locking behavior, but VSS had a tendency of corrupting the entire repo ever few weeks that is hard to accept.
I could live with the locking or the corrupted repos if it was half decent at just sharing code, but daily we had problems where someone would check in code, VSS would say it was checked in but the person updating would get stale versions. Sometimes if you looked at the server version it be be correct but not what you would receive on a fresh checkout.
It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.
It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.
Yes, there was that too. I've seen quite a few regressions caused by this.
I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.
Source Depot is very similar to Perforce since sd started as a p4 fork.
Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
Interesting. It wasn't a bad solution at the time, being able to pass around commits was nice and more straight forward than the patch mechanism on svn. Git and Mercurial were significantly superior solutions though.
Source Depot == Perforce
As a sysadmin, how do you version your infrastructure code (things like puppet or terraform)? If another VCS, cool. If not at all, try git for it!
Some people on the other side of the Unix/Microsoft tracks started out on sourcesafe.... shudder
raises hand
dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze.
I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.
dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze.
I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.
[deleted]
Do a shallow clone and you’ll save some time.
I started with CVS in HS on a couple SourceForge projects, but skipped svn for the same reasons I used CVS sparingly: setting up servers was too much effort, (especially for non-open source stuff), especially on Windows. Instead of svn I fell hard in love for darcs in college (after the usual college tale of losing source files the day before a project was due in a stupid unix tool mishap with a command line that was one letter off from what it should have been).
Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college.
My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.)
By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better.
(As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)
Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college.
My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.)
By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better.
(As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)
>and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.
I believe those have been deprecated in favor of the evolve extension.
Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?
I believe those have been deprecated in favor of the evolve extension.
Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?
Neat. I was unaware of the evolve extension. It's interesting to see things continued to progress since I last read anything on the subject.
All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.
(Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)
I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.
All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.
(Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)
I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.
>All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations
I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".
I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".
Git was successful before github. I’d say Github was successful because of git!
I was going to write this exact comment. I'm sure the "marketing" of "Linus Made!" and "used for the Kernel!" did git some favors, but git is technically superior in my experience, despite UI short comings.
I'm sure it's changed now, but the lack of cheap fast branching was jarring.
I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.
I'm sure it's changed now, but the lack of cheap fast branching was jarring.
I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.
And perhaps because there is no good offline ui for git
So you end up using github as ui, even if you do not want to use a webpage
So you end up using github as ui, even if you do not want to use a webpage
>I'll give hg the benefit of the doubt that it eventually got better
It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.
It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.
I've been using hg since 2012 on a few decent sized repositories, and it has never been anything other than immediate.
I've got a 1.2 GB repository and it's pretty fast for that once you set Watchman up to cache tree changes. It's dog slow without that little added step though, mostly because there are a ton of small files.
[deleted]
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.
Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users.
[1]: https://en.wikipedia.org/wiki/Videotape_format_war
Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users.
[1]: https://en.wikipedia.org/wiki/Videotape_format_war
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.
this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.
this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.
It does: change evolution. It's very good.
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use
The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.
In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.)
The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.
The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.
In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.)
The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.
> The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.
I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.
I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.
> Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.
Actually, it's like saying that those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool due to a combination of the tool itself and it's ecosystem.
Actually, it's like saying that those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool due to a combination of the tool itself and it's ecosystem.
OP> The real lesson is that once a technology [loses], the people who invested in the [loser] will run around forever calling the [loser] better.
rumanator> [...] those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool
The majority doesn’t determine every persons taste. Git is the dominant DSCM; it’s well represented. Why be so defensive if some minority likes hg semantics?
rumanator> [...] those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool
The majority doesn’t determine every persons taste. Git is the dominant DSCM; it’s well represented. Why be so defensive if some minority likes hg semantics?
[deleted]
I'm sorry to be pedantic but you've used "loose" incorrectly 3 times in a row. It's "loses" and "loser"
“One particular detail” is a gigantic understatement. Having introduced several people to git, it is uniformly awful as a tool to learn, and that bad design doesn’t go away once you memorise the basics.
Yeah, my experience fits. I spent about 6 months at my first job trying to understand and use Git with AOSP. In contrast, my second job used Mercurial and I learned how to do everything Git could do in about 2 weeks, then never looked back. I always groan when someone has to use Git.
I think people tolerate Git because they really like Github.
I think people tolerate Git because they really like Github.
> I think people tolerate Git because they really like Github.
I mean, I'll add to the pile of anecdotes this thread is accumulating but I don't know if it'll convince you that people are genuine:
I struggled to learn git, but it was also my first VCS. I've needed to muck with hg a few times and vastly prefer git. Hg was fine. It didn't win my heart or anything. But it also didn't let me (at the time) branch as quickly and trivially and it was slow as hell.
Sure, that need/want may not win a hg user to git, but I'd hardly call that tolerating git.
I mean, I'll add to the pile of anecdotes this thread is accumulating but I don't know if it'll convince you that people are genuine:
I struggled to learn git, but it was also my first VCS. I've needed to muck with hg a few times and vastly prefer git. Hg was fine. It didn't win my heart or anything. But it also didn't let me (at the time) branch as quickly and trivially and it was slow as hell.
Sure, that need/want may not win a hg user to git, but I'd hardly call that tolerating git.
Git won because it's superior in a way that many programmers think doesn't matter: performance.
Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower.
"Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important.
I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.
Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower.
"Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important.
I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.
Are you working on a Linux system? I have the opposite experience with Sourcetree and Gitkraken on Windows -- git is the least responsive tool I use.
Git is the only fast tool in that stack, it's slow because of the trinity of ntfs, electron and c# that those tools are built with. When you've got slow tools on a slow file system you're going to have a slow time.
If performance mattered, people would not have adapted electron
"Premature optimization is the root of all evil" means: make it work correctly first, and then - if anybody cares - make it fast.
Readability/maintainability, then only as needed trade it off for speed, because not all code needs to be highly performant.
Mercurial works correctly but is unbelievably slow compared to git.
If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.
If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.
From the Knuth paper:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
It means make it fast in the code that matters, do not try to make it fast in every single line.
To say the quote is often misunderstood is the biggest understatement in modern computer science.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
It means make it fast in the code that matters, do not try to make it fast in every single line.
To say the quote is often misunderstood is the biggest understatement in modern computer science.
I think any good advice in software development will be widely misunderstood. At lest, I haven't seen any that wasn't.
I don't agree with the assessment that betamax was superior. Sure it had more advanced technology, but it was too expensive and much more complicated - it fit the business requirements of a home video system poorly
https://www.youtube.com/watch?v=ddYZITaxlTQ
https://www.youtube.com/watch?v=ddYZITaxlTQ
Unlike the VHS vs betamax comparison, Mercurial was not strictly-better than Git. Mercurial is quite slow in comparison and becomes brutally painful to wait for once your repo gets reasonably large.
There's also Phabricator as a self-hosted (and open source) solution for Mercurial (and Git and SVN) repositories.
https://phacility.com/
https://phacility.com/
> technically better architecture and user interface
Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.
Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.
> I think Git turned out to have the better UI [...]
I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though?
I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.
I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though?
I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.
Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs.
Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready.
I also find the model of Git much easier to understand and explain to others.
Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready.
I also find the model of Git much easier to understand and explain to others.
Mercurial copied interactive rebase from Git a long time ago and refined it with phases[1].
What do you find easier to understand and explain about Git's model?
[1] https://www.mercurial-scm.org/wiki/Phases
What do you find easier to understand and explain about Git's model?
[1] https://www.mercurial-scm.org/wiki/Phases
Yeah they copied it. They copied it because it was better. Do you think that they copied it because it was a bad UI idea? Not sure what your point is.
And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git.
Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.
And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git.
Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.
How does Mercurial feel like "it wants to just make a literal log of what I've done"? It has a UI very similar to Git's for rewriting history and a feature specifically to help do it safely.
Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture".
Git still has the problem Mercurial phases address.
A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience.
Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist.
Do you have any other examples?
Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture".
Git still has the problem Mercurial phases address.
A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience.
Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist.
Do you have any other examples?
> How does Mercurial feel like "it wants to just make a literal log of what I've done"?
Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system.
If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase.
It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.
Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system.
If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase.
It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.
> Because rebasing was literally an afterthought - a plugin
Hg extensions are just as much part of hg as the core functionality. It's just that they're opt-in parts many users don't need and thus don't have to see. If your workflow requires history editing, then fine, enable rebase and histedit.
As for mq, I think I've only used it in a script where I converted an ancient CVS repo and rewrote entire parts of the history to remove stuff that should never have been in there to begin with. It's powerful, but rarely required by anyone, and thus is opt-in as well.
Hg extensions are just as much part of hg as the core functionality. It's just that they're opt-in parts many users don't need and thus don't have to see. If your workflow requires history editing, then fine, enable rebase and histedit.
As for mq, I think I've only used it in a script where I converted an ancient CVS repo and rewrote entire parts of the history to remove stuff that should never have been in there to begin with. It's powerful, but rarely required by anyone, and thus is opt-in as well.
I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy.
But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.
But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.
Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.
As somebody that spent a lot of time trying to convince people that BSD was superior to linux and eventually having to give in when linux won due to various other reasons I know how mercurial fans can feel.
I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.
I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.
I like mercurial not because I am fan, but pragmatic and my team can work well with it. I still use it on daily basis. Indeed my team use hg-git and also git to work with GitHub for synchronizing some upstream repository of libraries we are using.
Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though.
In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.
Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though.
In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.
Linus (and linux) was the key marketing; github and MS followed.
Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.
Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.
Google contributes to Mercurial as well.
As do Facebook, if I recall correctly:
https://engineering.fb.com/core-data/scaling-mercurial-at-fa...
That's from 2014, but I don't believe they've moved away from it since. In 2018, there's this:
https://news.ycombinator.com/item?id=16565299
https://engineering.fb.com/core-data/scaling-mercurial-at-fa...
That's from 2014, but I don't believe they've moved away from it since. In 2018, there's this:
https://news.ycombinator.com/item?id=16565299
I didn't know that, I thought Google is using customised perforce and later moved to Piper for their mono repository. I do not know if Piper still use some parts of mercurial or is based on mercurial. But it's good to know Google is supporting mercurial.
Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.
Just that git (w/o the central hosting/PR concept/issues) is the total opposite than proprietary, and despite the popularity of the social network GitHub (because that what it is) the market for hosting git repos is very active. Look at Gitlab, Bitbucket, Azure Repos, AWS, ... which are all just fine.
I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.
I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.
Another way to host Git code using 100% FOSS software is with https://sourcehut.org/ and of course it’s possible to host your own GitLab community edition server as per https://about.gitlab.com/install/
Sourcehut supports mercurial, too!
The UI is a hot mess though. Every time I try out their Mercurial site (it's actually a separate site, not just a feature of the main site) I always somehow end up on the Git part of the site and there's no obvious way back.
Moreover, SourceHut also is the only system that supports[1] both FreeBSD and OpenBSD as CI platforms. NetBSD is coming soon too.
[1] https://man.sr.ht/builds.sr.ht/compatibility.md
[1] https://man.sr.ht/builds.sr.ht/compatibility.md
Another happy user of Kallithea here!
I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.
I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.
Kallithea was an option 2 years ago, now the development of it is basically dead. Rhodecode is still releasing regularly. Just check the feature differences: https://rhodecode.com/blog/133/rhodecode-vs-kallithea-compar...
Who says development is dead. Please check the changelog.
https://kallithea-scm.org/repos/kallithea/changelog
Now lets look at Rhodecode. https://code.rhodecode.com/rhodecode-enterprise-ce
You will notice that Kallithea has been consistently updated regularly. Besides user like me its also used internally at Unity Engine.
Also the features you mentioned not all are in Rhodecode open source edition.
https://kallithea-scm.org/repos/kallithea/changelog
Now lets look at Rhodecode. https://code.rhodecode.com/rhodecode-enterprise-ce
You will notice that Kallithea has been consistently updated regularly. Besides user like me its also used internally at Unity Engine.
Also the features you mentioned not all are in Rhodecode open source edition.
I'm not really following the "commits" but rather following releases. In the last 2 Years Kallithea had only 1 minor release (https://pypi.org/project/Kallithea/#history) 0.3 -> 0.4 without many new features. RhodeCode had 5 minor releases (https://docs.rhodecode.com/RhodeCode-Enterprise/release-note...) and multiple bugfix releases. I'm aware not all features in comparison are free, but we use the CE free version and it's enough for us at this point.
Actually 0.3 to 0.4.1 is a major release with many changes including new mercurial versions and better git support with updated UI and celery for background tasks. If you see a new ssh feature is just added with documentation.
Kallithea is pretty easy to work with and extend. We recently updated and built a CI using buildbot. Rhodecode and Kallithea have diverged enough and are moving differently. Also its a Software freedom conservancy project so it will be supported, hopefully it can attract bit larger community.
Kallithea is pretty easy to work with and extend. We recently updated and built a CI using buildbot. Rhodecode and Kallithea have diverged enough and are moving differently. Also its a Software freedom conservancy project so it will be supported, hopefully it can attract bit larger community.
On a side note on this. I think Unity had their own fork of Kallithea with some changes that aren't in the official version ? Or those features are backported later from the Unity release
I believe some of the unity developers are constantly creating pull request to update Kallithea and are core developers.
Can't say for sure but I think Unity's system Ono is using Kallithea as core with additional plugins developed for their own use.
Can't say for sure but I think Unity's system Ono is using Kallithea as core with additional plugins developed for their own use.
As you said it's sad but fortunately we have Rhodecode. In my previous company I was using Rhodecode plus mercurial and for developer working with it was a pleasure.
Now in current company we using Bitbucket, we'll think then to moving to rhodecode because we still want to use Mercurial
“a single proprietary solution Github by Microsoft”
Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands:
Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands:
git clone https://github.com/foo/bar
vi bar/.git/config # Add new remote location
cd bar
git push baz master
One-liner to change the URL of the upstream repo:
git remote set-url origin <new URL> # Add new remote location
cd bar
git remote add neworigin https://newserver.com/foo/bar
git push --set-upstream neworigin masterAnd what about the issue tracker? Issues and discussions of pull requests would be lost by merely moving the code.
I'm working on this, have a look at https://github.com/MichaelMure/git-bug
you can import github projects including issues and stuff into gitlab
https://docs.gitlab.com/ee/user/project/import/github.html
https://docs.gitlab.com/ee/user/project/import/github.html
Some thing would be lost, yes [1] but the core code and commit history would be preserved. Issues can still be re-opened if still relevant, and pull requests can still be seen in the commit history. Comments on pull requests, if not approving a pull, will result in additional commits to the code which will be preserved.
Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam.
[1] Including branches unless one runs a script to go to and clone each branch to the new repo
Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam.
[1] Including branches unless one runs a script to go to and clone each branch to the new repo
I've been using Mercurial and git for a long time and I have to say git's workflow is a lot better. Mainly Mercurial doesn't let me pull or do other stuff with outstanding changes, for no apparent reason other than that the author wanted it that way.
Mercurial lets you pull and even update with outstanding changes.
This is one of my biggest pain points with hg vs git: Git is actually the one that flat-out prevents me from rebasing most of the time, usually for the most spurious of reasons, whereas hg just lets me choose to auto-rebase most files and pick the ones I'm interested in to manually merge.
And makes a mess of conflicts. I would rather not be able to do those things than to fix a conflict of a head with the working files on HG.
> doesn't let me pull or do other stuff
Not sure what that means?
Not sure what that means?
It just doesn't let me do things with changes in the working copy sometimes where git does. It's really annoying.
I'm using RhodeCode, and so far it has been working great for both git and mercurial repo hosting - paired with Concourse CI it makes for a great combo.
I still write my software in Pascal and store it an Mercurial repo on Sourceforge
It was just the best development environment on windows
It was just the best development environment on windows
It's funny to see how the whole world concentrates on this Git thing, while there is a treasure trove called Mercurial.
Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.
I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.
Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.
I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.
The ease of use is a big thing for me. I find Git a bit arcane -- it's better than it used to be (around the Hg 0.9 era), but it's still quite bad.
Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.
I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.
Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.
Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.
Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.
I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.
Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.
Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.
> Git will let you blow away a month's work if you mistype a command.
It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.
Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.
Management asked "what if you do that with Mercurial?"
Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can.
TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.
Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.
Management asked "what if you do that with Mercurial?"
Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can.
TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.
> Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.
Was "asking someone who knows how git works" on your list of things to try?
What about "learning how git works"? Was that on your list?
Frankly, you don't seem to have been trying very hard to get this work back.
Was "asking someone who knows how git works" on your list of things to try?
What about "learning how git works"? Was that on your list?
Frankly, you don't seem to have been trying very hard to get this work back.
> Was "asking someone who knows how git works" on your list of things to try?
If I can make an analogy.
There's little love lost on HN for C++. Anytime people mention C++ (possibly even here in this thread) people come out of the woodwork to talk about how hard it is to use, how it has too many features, blah blah.
I work in C++ every day. I don't think it's that hard.
When I have a question, I walk over and ask Chandler Carruth and Richard Smith. They are happy to help me debug my templates. Richard is the editor of the C++ spec, and Chandler is a well-known speaker, look him up on YouTube.
Over lunch we talk about new features of C++, we rant and gripe, and I learn.
Most people do not have Chandler and Richard in their life. Knowing them and the other experts on my team is a huge privilege. So when someone complains that C++ is too hard (wait for it, someone is going to do it here in this very thread...), it would be pretty insensitive of me to tell them that they should just ask someone who knows how C++ works.
Most of us in this thread do have someone in our life who is good at git, who helped us get started, and who saved our asses when we initially got stuck. Maybe that person isn't with us IRL, maybe that person is "just" a message board or IRC channel where we know we're welcome. But this too is a privilege.
If you've ever had trouble with anything and not had someone you could ask -- be it with C++, or real analysis, or whatever -- then I'd say you shouldn't throw stones at someone whose "whatever" happens to be git.
If I can make an analogy.
There's little love lost on HN for C++. Anytime people mention C++ (possibly even here in this thread) people come out of the woodwork to talk about how hard it is to use, how it has too many features, blah blah.
I work in C++ every day. I don't think it's that hard.
When I have a question, I walk over and ask Chandler Carruth and Richard Smith. They are happy to help me debug my templates. Richard is the editor of the C++ spec, and Chandler is a well-known speaker, look him up on YouTube.
Over lunch we talk about new features of C++, we rant and gripe, and I learn.
Most people do not have Chandler and Richard in their life. Knowing them and the other experts on my team is a huge privilege. So when someone complains that C++ is too hard (wait for it, someone is going to do it here in this very thread...), it would be pretty insensitive of me to tell them that they should just ask someone who knows how C++ works.
Most of us in this thread do have someone in our life who is good at git, who helped us get started, and who saved our asses when we initially got stuck. Maybe that person isn't with us IRL, maybe that person is "just" a message board or IRC channel where we know we're welcome. But this too is a privilege.
If you've ever had trouble with anything and not had someone you could ask -- be it with C++, or real analysis, or whatever -- then I'd say you shouldn't throw stones at someone whose "whatever" happens to be git.
Ok, then I'll give you an analogy in return:
Someone posts that they'd tried to join two strings in C++ and print the result. And they couldn't figure out how to do it; they would keep losing the second string. So, they gave up and changed languages, losing a month's worth of work.
Would you think that was reasonable, because they didn't have Chandler Carruth and Richard Smith available to help?
Someone posts that they'd tried to join two strings in C++ and print the result. And they couldn't figure out how to do it; they would keep losing the second string. So, they gave up and changed languages, losing a month's worth of work.
Would you think that was reasonable, because they didn't have Chandler Carruth and Richard Smith available to help?
> Would you think that was reasonable
The thing I object to is judging them at all.
They're not my coworker, someone I have to rely on and therefore might be annoyed if they're unproductive or whatever. They're a random person on the Internet who rather humbly admitted to making a mistake out of ignorance.
The thing I object to is judging them at all.
They're not my coworker, someone I have to rely on and therefore might be annoyed if they're unproductive or whatever. They're a random person on the Internet who rather humbly admitted to making a mistake out of ignorance.
Completely agree. Furthermore, I'm able to keep C and Common Lisp and most of Javascript and a bunch of other languages and Mercurial in my head (brain cache) so I rarely have to ask somebody how to use them.
But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.
But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.
To be frank, your sales technique needs work.
To be frank, I've no interest in selling anything so don't need a sales technique. To be franker, I think the OP was talking crap. No-one loses a month of work and doesn't think to get advice on how to fix it. It's just a stupid "git is bad" story.
That's not the point, the point is that Git is a really bad interface to a really powerful system.
Have you tried to operate an excavator? That thing is complicated compared to a car... But you know what? That is specialist tool. If you cannot operate with specialist tools you should not get a job of a specialist.
I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76
I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76
I'm quite adept at driving an excavator. I can pour wine out of the bucket of an excavator. It's quite easy with practice because muscle memory kicks in.
But if excavators were as hard to use as git, I'd never have mastered them.
But if excavators were as hard to use as git, I'd never have mastered them.
I wouldn't say "programmers who use version control" are a group of people who would qualify as "specialists". Especially since all programmers should be using version control. It should be a fundamental skill necessary to entering the field.
This was years ago, when Git was relatively new (around the time Mercurial was at v0.8-0.9).
Our "Git expert" was the one who blew away a month of work.
Our "Git expert" was the one who blew away a month of work.
> I've lost a day's work to a mistyped "git revert HEAD~n"
Mistyped as "git reset --hard HEAD~n"? git-revert is usually pretty nondestructive…
Mistyped as "git reset --hard HEAD~n"? git-revert is usually pretty nondestructive…
Fuck that guy. Seriously if someone is in silo mode for a month I am going to fire that guy.
He is doing either some dangerous changes, which is not acceptable OR he is doing something that could be walled off by feature switch and integrated with at least weekly commits.
If it was some manager that told him to do that, fire that manager too!
He is doing either some dangerous changes, which is not acceptable OR he is doing something that could be walled off by feature switch and integrated with at least weekly commits.
If it was some manager that told him to do that, fire that manager too!
You know that you can revert a revert, right?
> I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.
Don't you have backups? The companies I worked for had backups for all the home directories, so if I deleted something I could ask the admins to restore it.
If there are no central backups I would sure as hell set up a local backup, so there are more than one copies of my work in case something goes bad.
Don't you have backups? The companies I worked for had backups for all the home directories, so if I deleted something I could ask the admins to restore it.
If there are no central backups I would sure as hell set up a local backup, so there are more than one copies of my work in case something goes bad.
> git revert HEAD~n
You could just revert your revert commit, or check out an earlier revision.
You could just revert your revert commit, or check out an earlier revision.
> While it's easy to blow away work you haven't committed
This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.
This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.
I don't believe hg is any better in this respect.
I can tell you that it is in at least one use case that I've hit. If you have local uncommitted changes to a file, and then run `hg revert file` to undo your changes, it creates (by default) a ".orig" backup. The equivalent git command (`git checkout --hard` or something?) will just throw out local changes with no takebacks.
I would absolutely love it if Git had this feature. Having it on Hg has saved me so many times.
> every commit you've made in the past month is saved in the reflog
I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."
I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."
Just in the case you didn't know, you can view the reflog with `git reflog`
From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.
From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.
> Git will let you blow away a month's work if you mistype a command.
No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.
No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.
I've never worked at a company with protected branches... even though it's best-practice. "Because some day someone might need to push to master to do a hotfix".
So I have a local git push hook which blocks master pushes :)
So I have a local git push hook which blocks master pushes :)
> Git will let you blow away a month's work if you mistype a command.
Fortunately, that can always be undone with another command
Fortunately, that can always be undone with another command
How to undo
git checkout .
?That's like asking how to undo `rm -rf`
It really is. Sure, it is an issue that it's the same subcommand as you use for many other things (which is being worked on with git switch/restore), but there is no other context where you'd do `git checkout .` if it wasn't your direct intention to get rid of changes in your workspace.
Mercurial creates backup files though.
> Git will let you blow away a month's work if you mistype a command
What's the command to mistype?
What's the command to mistype?
Maybe git push -f my-branch
I can't imagine having a month of work on a local machine that hasn't been pushed anywhere so it has to be something about pushing.
I can't imagine having a month of work on a local machine that hasn't been pushed anywhere so it has to be something about pushing.
One thing I love about git is how it makes it almost impossible to lose work once it's committed. That's why I commit early and often.
At least on Windows Mercurial doesn't support filenames written in various languages. Git does. So Mercurial was made for one billion people while git for the rest 6.5 billion of us.
What does "written in various languages" mean? Mixing multiple legacy encodings in one filename? Unicode filenames work fine on Linux (I just tested it with Chinese) and I would be very surprised if they didn't on Windows.
The problem, as I understand it, was filenames were read and written as bytes. That's fine if everybody is on the same platform but it doesn't always work when moving between, for example, Linux (UTF-8) and Windows (UTF-16).
I don't know if that's still an issue.
I don't know if that's still an issue.
Hm, the Mercurial wiki does mention that's it was/is a problem on Windows.
I was surprised because we've been using it for years at work, sharing repositories between Linux and Windows, and we have never been bitten by this. Maybe the latin-1 subset of Unicode works? Or all the files we worked on just happened to have ASCII names (despite us being mostly non-Americans).
I was surprised because we've been using it for years at work, sharing repositories between Linux and Windows, and we have never been bitten by this. Maybe the latin-1 subset of Unicode works? Or all the files we worked on just happened to have ASCII names (despite us being mostly non-Americans).
Unfortunately, on Linux, filenames are actually bytes, not utf-8.
Well yes and on Windows they are a sequence of 16bit values, not utf-16. My point was the encoding of filenames differ. So you can't do a byte-for-byte copy and expect the same results across platforms.
As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.
As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.
Various languages mean letters other than ASCII. They don't on Windows.
And yet people overwhelmingly chose Git. Why is that?
IMHO: Because Github just came at the right time for a free "no strings attached" project hosting solution when Sourceforge decided to become evil. That was the reason why I switched to Github anyway.
That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.
After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.
Nobody expected that Github was essentially a Trojan horse ;)
That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.
After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.
Nobody expected that Github was essentially a Trojan horse ;)
It’s even more specific than that. GitHub chose “free public repos, paid private repos” as their business model and git as their DVC. Bitbucket chose the opposite.
GitHubs model is incredibly more viral and thus git won (sadly IMO).
GitHubs model is incredibly more viral and thus git won (sadly IMO).
Bitbucket had free private repos and free public repos.
Interesting, would like to hear more about why that is?
No clue. I thought for sure Mercurial would come out ahead, it had some proponents:
* Bitbucket provided unlimited free private repositories and they were exclusively Mercurial. Github had limits for private repos.
* Google evaluated both and preferred Mercurial for code.google.com http://www.saturngod.net/articles/dvcsanalysis-support-analy....
* Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln
Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is
* git was strongly associated with Linus so it won that crowd handily
* Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
* Bitbucket provided unlimited free private repositories and they were exclusively Mercurial. Github had limits for private repos.
* Google evaluated both and preferred Mercurial for code.google.com http://www.saturngod.net/articles/dvcsanalysis-support-analy....
* Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln
Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is
* git was strongly associated with Linus so it won that crowd handily
* Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
> Github had a stronger association with open source than Bitbucket (dunno why though).
Early on GitHub gave out free public repositories, but Bitbucket gave our free private repositories. Working in public is aligned much more closely with open source than working in private is.
Early on GitHub gave out free public repositories, but Bitbucket gave our free private repositories. Working in public is aligned much more closely with open source than working in private is.
As others have mentioned before, one possible reason could be performance, git commands work near instantaneously even for very large repos, perhaps mercurial was not able to offer a similar experience.
> * Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
Maybe because it was bought by Atlassian.
Maybe because it was bought by Atlassian.
> Maybe because it was bought by Atlassian.
Nope! Bitbucket had the "free private, paid public" model from the start. IIRC, Atlassian actually changed the model to allow unlimited public repositories after they purchased Bitbucket. It's possible that if BB had started with this model, they'd have been a much stronger competitor.
Nope! Bitbucket had the "free private, paid public" model from the start. IIRC, Atlassian actually changed the model to allow unlimited public repositories after they purchased Bitbucket. It's possible that if BB had started with this model, they'd have been a much stronger competitor.
I used both at the same time at work for about 2 years, and mercurial was worse.
Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.
I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.
Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.
I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.
Linus Torvalds made it. That at least got me to look into it. Then saw it was better than svn and never looked back. Or sideways, so I missed mercurial.
git was faster.
i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.
i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.
At this point, network effect
Network effect and first mover advantage.
But they were both released at around the same time. Or at least near enough that they were both serious contenders for awhile.
Mercurial was a bit slow in the first years.
It's still probably slower for huge repos (I havn't checked), but I doubt it will bother you much nowadays.
I used Hg before Git professionally, because when they were both new, Hg had _much_ better Windows support.
It's still probably slower for huge repos (I havn't checked), but I doubt it will bother you much nowadays.
I used Hg before Git professionally, because when they were both new, Hg had _much_ better Windows support.
Many will not admit it, but git is just better.
Back in 2008 I made a presentation about DSCVS where I introduced git, mercurial and bazaar, and my advice for fellow programmers was "use git".
[deleted]
> June 1, 2020: ... all Mercurial repositories will be removed.
It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).
Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.
It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).
Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.
This reminds me of patio11's analysis of tarsnap from a few years back: https://news.ycombinator.com/item?id=7523953
"all Mercurial repositories will be removed"
does indeed sound quite at odds with why people use Bitbucket. dissonance re core value-proposition.
I hope Atlassian finds a less destructive way to phase out Mercurial support. Gladly they do have enough time to clarify / reconsider.
"all Mercurial repositories will be removed"
does indeed sound quite at odds with why people use Bitbucket. dissonance re core value-proposition.
I hope Atlassian finds a less destructive way to phase out Mercurial support. Gladly they do have enough time to clarify / reconsider.
That's especially weird since serving Mercurial repositories in read only mode doesn't require any infrastructure apart from a static HTTP server.
Full bullet text:
"""
* February 1, 2020: users will no longer be able to create new Mercurial repositories
* June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.
"""
The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.
The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.
But as you say the second part should be punted way into the future if not never.
Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.
"""
* February 1, 2020: users will no longer be able to create new Mercurial repositories
* June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.
"""
The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.
The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.
But as you say the second part should be punted way into the future if not never.
Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.
I don't think it's about disk space at all.
Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.
Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.
They don't need to allow browsing it; but at least have a minimal page which shows the presence of the repository, and allow cloning it.
Or just provide a link to a tarball download.
Cloning it still runs code they don't want to run on their servers.
No. You just need a dumb webserver, no extra code needed.
They could just convert them to Git repos automatically. If you do that manually, their press release implies that the repos will stay around. So it can't be a disk space issue. Why haven't they offered to do this rather than just remove them?
According to the comments on the OP they tried to make a tool but couldn't make sure it would work in all cases for all repos, so they decided to not make a tool (and delete our repos instead). Such a disgrace.
The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.
The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.
The Mercurial data model is a superset of git's. A lossless conversion is simply not possible in that direction.
It’s very expensive to maintain two SCM implementations in something like Bitbucket and maintain feature parity between the two. Poor cost/benefit ratio.
I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.
I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.
> we had introduced Git repositories, Git usage grew an order of magnitude almost overnight
Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.
Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.
[deleted]
They link to an SO survey:
* https://insights.stackoverflow.com/survey/2018#work-_-versio...
where "zip backups" and network copy (each 7.9%) and "no version control" (4.8%) are higher than Mercurial (3.6%).
If you're in that boat, I can understand not using git (87%) because its UI sucks (IMHO), and not using SVN (16%) because it needs infrastructure, but Mercurial has neither of those hindrances. Heck, even RCS would be better than nothing at that point, and Hg is better than that.
* https://insights.stackoverflow.com/survey/2018#work-_-versio...
where "zip backups" and network copy (each 7.9%) and "no version control" (4.8%) are higher than Mercurial (3.6%).
If you're in that boat, I can understand not using git (87%) because its UI sucks (IMHO), and not using SVN (16%) because it needs infrastructure, but Mercurial has neither of those hindrances. Heck, even RCS would be better than nothing at that point, and Hg is better than that.
Well git is the go-to default at many companies, so junior developers, if they learn anything, will learn git. People using network copy, no version control, or zip backups didn't choose those answers because they preferred them to mercurial; rather, they ended up with those because they either don't yet know about or understand how to use git (or any vcs).
IMHO mercurial's usage is so low because github/gitlab don't support it. I understand bitbucket not wanting to, but it says nothing about what mercurial's usage would be like if people didn't have to choose between it and being able to use github or gitlab.
Hi GitLab employee. While we don't officially support it, there is a friendly fork project of GitLab CE that does, and we do provide official support to them :) https://heptapod.net/
I'm not a Mercurial user, but some might be interested on this team that's working on adding Mercurial support to Gitlab, currently in the from of a fork or distribution called Heptapod:
https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_19...
https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_19...
Thanks for sharing, ppl may be headed to Gitlab then.
Sourcehut has Mercurial support. It's open source and community maintained, and will remain supported for as long as the Hg community wants it to be. We recently took our Hg team out to Paris to meet the Mercurial community at the first Hg conference, and discussed how we can get involved in the future of Mercurial and committed to continuing to improve our offering into the foreseeable future.
I've whipped together a script to help you migrate your repos to hg.sr.ht, for those interested:
https://hg.sr.ht/~sircmpwn/invertbucket
Let me know how it works out for you - I'd like to hear some test results before I post it to sr.ht-announce. Cheers :)
I've whipped together a script to help you migrate your repos to hg.sr.ht, for those interested:
https://hg.sr.ht/~sircmpwn/invertbucket
Let me know how it works out for you - I'd like to hear some test results before I post it to sr.ht-announce. Cheers :)
One important feature is unfortunately missing: to also clone the wiki (which on Hg projects is a Hg repo in its own right). But that would probably pose a bigger problem, given that Sourcehut appears to have no feature like the (Gollum-based) Wikis in GitHub and GitLab (not sure what they were based on in Bitbucket, though).
Thanks for making `invertbucket`! I used it to import my bitbucket repositories and ran into a few issues:
1. `invertbucket` should check that the machine has `hg` installed. (I accidentally ran it on a machine that didn't.)
2. Say my sr.ht username is "thegreengiant" and my bitbucket repository is "abc". At the end of its run, `invertbucket` says:
> Imported to: https://hg.sr.ht/srht_owner/abc
That URL 404s. It would be an improvement if `invertbucket` replaced "srht_owner" with "~thegreengiant".
1. `invertbucket` should check that the machine has `hg` installed. (I accidentally ran it on a machine that didn't.)
2. Say my sr.ht username is "thegreengiant" and my bitbucket repository is "abc". At the end of its run, `invertbucket` says:
> Imported to: https://hg.sr.ht/srht_owner/abc
That URL 404s. It would be an improvement if `invertbucket` replaced "srht_owner" with "~thegreengiant".
Thanks for the feedback! Fixed on both counts.
What sr.ht URL path would I use to get a page to render as markdown? hg.sr.ht/~thegreengiant/raw/default/foo.md renders as text.
Evaluating hg.sr.ht right now. On quick scan I saw that man.sr.ht has no API reference for hg - I was wondering what the status for that bit is. Thanks!
man.sr.ht has an API which is equivalent to git.sr.ht's API except for the portions which deal with querying git data:
https://man.sr.ht/git.sr.ht/api.md
So you can create and manage repos over the API today. We're still figuring out a good API design for fetching hg data over REST.
https://man.sr.ht/git.sr.ht/api.md
So you can create and manage repos over the API today. We're still figuring out a good API design for fetching hg data over REST.
Sigh. I really hate seeing hg languish like this. Command line is nicer, and I have yet to find any git gui frontend that matches what TortoiseHG can do (both in terms of invocating dialogs from the cmdline; and in terms of presenting and manipulating the graph).
I really hope something happens to help hg start accumulating more market share. Not just for my opinion on the tooling; but because IMO the "git = github = the only place for opensource" monoculture is kinda problematic.
I really hope something happens to help hg start accumulating more market share. Not just for my opinion on the tooling; but because IMO the "git = github = the only place for opensource" monoculture is kinda problematic.
The best TortoiseHg equivalent I've found (after a lot of searching) is SmartGit [1]. It's not as good as TortoiseHg and its not free but it's nice enough for most of my use cases.
[1] https://www.syntevo.com/smartgit/
[1] https://www.syntevo.com/smartgit/
Thanks for the pointer. I'll see if my company will "sponsor" me a copy. Looks nice indeed.
I've been using Bitbucket with Mercurial repositories since 2011, both for private and public repos. I can count more than 50 mercurial repos that I'll need to manually move somewhere else. I'm really disappointed right now. I can understand their motives but they need to provide a single click method to at least convert a repo to git (this is a MUST IMHO).
I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.
I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.
I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.
I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.
Move your repos to hg.sr.ht: https://hg.sr.ht/~sircmpwn/invertbucket
I'll consider it, thanks for sharing.
Hg already works with Python 3, and tortoisehg's Python 3 development is proceeding at a rapid pace. They're not dead, they just left it to the last minute, relatively speaking. I expect them both to make the cutoff of Python 2 EOL with stable releases.
The releases being out of sync is not great, but if you're on Windows you download tortoisehg with a compatible hg, and if you're not your distro's repositories should ensure they don't push a new hg to you before tortoisehg is updated. I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks. Not a big deal. On Arch Linux since tortoisehg isn't in the repos it's a slight pain to hold back mercurial. Hopefully after the Python 3 transition tortoisehg makes it into the repos.
...though if there is not mercurial hosting available by the time bitbucket sunsets support, then maybe I won't care. I really want to keep using mercurial for my public open-source projects.
The releases being out of sync is not great, but if you're on Windows you download tortoisehg with a compatible hg, and if you're not your distro's repositories should ensure they don't push a new hg to you before tortoisehg is updated. I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks. Not a big deal. On Arch Linux since tortoisehg isn't in the repos it's a slight pain to hold back mercurial. Hopefully after the Python 3 transition tortoisehg makes it into the repos.
...though if there is not mercurial hosting available by the time bitbucket sunsets support, then maybe I won't care. I really want to keep using mercurial for my public open-source projects.
I didn't know that Hg already works with Python 3, that's great! The problem is that most distributions still will distribute the Python 2.7 version, I guess it makes sense until TortoiseHG catches up with Mercurial. I hope this happens soon, but I think that I'm going to switch to Git for the convenience of using GitHub over the other solutions (for open source projects the visibility is a good plus, for private projects I think GitLab is on par on features).
> I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.
3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.
In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.
> I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.
3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.
In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.
Yep, wholeheartedly agree that it will have a bad impact. However, to me Git is nothing I would use voluntarily in my spare time as it is so hostile to its users (not to mention the conceptual shortcomings and outright questionable "features"). So for me it will be Mercurial and if that means helping out with Heptapod and/or other projects, so be it.
This suck big time.
HG is by far the best UX of all SCM I have used. Without bitbucket I think usage of hg will drop even faster.
The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
I wonder why the worst always win? C, C++, JS, MySql.
Don't tell me is for "speed" or "features". Is incredible how much stupid effort and money go in put a lipsick on top of that when nicer ways exists... and are know... and have proved to work... and even faster (look at you, C/C++ build times)...
Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?
Probably only python of the "good" side have critical mass...
HG is by far the best UX of all SCM I have used. Without bitbucket I think usage of hg will drop even faster.
The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
I wonder why the worst always win? C, C++, JS, MySql.
Don't tell me is for "speed" or "features". Is incredible how much stupid effort and money go in put a lipsick on top of that when nicer ways exists... and are know... and have proved to work... and even faster (look at you, C/C++ build times)...
Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?
Probably only python of the "good" side have critical mass...
> The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
Like what? I've been using git for 5 years and I hardly ever stray from the set {push, pull, reset, checkout, rebase}. I use VSCode for staging, committing, diffing, etc. though, so that probably spares me some commands, but I rarely (if ever?) have had to do what I would consider an "arcane" command.
> Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?
Git has improved over time. Why, in the latest release they improved UX for the "checkout" command. Before it could mean "switch branch" or "restore file" but now there are 2 explicit commands: "git switch" (for switching branches) and "git restore" (for restoring files).
Like what? I've been using git for 5 years and I hardly ever stray from the set {push, pull, reset, checkout, rebase}. I use VSCode for staging, committing, diffing, etc. though, so that probably spares me some commands, but I rarely (if ever?) have had to do what I would consider an "arcane" command.
> Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?
Git has improved over time. Why, in the latest release they improved UX for the "checkout" command. Before it could mean "switch branch" or "restore file" but now there are 2 explicit commands: "git switch" (for switching branches) and "git restore" (for restoring files).
The buzzwordiest always win because managers seem to rely on whatever comes up first in a web search. And that's typically Scrum, not Kanban. It's Git, not Mercurial.
Managers won't have to work with the tools they impose on their subordinates. It's the subordinates who have to. But I have also noticed how a lot of people profess to "like" Git for spurious reasons like because it's (allegedly) "so powerful", but then they stick to the simplest workflow possible, because they don't have a clue about intermediate or advanced uses. But that same logic can seemingly also be applied to why C++ "won" (not that I dislike C++ as much as Git, though). The charm is in how powerful it seems to be, but then you use loads of third-party abstractions and throw the alleged performance benefits out of the window.
For an SCM tool I want it to stay out of my way. It's meant to assist me in doing my main job. An SCM should not require my attention all the time because of the shitty CLI, inconsistent subcommands, horrible and incomplete documentation seeping with tool-specific terminology (see man gitglossary) and incomplete (or unidirectional) support for important features (git clone [here] [there], git push to remote with worktree).
Git manages to always require ones attention, and typically in the worst way possible.
Managers won't have to work with the tools they impose on their subordinates. It's the subordinates who have to. But I have also noticed how a lot of people profess to "like" Git for spurious reasons like because it's (allegedly) "so powerful", but then they stick to the simplest workflow possible, because they don't have a clue about intermediate or advanced uses. But that same logic can seemingly also be applied to why C++ "won" (not that I dislike C++ as much as Git, though). The charm is in how powerful it seems to be, but then you use loads of third-party abstractions and throw the alleged performance benefits out of the window.
For an SCM tool I want it to stay out of my way. It's meant to assist me in doing my main job. An SCM should not require my attention all the time because of the shitty CLI, inconsistent subcommands, horrible and incomplete documentation seeping with tool-specific terminology (see man gitglossary) and incomplete (or unidirectional) support for important features (git clone [here] [there], git push to remote with worktree).
Git manages to always require ones attention, and typically in the worst way possible.
I'd like git internals (merkle-tree etc.) with Mercurial's CLI UI, I think.
You may be interested in OpenBSD’s front end *(uses the git on-disk format, apparently)
https://gameoftrees.org/
https://gameoftrees.org/
Trippy, it seems like advancing sideways...
It's quite possible to write your own Git CLI, the fundamentals are well exposed.
It works until it doesn't. One of the biggest problems with Git IMO is that it always exposed a plethora of internals which therefore have become public interfaces. One is to be expected to know the guts of .git as an intermediate/advanced user. And because those are interfaces, it's _always_ going to be very difficult to fix issues arising from previous wrong design decisions.
Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll get by with a dozen or so command line invocations overall. And I found it astonishing and disheartening how so many people were able to make do with completely illogical commands like "git checkout -b" ...
But once Git sticks you the finger and you _need_ to delve down into its guts, you often have a problem.
Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and web interfaces like GitHub glossing over numerous shortcomings of Git have certainly helped the UX and the popularity. But once you _have to_ delve down to CLI usage because you ran into an issue that your tool tries to gloss over, most people are at a loss. And most people will opt to scrap the current clone+worktree and clone anew. That doesn't really sound to me like people are in command of their tool of choice (Git), though.
And at this point we haven't even touched stuff like refs which only differ in case. It's all fine until Git starts unpacking the refs. Which can be fun on systems like macOS and Windows which have support for case-sensitivity in the file system, but who opted to forgo that via a setting.
Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll get by with a dozen or so command line invocations overall. And I found it astonishing and disheartening how so many people were able to make do with completely illogical commands like "git checkout -b" ...
But once Git sticks you the finger and you _need_ to delve down into its guts, you often have a problem.
Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and web interfaces like GitHub glossing over numerous shortcomings of Git have certainly helped the UX and the popularity. But once you _have to_ delve down to CLI usage because you ran into an issue that your tool tries to gloss over, most people are at a loss. And most people will opt to scrap the current clone+worktree and clone anew. That doesn't really sound to me like people are in command of their tool of choice (Git), though.
And at this point we haven't even touched stuff like refs which only differ in case. It's all fine until Git starts unpacking the refs. Which can be fun on systems like macOS and Windows which have support for case-sensitivity in the file system, but who opted to forgo that via a setting.
That's a good point. I could probably strap together click and Dulwich and bang out something in a day or two.
https://palletsprojects.com/p/click/
https://click.palletsprojects.com/en/7.x/
https://www.dulwich.io/
https://palletsprojects.com/p/click/
https://click.palletsprojects.com/en/7.x/
https://www.dulwich.io/
> Don't tell me is for "speed" or "features"
In this case it was speed. Git respected the time of it's users and hg respected the time of it's developers more, it's in no way surprising that users picked git.
> The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
IME the only people that struggle with git are people that refuse to learn it, properly learn it and not "pick it up as you go". It's such a small time investment that pays off for any professional.
In this case it was speed. Git respected the time of it's users and hg respected the time of it's developers more, it's in no way surprising that users picked git.
> The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
IME the only people that struggle with git are people that refuse to learn it, properly learn it and not "pick it up as you go". It's such a small time investment that pays off for any professional.
I will be affected. I think I will take a serious look at sourcehut[1] now. I get a good vibe, but the bus factor scared me away before.
[1] https://hg.sr.ht/
[1] https://hg.sr.ht/
Don't worry, in the event of my untimely demise there are trusted people with access to the servers to pick up the mantle.
Sir, I wish you long life and godspeed, but my threat model includes acquihire and lost interest ;)
However, I keep talking how we need to avoid monocultures, so I guess it is about time I assume some minor risk.
However, I keep talking how we need to avoid monocultures, so I guess it is about time I assume some minor risk.
https://man.sr.ht/billing-faq.md
Sourcehut has accepted no external funding and once the alpha period ends, all accounts must be paid. Even with optional payment, it already turns a profit. I'm pretty confident in the sustainability of the service.
As for me losing interest, the good news is that I need software hosting no matter what I'm working on, so I'll always be working on it. And, since it's open source and patches are welcome, so could you add anything you need.
Sourcehut has accepted no external funding and once the alpha period ends, all accounts must be paid. Even with optional payment, it already turns a profit. I'm pretty confident in the sustainability of the service.
As for me losing interest, the good news is that I need software hosting no matter what I'm working on, so I'll always be working on it. And, since it's open source and patches are welcome, so could you add anything you need.
You just got another paid user. I am very much in the amateur hacker camp, so I might not add much revenue. Anyway, thanks for sourcehut. Mercurial is my preferred way. I have managed to shoot myself in the foot so many times with git that I just gave up on it and since it is my hobby I don't want to spend much time with git.
Welcome to sourcehut!
It would be interesting to read a breakdown of why Mercurial failed against Git. It is superior to Git in every way except performance and adoption. Git won because GitHub won, and I bet GitHub chose Git over Hg's Python implementation because it was too slow.
I wonder if Mercurial would have won if it was implemented in C or Rust (had it existed then).
I wonder if Mercurial would have won if it was implemented in C or Rust (had it existed then).
> It is superior to Git in every way except performance and adoption.
Performance is such an important advantage, though.
I type git diff hundreds of times a day, and when I switched from hg to git at Mozilla, this made such a big difference in my life.
These days I type hg histedit maybe fifty times a day at Google, and I cry every time because it is so. glacially. slow. hg diff too. And I'm working with a relatively small repository.
Speed matters for tools we use all the time.
I'd also posit that the process of writing "plugins" for git is much easier than writing hg plugins. A git "plugin" is just a shell script that uses git. If you can use git, you can write a shell script that uses it. An hg plugin...whoaboy.
Performance is such an important advantage, though.
I type git diff hundreds of times a day, and when I switched from hg to git at Mozilla, this made such a big difference in my life.
These days I type hg histedit maybe fifty times a day at Google, and I cry every time because it is so. glacially. slow. hg diff too. And I'm working with a relatively small repository.
Speed matters for tools we use all the time.
I'd also posit that the process of writing "plugins" for git is much easier than writing hg plugins. A git "plugin" is just a shell script that uses git. If you can use git, you can write a shell script that uses it. An hg plugin...whoaboy.
Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.
I'll see what I can do. Because it's Google code, it may not be feasible. But we have a whole team of hg developers ourselves, maybe I should bug them before putting it on you. :)
Please correct me if I'm wrong, but I think it was in "The Hundred-Year Language" [^1] where @pg argued for performance as a language design feature. He could have meant a different kind of performance though.
- [^1]: http://www.paulgraham.com/hundred.html
- [^1]: http://www.paulgraham.com/hundred.html
Have you aliased `hg` to `chg` (built-in I believe). That solved things for me.
I hadn't heard of this! It definitely helps with startup time.
$ time hg help > /dev/null
real 0m0.232s
user 0m0.196s
sys 0m0.033s
$ time chg help > /dev/null
real 0m0.081s
user 0m0.003s
sys 0m0.000s
$ time hg diff
real 0m1.383s
user 0m0.558s
sys 0m0.333s
$ time chg diff
real 0m1.224s
user 0m0.003s
sys 0m0.007sPart of git's success might be due to its initial association with Linus.
Which I would find mildly ironic, because Linus initially was one of the last prominent holdouts against version control systems, and then made (in my opinion) a very ill-conceived decision to go with a commercial version control system that effectively made it harder for non-prominent, non-paying developers to contribute.
So when he decided to build his own version control system, I'd say it was not a foregone conclusion that he was a particularly qualified expert in the field. But in retrospect, the technical architecture underlying git has held up well (the UI maybe not so much).
Which I would find mildly ironic, because Linus initially was one of the last prominent holdouts against version control systems, and then made (in my opinion) a very ill-conceived decision to go with a commercial version control system that effectively made it harder for non-prominent, non-paying developers to contribute.
So when he decided to build his own version control system, I'd say it was not a foregone conclusion that he was a particularly qualified expert in the field. But in retrospect, the technical architecture underlying git has held up well (the UI maybe not so much).
I'm reminded of that article I read on HN a few months ago about how "you're not Google/Amazon/Facebook" and you probably shouldn't base your technical choices on what these companies are doing because chances are that you have a massively different usage profile and very different priorities. Still, everybody wants to be like the big guys (dress for the job you want, not the one you have) so you still often seen small-ish websites using a ridiculously overpowered and over-architectured backend.
I think there's a bit of that in Git vs. Mercurial. Git was built specifically for the Linux kernel and it shows. Most of its quicks and features make sense in that context. But the thing is, the overwhelming majority of projects out there are not anywhere similar to the kernel. They have fewer contributors, there are generally much more centralized, they don't use 90's style mailing lists, they don't deal with dozens of millions of lines of code etc...
I think for that "silent majority" of projects Mercurial was a much better choice indeed. It's simpler, for a long time it was much better documented, it was also easier to migrate from SVN and other centralized version control systems. But Git was cooler, it's what the kernel used, and if it's good enough for the kernel then it's good enough for me!
That being said at this point it's clear that Git has won. I've been slowly migrating my (active) projects to Git over the past couple of years. I'll have to use Git one way or the other anyway, I might as well try to uniformize my workflow. RIP Mercurial, you deserved better.
I think there's a bit of that in Git vs. Mercurial. Git was built specifically for the Linux kernel and it shows. Most of its quicks and features make sense in that context. But the thing is, the overwhelming majority of projects out there are not anywhere similar to the kernel. They have fewer contributors, there are generally much more centralized, they don't use 90's style mailing lists, they don't deal with dozens of millions of lines of code etc...
I think for that "silent majority" of projects Mercurial was a much better choice indeed. It's simpler, for a long time it was much better documented, it was also easier to migrate from SVN and other centralized version control systems. But Git was cooler, it's what the kernel used, and if it's good enough for the kernel then it's good enough for me!
That being said at this point it's clear that Git has won. I've been slowly migrating my (active) projects to Git over the past couple of years. I'll have to use Git one way or the other anyway, I might as well try to uniformize my workflow. RIP Mercurial, you deserved better.
There are similar patterns in other industries. Manufacturing tends to fetishise the automotive industry -- so an absolute mountain of changes come from "well Toyota's doing it" or "well BMW is doing it". Of course, they're great solutions for building cars, but not so great when you're building TV remote controls.
I wouldn't say Git has "won" or Mercurial has "lost". Hg still sees a lot of active development from the maintainers. As do Subversion, Perforce, and so on. Heck, ClearCase is as old as the hills and even that still has an active user community.
I wouldn't say Git has "won" or Mercurial has "lost". Hg still sees a lot of active development from the maintainers. As do Subversion, Perforce, and so on. Heck, ClearCase is as old as the hills and even that still has an active user community.
Use everyone's favorite Sourcehut, which works with (not against) the mail-centric workflow of Git. (Or use Mercurial on Sourcehut.)
On the other hand, the software development version of the maxim "dress for the job you want, not the job you have" could easily be "use the tools the job you want uses, not just what you can get away with".
> It is superior to Git in every way except performance and adoption.
For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.
For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.
I'm not so sure really, in my experience the performance difference only becomes noticeable if you have a very large repository. For the Linux kernel I'm sure it matters, for "my library with 100 commits and 10k lines of code" it won't make a significant difference.
Most commercial projects are orders of magnitude more complex than that, and the performance differences are stark.
I have worked on many projects where I have wished that git was faster. It doesn't take a very big repository for performance to become an issue.
People are going to go for something that runs in 0.1 seconds as opposed to 1 second, most things being the same.
Performance is not the reason GitHub chose git over mercurial. They chose git because their core developers understand internal architecture of git better. They were more proficient in Ruby and C than Python, so git was a natural choice for GitHub.
Python language used mercurial for quite sometime to manage all it's repository, they moved to GitHub not for performance but for inertia of mass adoption, knowing very well that git has inferior user interface and they need to rely on GitHub to make it work for them. Facebook, Unity engine still use mercurial.
Python language used mercurial for quite sometime to manage all it's repository, they moved to GitHub not for performance but for inertia of mass adoption, knowing very well that git has inferior user interface and they need to rely on GitHub to make it work for them. Facebook, Unity engine still use mercurial.
I have no idea how good mercurial is now, but I think back in the days when git started to get ahead it was superior to mercurial in more than one way.
> except performance
That's a big except. Mercurial was far too slow. Not sure if that's still the case; I haven't used it in years. But it was slow when the field was still open to competition.
That's a big except. Mercurial was far too slow. Not sure if that's still the case; I haven't used it in years. But it was slow when the field was still open to competition.
In my understanding it's the opposite, that Mercurial is effectively a subset of Git. But I was never a Hg user.
Well, you can express any Git repository in Mercurial terms, but not otherwise.
Over the year I've used CVS, SVN, bazaar, Mercurial and Git.
Mercurial has always been the one I struggled the most with. It never clicked with me. Just to respond to some arguments I see floating around.
In my last team we switched from Hg to Git and absolutely everyone but the CTO felt more comfortable with it. including the data scientists.
To me, Mercurial UI might be friendlier than Git's but it's really a moot point if it does not fit with the way people actually think/work.
Also, I sincerely think Git was getting more popular _before_ Github. Granted, it massified the adoption.
In my last team we switched from Hg to Git and absolutely everyone but the CTO felt more comfortable with it. including the data scientists.
To me, Mercurial UI might be friendlier than Git's but it's really a moot point if it does not fit with the way people actually think/work.
Also, I sincerely think Git was getting more popular _before_ Github. Granted, it massified the adoption.
I and the dozens of other remaining Mercurial users will be severely inconvenienced by this.
Still, at least SourceForge still has Mercurial support!
Still, at least SourceForge still has Mercurial support!
Savannah allows using mercurial[0] and is likely less evil than sourceforge.
[0] https://savannah.gnu.org/maintenance/WhyChooseSavannah/
[0] https://savannah.gnu.org/maintenance/WhyChooseSavannah/
> Savannah has high project approval requirements and thus visitors can expect freedom-related qualities from projects hosted here
Is that code for "must be under GPL"? I'm a BSD man myself.
Is that code for "must be under GPL"? I'm a BSD man myself.
https://savannah.gnu.org/register/requirements.php
It does not explicitly give out a list on that page (to get that you need an account), but from a read it seems to say GPL-compatible which BSD is.
The repository has a very explicit goal: The expressed purpose of advancing free software that can run in free operating systems. Licenses aside, the answer to the question if a project is suited for Savannah is likely answered by looking at that goal.
It does not explicitly give out a list on that page (to get that you need an account), but from a read it seems to say GPL-compatible which BSD is.
The repository has a very explicit goal: The expressed purpose of advancing free software that can run in free operating systems. Licenses aside, the answer to the question if a project is suited for Savannah is likely answered by looking at that goal.
I honestly do not know. I believe I had a MIT licensed project there many years ago, but I would not surprised if it's GPL only.
I wouldn't trust SourceForge at all after all the horrible stuff they've done. I know they have allegedly improved after new owners and a come-to-jesus moment, but damn, that was some shady shit.
I think you are thinking about the old and nasty sourceforge. They have since been bought and the new owners have changed what nasty old sourceforge used to be
> I know they have allegedly improved after new owners and a come-to-jesus moment, but damn, that was some shady shit.
If Facebook tomorrow started saying they're totally going to stop being creepy and got a new CEO, I wouldn't suddenly start trusting them either.
If Facebook tomorrow started saying they're totally going to stop being creepy and got a new CEO, I wouldn't suddenly start trusting them either.
We're a small independently owned private company, and not a single person responsible for those decisions made years ago is still involved with the company. It's been over 3 years since we bought SourceForge and we reversed all the bad decisions on day 1 and never looked back. We still support Mercurial https://sourceforge.net/p/forge/documentation/Mercurial/#pub...
But why buy such a tarnished trademark which has garnered so much ill will over the years for horrible practices? Is it a form of "all PR is good PR", that it's better to have a recognized but hated name than to have a name nobody knows of?
Most people have gotten the message that things have changed at SourceForge. We bought it to redeem the name and protect free open source software.
I still avoid SourceForge links because of that annoying 'Your download will start shortly...' interstitial.
I suspect the whole post was a bit tongue-in-cheek, not just the line about "There's dozens of us. Dozens!"
sr.ht also recently added support for hg
at RhodeCode we used to have a hosted Mercurial repositories service. Actually, it was a per-customer isolated instance that we hosted on digital ocean. We have all the logic and code still here, i wonder if we should bring that back to have people host their Mercurial repositories.
Doesn't this mean BitBucket will die? Slowly, sure, but Mercurial support seemed like a key differentiator relative to GitHub.
Mercurial support was the one reason for me to still use Bitbucket: there is no other Bitbucket feature I can think of that Github doesn't already have, while Github's community is miles ahead since everyone and their dog is already there.
More importantly, Bitbucket leaves the migration to you (if I read the article correctly). Once I download my repo and convert it to git, why would I stay with the company that just made me go through an annoying (and often painful) process, when I can migrate to Github with the exact same command? And why isn't there a "migrate this repo to git" button right there?
I want to believe that Bitbucket has smart people and that this choice is a good one. But I'm with you there - to me, this definitely looks like Bitbucket will die.
More importantly, Bitbucket leaves the migration to you (if I read the article correctly). Once I download my repo and convert it to git, why would I stay with the company that just made me go through an annoying (and often painful) process, when I can migrate to Github with the exact same command? And why isn't there a "migrate this repo to git" button right there?
I want to believe that Bitbucket has smart people and that this choice is a good one. But I'm with you there - to me, this definitely looks like Bitbucket will die.
They wouldn't have done it if a they had a significant user base using Mercurial, or if Mercurial usage was showing promising growth.
The article claims that virtually no new accounts are using Mercurial support at all.
I suspect that they are working on improving their build pipeline and CI tooling and it's proving to expensive (perhaps in both time and money) to get that working reliably for both Git and Mercurial.
I suspect that they are working on improving their build pipeline and CI tooling and it's proving to expensive (perhaps in both time and money) to get that working reliably for both Git and Mercurial.
The key differentiator on Github's side is community involvement. The UI allows you to quickly search for projects across repositories.
Bitbucket seems more geared to teams working internally; finding projects on Bitbucket is hard.
To be brutally honest, I used Bitbucket because I had a grandfathered academic account (most features free). Github offers nearly all that I had on that account now.
Github is great for "social" coding, but Bitbucket is very clearly moving towards targeting insular, corporate development tasks. But then, with the price ticket on Atlassian's products, that's hardly a surprise. B2B is their bread and butter.
Bitbucket seems more geared to teams working internally; finding projects on Bitbucket is hard.
To be brutally honest, I used Bitbucket because I had a grandfathered academic account (most features free). Github offers nearly all that I had on that account now.
Github is great for "social" coding, but Bitbucket is very clearly moving towards targeting insular, corporate development tasks. But then, with the price ticket on Atlassian's products, that's hardly a surprise. B2B is their bread and butter.
yeah, I think that open source and other social products will gear towards Github. While Bitbucket will thrive in B2B space. currently, JIRA has a huge moat around it and I am not seeing that disappearing in the near future.
There's already a self-hosted version of Bitbucket which is fairly decent aside from being as slow as molasses (which, let's face it, is an 'Atlassian thing' at this point).
I used to use Jira extensively for my own internal projects (and, hilariously, my personal TODO list), but I'm moving away from that. I'm moving from my own personal server to a couple of Droplets, and I realised in moving JIRA across just how bloated it is. Most of the SCM integration tools I use are pay-for now, so for $10/yr, I'm getting less than I'd get with a Mantis or Bugzilla install.
I need to have a look for a new bugtracker. Custom Workflow support would be nice, that's really the only feature which kept me on JIRA for so long!
I used to use Jira extensively for my own internal projects (and, hilariously, my personal TODO list), but I'm moving away from that. I'm moving from my own personal server to a couple of Droplets, and I realised in moving JIRA across just how bloated it is. Most of the SCM integration tools I use are pay-for now, so for $10/yr, I'm getting less than I'd get with a Mantis or Bugzilla install.
I need to have a look for a new bugtracker. Custom Workflow support would be nice, that's really the only feature which kept me on JIRA for so long!
If it's going to die (and it might, I know I couldn't get off it fast enough), this can likely only help, not hinder.
Not every feature helps you. There's a support burden with every line of code, and the support burden for another entire version control system is probably pretty high. Every new feature you add has to either be written for that second version control system as well, or come with a disappointing article explaining why not.
If anything, this has the potential to free up resources they can spend on creating a differentiator that engages more than 1% of their customers.
Not every feature helps you. There's a support burden with every line of code, and the support burden for another entire version control system is probably pretty high. Every new feature you add has to either be written for that second version control system as well, or come with a disappointing article explaining why not.
If anything, this has the potential to free up resources they can spend on creating a differentiator that engages more than 1% of their customers.
It is quite funny because BitBucket started as a GitHub for Mercurial users (it had only Hg support).
Then they (after it was sold) added git support and now they are removing hg.
Then they (after it was sold) added git support and now they are removing hg.
Unlikely. The deep integration between JIRA, BitBucket, and Bamboo is a huge selling point.
As a data point, our company that only uses git moved from GitLab to BitBucket literally about two months ago. No idea why (waaaay to low on the food chain) but I'm guessing it must have some advantages at least.
Most likely you will also see a Jira roll-out soon (unless that preceded the move to BitBucket)
We have moved from BitBucket after they had several days worth of unavailability over a year and the fact that they would regularly decline our company credit card, which would subsequently immediately block all commits to our repos.
It was a mess which was simply fixable by re-submitting the card details again.
They only had one job.
It was a mess which was simply fixable by re-submitting the card details again.
They only had one job.
[deleted]
We use Bitbucket at work because they offer selfhosting. Until Github can offer this I don't think Atlassian has anything to worry about.
GitLab employee, just wanna pop in here to say we have free self-hosting too in case anyone stumbles across this comment: https://about.gitlab.com/pricing/index.html#self-managed
https://github.com/enterprise
GitHub has offered an onprem server for some time now.
GitHub has offered an onprem server for some time now.
Would you look at that! This was not an option about a year or two ago when we signed our contract for bitbucket...
It's been around since 2011: https://github.blog/2011-11-01-introducing-github-enterprise...
Fairly sure GitHub Enterprise has been a thing for several years now?
It was preceded by GitHub:FI, but Enterprise has existed since I worked there in 2013. Definitely not a new capability for them and it’s actually really nice to administer, e.g. very easy high-availability setup and excellent documentation.
https://help.github.com/en/enterprise/2.16/admin/installatio...
https://help.github.com/en/enterprise/2.16/admin/installatio...
This is terrible news.
I prefer Mercurial to Git. I intensively used both for years and I can't say that Git is any better than Mercurial.
I do think they should at least come up with a plan to seamlessly migrate existing repositories to Git. Still, shocking.
I prefer Mercurial to Git. I intensively used both for years and I can't say that Git is any better than Mercurial.
I do think they should at least come up with a plan to seamlessly migrate existing repositories to Git. Still, shocking.
What a damn shame. I use git when I have to, hg when I get to choose. The usability and ergonomics are just so much better. I've never had any performance complaints. I chose Bitbucket over Github specifically because of Mercurial support. Unfortunately it's a business decision and they had to make a tough call.
I remember playing pool with Chris Wanstrath back in the day and he was telling me how he just started a product based on Git. I told him to bail on it and use Mercurial instead! I listed a bunch of reasons why I thought it was the best distributed VCS. I remember shaking my head a bit thinking: "Whelp... good luck with that". I probably lost that game of pool too.
OMG, sad. And I'm part of the problem:
I've always wanted to use Mercurial; I'd always found its user interface to be an improvement over git; as if it shipped with a great "porcelain" by default. I respect its ability to leak fewer implementation details while still offering plenty of power.
But I kept using git for all my projects, and GitHub with it.
I've always wanted to use Mercurial; I'd always found its user interface to be an improvement over git; as if it shipped with a great "porcelain" by default. I respect its ability to leak fewer implementation details while still offering plenty of power.
But I kept using git for all my projects, and GitHub with it.
I feel old. I can literally remember dozens of silver bullet technologies I was told were necessary to know ("you're not a real professional if you don't..."), and then forgotten by nearly everyone. All of these were supposed to save the world and most of these were cutting edge less than ten years ago.
I'm astonished, just because hg defined bitbucket for me. Else its other features were just OK.
Also, though I never found a reason to choose hg I had been told that it fit the Windows file system better than git. If so that wasn't enough.
Also, though I never found a reason to choose hg I had been told that it fit the Windows file system better than git. If so that wasn't enough.
Since this is likely to attract bitbucket users, I’ll toss out a question in hope someone knows:
It appears that in bitbucket enterprise cloud, there is no way for me as an administrator to prevent members of my team from making repositories public to the Internet. Is that true? If so I may need to look to on prem options, or perhaps GitHub enterprise cloud which seems to support better permissions. We deal in sensitive data so can’t risk an analyst publishing them to the net accidentally.
It appears that in bitbucket enterprise cloud, there is no way for me as an administrator to prevent members of my team from making repositories public to the Internet. Is that true? If so I may need to look to on prem options, or perhaps GitHub enterprise cloud which seems to support better permissions. We deal in sensitive data so can’t risk an analyst publishing them to the net accidentally.
Strange. I would have thought that serving more niche customers would be a more sustainable business model than competing against GitHub and GitLab on their home turf.
Is Bitbucket profitable?
Is Bitbucket profitable?
It’s owned by Atlassian but who knows if revenue generated exceeds costs incurred for that specific product. Somehow doubt they’re going to disclose that.
Would be nice if companies were transparent about which products and services made the most money, rather than (best case, public companies) stating earnings for the whole company and breaking it out fairly opaquely through categorizations.
On the flipside I could see this being useful information to competitors, and instructive on which parts of your business to attack.
Would be nice if companies were transparent about which products and services made the most money, rather than (best case, public companies) stating earnings for the whole company and breaking it out fairly opaquely through categorizations.
On the flipside I could see this being useful information to competitors, and instructive on which parts of your business to attack.
The Software Heritage [1] was mentioned in another thread today. They seem to archive source code from most of the popular locations, but Bitbucket doesn't seem to be on the list?
If Bitbucket is planning on actually removing Mercurial repos it seems like a good idea to crawl and archive those before that happens.
[1] https://www.softwareheritage.org/archive/
If Bitbucket is planning on actually removing Mercurial repos it seems like a good idea to crawl and archive those before that happens.
[1] https://www.softwareheritage.org/archive/
I have 92 mercurial repositories at my company that I'll need to convert.
All my software is in Bitbucket for two reasons: Free private repos and Mercurial. Now that Github has free private repos and Atlassian is removing support for Mercurial, I have no remaining reason to keep my repos in Bitbucket. Sayonara, Bitbucket. You just created a Github customer.
When I picked up a DVCS years ago I initially went for Mercurial for its ease of use. It had a clean command line interface and it just clicked with me (Git still had some bits written in Perl).
It worked very well for my small projects.
Its hgweb worked without fuss on top of Apache (which was still popular). Bitbucket was a small time site back then (about 2008) and I mainly hosted the projects locally on a web server.
However the industry has voted by putting its weight behind Git and Git has won. It has caught up usability-wise. Its performance is miles ahead of Mercurial. While its underlying model is not straightforward to grok it enables great work flows.
Honestly I'm happy with Git and never looked back.
However the industry has voted by putting its weight behind Git and Git has won. It has caught up usability-wise. Its performance is miles ahead of Mercurial. While its underlying model is not straightforward to grok it enables great work flows.
Honestly I'm happy with Git and never looked back.
Only reason I use Bitbucket is because of Mercurial. I guess that's what you get for using centralized services. The funny thing is that both Git and Mercurial was designed to be decentralized! But we humans are social creatures, and Github is like Facebook for invert's - instead of posting pictures of your acquaintance you post your software projects. Stars are the likes ... So in order to fully decentralize, the human/social bit also need to be decentralized. But there is also the convenience, while setting up Git and Mercurial hosted repositories is straightforward, I can understand why dev's choose to use a service instead, especially when it's free.
When clicking on the link to "A Community thread to discuss conversion tools, migration, tips, and offer troubleshooting help", I see:
Article not found
The article you are trying to access is not available.
It may have been deleted or marked as spam.
Article not found
The article you are trying to access is not available.
It may have been deleted or marked as spam.
I am annoyed at this news.
v1. Bitbucket == Mercurial
v2. Bitbucket == Mercurial|git
v3. Bitbucket == git
However, GitHub is better at git, so now
GitHub > Bitbucket
May bitbucket and it's management forever have it sheets and stocks shorted. They deserve it.
Since I want my repos' outsourced and I'm being forced to use git, I am moving to GitHub.
Define: git - https://www.google.com/search?q=what+is+a+git
May bitbucket and it's management forever have it sheets and stocks shorted. They deserve it.
Since I want my repos' outsourced and I'm being forced to use git, I am moving to GitHub.
Define: git - https://www.google.com/search?q=what+is+a+git
Guess I'm taking my money and going elsewhere, then.
Several things seem really odd to me:
Several things seem really odd to me:
- They are ditching one thing that was a safe harbor from github.
- No migration path to Git inside bb service.
If I am going to migrate outside bb I might as well move away completely.
- Armageddon-style wholesale destruction of the old repos.
Could have left the read-only repos on a separate server. Or even just a tarball.
Damn, this is disappointing. I've long preferred hg over git but developer preference has clearly moved to favor git. I like using mercurial queues for managing local config changes but I guess I'll have to get better using `git stash`. I hope bitbucket provides some tools to easily convert repos from hg to git. Frankly, though, I'll likely just move from bitbucket now.
For anyone looking to jump ship, check out invertbucket (https://hg.sr.ht/~sircmpwn/invertbucket), a script which automates the transfer of mercurial repos from Bitbucket to Sourcehut. Support for transferring tickets and pull requests should be coming soon as well.
A friend of mine is a core contributor to Mercurial. He is... well, I suppose "livid" is as close a descriptor as any.
Enjoy your monoculture.
SourceForge still supports Mercurial https://sourceforge.net/p/forge/documentation/Mercurial/#pub...
Is there any feature in mercurial that git doesn't have? Is there some plugin to allow mercurial users keep using the client with a git remote repository (like the one for using git with svn)?
1) hg absorb
2) hg-git exists, and there's other things afoot that should be better
2) hg-git exists, and there's other things afoot that should be better
Just looked at hg absorb. It seems like a very useful feature but I understand it is an extension by Facebook. Can't someone make a similar extension for git?
...and I just found it: https://github.com/tummychow/git-absorb
...and I just found it: https://github.com/tummychow/git-absorb
As a daily hg-git user, could you elaborate on (2)?
Hopefully this: https://www.mercurial-scm.org/pipermail/mercurial-devel/2019...
That would be helpful
I use hg-git to put all my Mercurial based projects on Github.
But the last OpenSUSE update installed Mercurial 5, but left the old hg-git for Mercurial 4. Now it does not work anymore.
I use hg-git to put all my Mercurial based projects on Github.
But the last OpenSUSE update installed Mercurial 5, but left the old hg-git for Mercurial 4. Now it does not work anymore.
Changeset evolution for starters.
You mean the thing that was only suitable for real world use by in-the-wild development teams last year? Something no repo provider really fully supports even to this day?
From HG's own documentation (https://www.mercurial-scm.org/wiki/ChangesetEvolution):
>While well on the way, the full implementation of the changeset evolution concept is still in progress.
HG's entire system requires far more investment in the tool than git will ever ask of you. And you probably don't need the feature in the first place. I consider changeset evolution a nifty feature, but it's also a devop smell in my book.
From HG's own documentation (https://www.mercurial-scm.org/wiki/ChangesetEvolution):
>While well on the way, the full implementation of the changeset evolution concept is still in progress.
HG's entire system requires far more investment in the tool than git will ever ask of you. And you probably don't need the feature in the first place. I consider changeset evolution a nifty feature, but it's also a devop smell in my book.
Changeset evolution has had the "beta" label for way too long. I started using it years ago and it was fine.
As far as smells go, its whole purpose is to make editing history less "smelly" than git's rebase -i followed by force push.
As far as smells go, its whole purpose is to make editing history less "smelly" than git's rebase -i followed by force push.
> I started using it years ago and it was fine.
You are not a full blown development team, and beta software works for many people. That doesn't mean it's ready for prime time.
You are not a full blown development team, and beta software works for many people. That doesn't mean it's ready for prime time.
No. Evolution was usable since 2015 at least. Supported by Bitbucket and others.
Evolution requires no effort whatsoever to maintain.
Evolution requires no effort whatsoever to maintain.
[deleted]
Revsets: a single, uniform syntax for querying and selecting commits. Used throughout Mercurial and accepted almost everywhere that a subcommand takes one or more commits as a parameter.
https://www.mercurial-scm.org/repo/hg/help/revsets
https://www.mercurial-scm.org/repo/hg/help/revsets
A disaster for me, I've got dozens of hg repos over there. Do they support an automated conversion? If not, probably no reason to use bitbucket any longer.
I'm in the same boat. And Mercurial support was the key differentiator for me, I'll probably convert the repos to git (hg is almost sure to die after this) and move to GitHub in the process, including the git repos I have on Bitbucket.
[deleted]
It seems that Bitbucket and GitHub are trying to emulate GitLab’s strategy of being a one-stop tool rather than just version control.
The opposite is true actually, Bitbucket was bought by Atlassian in 2010 to make Atlassian the one-stop shop, a strategy GitHub and GitLab are emulating (GitLab launched in 2011).
Seems to me that one-stop shop is very different from one-stop tool. GitLab is aiming for the latter, whereas Atlassian (at least when I was using those tools) seems much less integrated.
Jira may be the most comprehensive issue tracker (which isn't necessarily attractive -- but then they have Trello now, too), but on the version control and CI front I don't think Atlassian will have an easy time competing against Azure/GitHub/GitLab.
Jira may be the most comprehensive issue tracker (which isn't necessarily attractive -- but then they have Trello now, too), but on the version control and CI front I don't think Atlassian will have an easy time competing against Azure/GitHub/GitLab.
I think the ALM market was defined and alive before any of these companies even existed. It is natural evolvement of these companies.
The common user just realized he or she needed more and demanded them for free.
The Enterprise market had DevOps features long before DevOps as term existed.
The common user just realized he or she needed more and demanded them for free.
The Enterprise market had DevOps features long before DevOps as term existed.
Anyone knows what happened to Spolky's hginit.com ? It used to be one of the most accessible Hg tutorials out there.
I also miss hginit.com. I've been referring new devs to https://web.archive.org/web/20180924182907/http://hginit.com...
I guess hginit.com disappearing was a signal of things to come.
I guess hginit.com disappearing was a signal of things to come.
I don't know what happened to it, but I was just searching for it as well... I found it on the Wayback Machine. Is good.
https://web.archive.org/web/20170320142857/http://hginit.com...
https://web.archive.org/web/20170320142857/http://hginit.com...
Another casualty of the expanding Github empire.
Mercurial is officially dead.
This is disappointing. Bitbucket is the premier place to host free private mercurial repos. Just look at the hosting page on the mercurial website. There is literally not a single other place for free private hosting. There may be some smaller ones out there I'm not aware of.
Hacker news, question: Have you ever tried mercurial? Don't you like to save keystrokes? Isn't `hg com` easier than `git commit`? Isn't `hg pul` easier than `git pull`?
Is there any way to shorten the amount of keystrokes to use git?
Hacker news, question: Have you ever tried mercurial? Don't you like to save keystrokes? Isn't `hg com` easier than `git commit`? Isn't `hg pul` easier than `git pull`?
Is there any way to shorten the amount of keystrokes to use git?
> Is there any way to shorten the amount of keystrokes to use git?
Sure, you can just set up aliases in your shell and in git. Set an alias in your shell for git → g and in git for commit → c and you can commit with `g c`.
Sure, you can just set up aliases in your shell and in git. Set an alias in your shell for git → g and in git for commit → c and you can commit with `g c`.
There's a really good starter set in the Git manual:
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
I'm so used to "git co" and "git br" at this point (which are effectively analogues of the same commands on Hg) that I have to think for a minute when I SSH into a machine which doesn't have these set up.
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
I'm so used to "git co" and "git br" at this point (which are effectively analogues of the same commands on Hg) that I have to think for a minute when I SSH into a machine which doesn't have these set up.
Awesome, wasn't aware of git aliases. Thank you.
Just be careful that if you define an alias that shadows a built-in command, your alias will be (silently?) ignored. Mostly a problem if a future version of git adds a command and clobbers an alias that used to work.
> Is there any way to shorten the amount of keystrokes to use git?
Others have mentioned git aliases. But also, git recognizes some shortforms too. E.g. git rebase --con works the same as --continue. Doesn't work in hg.
Others have mentioned git aliases. But also, git recognizes some shortforms too. E.g. git rebase --con works the same as --continue. Doesn't work in hg.
So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. GitHub successfully marketed git, so git and GitHub are synonymous for most developers. Now majority of open source projects are reliant on a single proprietary solution Github by Microsoft, for managing code and project. Can understand the difficulty of bitbucket, when Python language itself moved out of mercurial due to the same inertia.
Hopefully gitlab can come out with mercurial support to migrate projects using it from bitbucket.
For people who believe in self hosted solution can install Kallithea (https://kallithea-scm.org) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.