Earlier quoted context omitted.
> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…
> Ouch, yet another way in which running on Windows can lead to poor technical decisions. I didn't see any indication in the parent comment (or in general, really) that Windows support was the cause of Mercurial's difficulty in implementing those features.
I'm going to slowly move on from Mercurial
41–50 of 165 posts
Re: I'm going to slowly move on from Mercurial
#42Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.
Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
Re: I'm going to slowly move on from Mercurial
#43Earlier quoted context omitted.
Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actual…
> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…
How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the files, or even a part of a file if you use the record extension.
Re: I'm going to slowly move on from Mercurial
#44hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
hg came before git, you have your network effect backwards. The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly. Mercurial, in contrast, is "opinionated". (Before you mention github -- the timeline here is also backwards, github became…
Re: I'm going to slowly move on from Mercurial
#45Earlier quoted context omitted.
Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
Docs:
https://selenic.com/hg/help/revsets
A complete example, which appears to have some popularity in Mozilla:
http://jordi.inversethought.com/blog/customising-mercurial-l...
edit: Sorry, the --decorate part would be with template, the --all is kind of like a revset, and the --graph part is well, --graph.
Re: I'm going to slowly move on from Mercurial
#46Earlier quoted context omitted.
Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
Re: I'm going to slowly move on from Mercurial
#47Earlier quoted context omitted.
Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
Re: I'm going to slowly move on from Mercurial
#48hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
Yeah by "git's network effects" you mean github. If github had decided to be hghub instead, hg would probably have won.
Re: I'm going to slowly move on from Mercurial
#49Earlier quoted context omitted.
Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)
What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
Re: I'm going to slowly move on from Mercurial
#50Earlier quoted context omitted.
> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…
> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the file…
It's now part of core with `hg commit -i`, although it's still experimental.