I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.
Mercurial 2.9 released
61–70 of 79 posts
Re: Mercurial 2.9 released
#62Re: Mercurial 2.9 released
#63For all the reasons mentionned in this thread (interface consistency, performance, ...) hg is far superior to git. But, as long as git would get the cool tools - namely, gitlab / gitlab-ci - people won't bother looking at hg. I started a new project with collaborators a month ago, we had to chose git mainly because of gitlab, as it would ease the process of managing consistently our codebase in a visual and simple wa…
Re: Mercurial 2.9 released
#64Has anyone used this (or something similar)? the Hg-Git mercurial plugin http://hg-git.github.io/
Re: Mercurial 2.9 released
#65Earlier quoted context omitted.
> Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). You can do the same in git: git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/ or git daemon --verbose --export-all --base-path=. --reuse…
Or you can use git instaweb instead?
Re: Mercurial 2.9 released
#66Has anyone used this (or something similar)? the Hg-Git mercurial plugin http://hg-git.github.io/
Re: Mercurial 2.9 released
#67Re: Mercurial 2.9 released
#68I would LOVE to use mercurial. If the concept of a backup bundle was completely removed. When I amend a commit with git, I don't put myself 20 minutes away from recovering that pre-amend commit. If hg comes up with some way to have a flat namespace like git, (ideally with a reflog) I'll be back.
That whole "back up a part of history so that you could undo stuff later" will be gone as soon as Changeset Evolution [1] is ready. An when it's ready, it will be tremendous. [1]: http://mercurial.selenic.com/wiki/ChangesetEvolution
Re: Mercurial 2.9 released
#69Earlier quoted context omitted.
3 reasons: * Linux Kernel : this means for once, great popularity. Those who commit to the kernel have quite a bit of say and influence in the industry. The tools they use get free marketing just from that. But this actually leads to the next reason --> * Speed : initially git was quite a bit faster. It had been tested and benchmarked day to day on the kernel source tree. hg, bazaar and others weren't as performant b…
> Speed Actually in 2005 performance was pretty similar and for some workflows hg was definitely faster (patch + commit). Also before packs were introduced git just used massive disk space (hg had smart storage from day one).
Re: Mercurial 2.9 released
#70Earlier quoted context omitted.
Speed and workflow, previously. Mercurial has made up most of the difference in speed, so now git is better for some things ([temporary] topic branch workflow and history clean-up of such branches before merge is more likely to be used by git committers even if hg technically has that now, speed in a few cases, mindshare) while mercurial is better for other things like syntax, or dealing with gigantic repositories --…
I think hg has both temporary (bookmarks) and permanent (branches) branch workflow out of the box now- and has for a while.