Given the bad news from Bitbucket, the WinDirStat project will move to a self-hosted solution until the end of 2019. At least that’s the plan.
We thank Bitbucket for their services.
Once the self-hosting will be available, I will let everyone know on r/WinDirStat, Twitter, and here. Furthermore I will make sure that there will be independently hosted alternatives 1.
With best regards,
Oliver
PS: a transition to Git will definitely not happen. This does, however, not preclude any means of interoperability.
- OSDN comes to mind, but also SourceForge [↩]
Out of curiosity, why do you prefer Mercurial over Git? I am not judging nor wanting to debate your choice, I am only curious to know the reason for your preference.
Can I ask why you would not consider putting it in git, do you have an aversion to git, Microsoft or something else?
Also, thank you for continued use of a fantastic program over my many years in IT, it certainly has helped myself, co-workers, clients, my parents and many a forensic hunt!
I hope you continue to release opensource software, hopefully with a big smile on your face knowing you’ve helped countless people!
-S
wait, why don’t you want Git conversion?
Hi Oliver, first of all, many thanks for WinDirStat, I have used it a lot over the years.
I wanted to ask you: is the information on https://en.wikipedia.org/wiki/WinDirStat current? I was curious of having a look at the latest development activity, but the Wikipedia page is not clear.
I hope the move to a new mercurial hosting goes smoothly.
@muxator: the repository has the progress since the 2007 release, but nothing stable has transpired. I have just resumed working on WDS and the stuff surrounding the TODO list after several months of “hiatus” (new work place, daughter in kindergarten age etc) and hope to publish another pre-release version before the end of this year (one code-signed version can be downloaded in the download area on Bitbucket, including 64-bit binary).
@all: In general the aversion to Git is based on having used it for a very long time. I started using Git not long after I started with Hg (around 2008). In fact on a regular basis — at work — folks will approach me for advice regarding whatever kerfuffle Git has gotten them into again (because as much as those GUI tools attempt to hide, sooner or later you end up with gitglossary). SCM/VCS is supposed to help me do my job and save me time as a developer. Git — on a regular basis — does the exact opposite. Git will happily scream “here here”, asking my attention for stuff that I expect a supporting technology to solve for me.
While — with a very limited workflow — Git can be okay to work with, I never quite fancied that on Windows it would open a browser when I simply ask for
--help. I also don’t quite like how questionable design decisions have led to wacky behavior (ever tried working on a repository with ref whose names differ only in case on Windows? … oh, but that only happens once the refs get unpacked … don’t even get me started on the innards of.git, because as a user you’re pretty much expected in several scenarios to know your way around there; or differently phrased: the internals of Git are part of its public interface …).It’s true that CVS can’t be fixed, as Linus Torvalds so candidly stated in one of his first talks about Git, making fun of Subversion trying to do that so hard. Subversion made its own questionable decisions (you only learn to appreciate tags and branches as “paths” following a “convention” once a coworker “blesses” the repository with branching from the repository root), I guess many SCM systems did (including Hg). But given Hg (2005-04-19) and Git (2005-04-07) came along within weeks of each other — if you merely look at the initial release date — and for the same reason (Linux kernel, getting away from BitKeeper) one has to wonder why Hg always had an overbearing design and never considered non-unixoid systems second-class “citizens”. With Git, on the other hand, commands kept sprouting (128 aliasing
git, 190 overall in/usr/lib/git-coreon Ubuntu 20.04 with Git 2.25.1) and command line switches blossomed and.gitinternals (not just plumbing commands!) became part of its public interface … which makes me wonder if fundamental issues (many of which its developers will not even acknowledge as problematic!) with Git can ever get fixed.GitHub, in my opinion, is the single biggest reason for Git’s “success” and I wonder almost on a weekly basis — basically whenever Git sticks me the finger again — why we developers put up with mediocre tools. And whenever people tell me they work with Git it oftentimes turns out what they mean to say is that they use GitHub and are excited by its client or they are excited by SourceTree or some other fancy GUI tool or the by the libgit2 integration of their favorite editor/IDE. Or to sum it up: many people go on about Git’s potential benefits while reluctant to explore/apply even a sizable fraction of those perceived benefits and sticking to very very limited (and limiting) workflows and still struggle on occasion as you can find out yourself with a cursory web search …
One may attribute the fact that there are dozens of books about Git in English alone versus one (that I know of) about Hg as indicator of Git’s success … I have a slightly different interpretation of that fact, though.
A small selection of my reasons for disliking Git (I am still collecting for an article albeit not for this blog):
Ian: “the same could be said about Git (apart from windows support)” — Ehh-heh, you’ve apparently missed the “It’s easy to use” part. ;-p Git is the gold standard example of a tool with a user interface designed for its own developers as the target audience. It’s like driving your car via CAN-bus adaptors and prototype test equipment loaned from the R&D lab. Extremely powerful, but requires you being in the car industry. ? Sz. Jan 24 ’16 at 23:20
Comments on StackOverflow are volatile, but I got screenshots showing question and comments.
discussionsflame wars about why Git is superior to any other SCM), but so what. Hg isn’t as powerful as Git out of the box (i.e. in its default configuration) because it doesn’t enable every shipped feature, such as those of the caliber allowing you to wipe out revision history. There are extensions for such features, which can be enabled on-demand. In Hg, if I really wanted to I could mimic it some way (MQ comes to mind), but in fact I’d like to keep a true history of the revisions, including small intermediate commits. If I wanted to, I could still squash the changes before pushing (i.e. before moving from draft to public stage).branchmy intention is that the next commit goes there … with Git you can do that (i.e. switch to the branch upon creation) withgit checkout… wait, what? … and yeahgit switchcame along meanwhile to join the other two commands operating on branches … ughgit --everything-is-localis one of the PR claims on their website. Depends on how you look at it, I guess. Whenever I clone, I have to go through hoops to get everything from the remote end set up as a local verbatim copy. Sure, I can start out withgit clone --mirrorand “unbare” it, but setting up all the tracking branches from that to establish a real mirror is insanely hard (and involves shell script which makes those solutions less portable as well) … it’s the reason why Hg branches don’t map to Git branches in solutions trying to achieve interoperability. Git branches are mapped to Hg bookmarks in those cases (and bookmarks are local by default). So in the sense that “everything is local” until you decide to share it, that’s true. But it means that a clone does not in fact carry all revision history (which some people may like, but I decidedly don’t).git clonevia SSH isn’t two-way (I can clone from but not to a remote via SSH). The advice then is usually to pull from the remote one. Alas, that can occasionally be quite difficult. That is because, just being able to connect to a host via SSH, doesn’t — conversely — imply that this host can connect back to where I am connecting from. “Solutions” to this are regularly unnecessarily fiddly (and yeah, I am quite apt with SSH port forwarding and stuff) …man gitglossaryagain).fetchvs.pull… just in the other direction) …All that said I am not planning on creating extra obstacles for contributors using Git. And I have researched several options that may provide a smoother experience for Git users. However, I am definitely not planning on transitioning to Git, but Heptapod, Kallithea, Phabricator and RhodeCode are being investigated as options.
As long as I am not paid to put up with Git (as I am at work), I’m not going to spoil my spare time with it
…
@Oliver thank you for taking the time to describe at length why you are staying with Hg. A few months ago I made the decision to migrate from Hg to Git because that’s what work considers the blessed tool; and because GitHub. I’m somewhat saddened by the move but it remains the right thing for here, for now. (I’ve copied your words to my notebook for my future reconsideration though. 😉
Thank you, @Oliver, for your very nice breakdown of the shortcomings of Git vs Mercurial. I never suspected.
I have liked using Git, after before only ever using CVS and Subversion, but that’s mostly because it makes version control so much easier than those older systems, and because version control vs. no version control is such a leap ahead.
I had never tried Mercurial and thought of it mostly as some less-popular Git equivalent — I never suspected that it potentially was so much better than Git.
I have run into many of the issues you mentioned with Git over my 4+ years of regular use — the possibility that Hg could be so much better in these aspects makes me want to try it on my next project, and also sad that Bitbucket is ending its support, and that so few people are probably aware of these things.
Thank you.
Aaron, there’s absolutely nothing wrong with liking Git in my opinion. I don’t, but that’s just my opinion.
Hey Matt, yep I know the argument. It’s a bit like with Scrum I think. People say they “do Scrum” and they say they “use Git”, but when you try to dig deeper you find out that they really only use a fraction of the features Git offers or with Scrum that their workflow is “inspired by Scrum” but they do it in a way that – going by the Scrum manual – is no longer Scrum (think time boxes beyond 30 days).
My hope is that hg-git will take a leap forward and that the Heptapod efforts to provide an HGitaly will culminate in better support and hopefully even a situation where interop will be a main concern for both sides with one software like GitLab supporting both VCSs. I’ve even pondered looking into writing something along the lines of Gitea for both Git and Mercurial, but using Rust.
@oliver: I totally agree with you on the comparison between git and mercurial. Mercurial is ergonomic, works well and mostly gets out of the way. TortoiseHg, its GUI, albeit non aesthetically modern, is extremely powerful.
The combination hg + hg-git for directly interacting with git remotes (including Github) used to be a viable road for who wanted to live a happier life. In this moment (may 2020) hg-git is not in a good shape due to the py2->py3 transition having demanded its toll.
Hopefully that will improve, or the new experimental extension in https://phab.mercurial-scm.org/D6734 will reach maturity.
Bye
It appear that the Project has moved to use git at https://github.com/windirstat/windirstat
That’s correct. Since there are now other contributors — notably Bryan — and it creates less friction it was fully migrated to Git and is hosted still at SF.net, GitHub and other platforms. Because GitHub alone doesn’t really cut it.
Hi @Oliver! Thank you for investigating RhodeCode as an option! I’m just here to say that free open-source Community Edition of RhodeCode is here to stay. And we’re planning to support all – SVN, Mercurial, and Git – for a very long time! Let me know if we can share any additional info with you and make your investigation easier!