Mercurial 2.9 released(mercurial.selenic.com)
mercurial.selenic.com
Mercurial 2.9 released
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.9_.282014-2-1.29
8 comments
Very glad to see this in between all the git monoculture. Yes, GitHub is kind of nice for some things, but git really isn't.
What a contentless comment. One might just as well flatly claim that mercurial isn't nice for anything.
git's CLI design is byzantine and inconsistent, with terms that are both overloaded and underloaded (many commands do multiple, unrelated things while at the same time many common tasks do not have commands). It's very easy for newcomers to place their local repo into a limbo or failure state that they can't get out of without consulting a git guru. git's error messages and man pages are written for its developers, not for its users. git's overall CLI structure maps poorly onto its underpinnings, half-hiding parts and not explaining the rest. Pushing and pulling have really bizarre default behavior that easily confuse those who have not carefully studied how they work.
git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.
(Don't get me wrong, I use git all the time and appreciate its power. I just wish Linus has asked someone else to design the CLI.)
git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.
(Don't get me wrong, I use git all the time and appreciate its power. I just wish Linus has asked someone else to design the CLI.)
> git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.
To some extent, the same arguments can be used by newbies against any powerful tool (such as vim).
To some extent, the same arguments can be used by newbies against any powerful tool (such as vim).
As far as I am concerned, the gap in power between git and hg is much smaller than the gap in ease of use. The ease-of-use argument is only countered when there is real value to using the more frustrating alternative, and I'm not sure there is with git (besides the existence of GitHub, and the support of Linus Torvalds).
This is precisely the reason I couldn't force myself to use Git. The UI of Mercurial is so much more consistent and intuitive. I find it easier for non-technical people in the company to share files.
That came quite close to happening. Quite quickly after git appeared, several alternative CLI's called porcelains were developed. The most popular was cogito. Git itself quickly stole the nice features from the porcelains withered. At that time only power users used git, so there was little interest in the porcelains and the nicer interfaces were list.
For the average user, git and mercurial have similar commands, a lot of the time you could just replace `git` with `hg` and it works.
I also don't believe that mercurial has a 'cleaner UI', especially when it comes to merge.
For advanced users, git has a lot more to offer by default, you need to install a boatload of extensions on hg to achieve the same functionality.
I also don't believe that mercurial has a 'cleaner UI', especially when it comes to merge.
For advanced users, git has a lot more to offer by default, you need to install a boatload of extensions on hg to achieve the same functionality.
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.
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.
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 back in the day.
* Github : this was the nail in the coffin of all the other DVCS-es as they say. It just came on time, with a nice interface,issues, easy to fork, do pull requests, markdown readmes etc. Not all rocket science features but it was just working very consistently and smoothly.
Now I liked bazaar better if I were not to compare them on performance back in the day. I like some of its centralization options, other things. But it is kind of too late in that sense. Launchpad should have appeared, say 6 months earlier, and it should have been smoking fast. It wasn't. And so my favorite DVCS was left behind. Bitbucket is also very nice. I really like it. But well all the cool kids are on Github so some projects just moved to that. I creates kind of mono-culture and I am not sure if it is good or bad yet.
At the end of the day there are 2 type of developers -- those who care about version control systems, read about them, play with them, and those that don't. This classification usually says nothing about other qualities, experience, personality traits etc. It is just the second group just cares to use it as a tool. They are willing to learn the minimum amount of command from a refcard to get their code committed. And having just one system means having one ref card only if they have to collaborate. So learning git/Github interface is the easiest way to proceed.
* 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 back in the day.
* Github : this was the nail in the coffin of all the other DVCS-es as they say. It just came on time, with a nice interface,issues, easy to fork, do pull requests, markdown readmes etc. Not all rocket science features but it was just working very consistently and smoothly.
Now I liked bazaar better if I were not to compare them on performance back in the day. I like some of its centralization options, other things. But it is kind of too late in that sense. Launchpad should have appeared, say 6 months earlier, and it should have been smoking fast. It wasn't. And so my favorite DVCS was left behind. Bitbucket is also very nice. I really like it. But well all the cool kids are on Github so some projects just moved to that. I creates kind of mono-culture and I am not sure if it is good or bad yet.
At the end of the day there are 2 type of developers -- those who care about version control systems, read about them, play with them, and those that don't. This classification usually says nothing about other qualities, experience, personality traits etc. It is just the second group just cares to use it as a tool. They are willing to learn the minimum amount of command from a refcard to get their code committed. And having just one system means having one ref card only if they have to collaborate. So learning git/Github interface is the easiest way to proceed.
> 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).
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).
git is still slower than hg for some operations, such as blame and clone. I think it's fundamentally due to the nature of git's data structures, they just don't optimise for this case, but David Kastrup has boasted that he can fix git's slowness. I'm skeptical, but let's see...
Linus is the reason, I guess.
I tend to think that if Git was written by somebody other than Linus, it wouldn't have gotten so popular. After all, Git was not even envisioned as a VCS [1], and all the usual VC-related functionality has been bolted onto it without a single design vision, which is why we have this clusterfuck of a CLI now.
Sometime after that there was GitHub.
[1]: http://marc.info/?l=linux-kernel&m=111288700902396
I tend to think that if Git was written by somebody other than Linus, it wouldn't have gotten so popular. After all, Git was not even envisioned as a VCS [1], and all the usual VC-related functionality has been bolted onto it without a single design vision, which is why we have this clusterfuck of a CLI now.
Sometime after that there was GitHub.
[1]: http://marc.info/?l=linux-kernel&m=111288700902396
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 -- like Facebook's[1], but only because Facebook engineers decided that functionality was easier to add to mercurial than to git.
[2] https://news.ycombinator.com/item?id=7019673
[2] https://news.ycombinator.com/item?id=7019673
1) Linux and it's viral tirade on SVN on Youtube.
2) Cargo-cult computing.
3) Very strategic integration with Heroku and Xcode. Both are very important force multipliers. It was initially the Ruby folks they were the champions of Git outside of the Linus kernel devs.
4) Github.
5) Silicon Valley. SV is a very large echo chamber, the fact that Github is in the middle of it gives you an edge. Bitbucket is based out in Australia I think, there was less people to talk to, less good people for hire etc. Back in around 2008, both Github and Bitbucket were terrible.
2) Cargo-cult computing.
3) Very strategic integration with Heroku and Xcode. Both are very important force multipliers. It was initially the Ruby folks they were the champions of Git outside of the Linus kernel devs.
4) Github.
5) Silicon Valley. SV is a very large echo chamber, the fact that Github is in the middle of it gives you an edge. Bitbucket is based out in Australia I think, there was less people to talk to, less good people for hire etc. Back in around 2008, both Github and Bitbucket were terrible.
It isn't _just_ GitHub, but it's 90% GitHub. And 10% Torvalds. The important part is that it's 0% actual, useful reasons.
Because is it better. Very simle reason, although very difficult to stomach for some.
The only bug here that was "bugging" me was that issue 3857, where you had to specify the username in your config rather than being able to just do it on the fly in the command. Nice to see the rest getting fixed, though.
While we're talking about Mercurial (which is rare), the crecord extension may be getting Windows support soon -- there's a Windows fork, and the original author wants to merge it in. Crecord is a command-line interface for choosing which specific lines to include in a commit. It's one of the reasons why I feel hg is very useable from the command line, even if you aren't a command-line wizard.
crecord: https://bitbucket.org/edgimar/crecord/
windows fork: https://bitbucket.org/jmb/crecord
While we're talking about Mercurial (which is rare), the crecord extension may be getting Windows support soon -- there's a Windows fork, and the original author wants to merge it in. Crecord is a command-line interface for choosing which specific lines to include in a commit. It's one of the reasons why I feel hg is very useable from the command line, even if you aren't a command-line wizard.
crecord: https://bitbucket.org/edgimar/crecord/
windows fork: https://bitbucket.org/jmb/crecord
I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?
Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: GitHub is why git won, and people are still learning how terrible git is and how awesome Mercurial is. They don't "still use" Mercurial, they "still use" git.
Mercurial has a great API. git has a terrible API. Mercurial is a joy to extend in Python. git is impossible to extend to any meaningful degree and is a terrible mess of Perl, shell script and C.
git is a hack and Mercurial is the future.
Mercurial has a great API. git has a terrible API. Mercurial is a joy to extend in Python. git is impossible to extend to any meaningful degree and is a terrible mess of Perl, shell script and C.
git is a hack and Mercurial is the future.
Git an Mercurial are so similar. You have to remember that Git, Mercurial, and Bazaar were all released within a month of one another to do basically the same thing (because BitKeeper took their licenses away from linux debs). They all have very similar concepts and try to solve the same problem in near the same way. Each of these DVCSs have stolen concepts from one another and there isn't a lot differentiating them. Sure, syntax and terminology differ, but they all end up working pretty similar to one another.
You have tools like Kiln Harmony[0] that lets you use git/mercurial for the same repo (looks like it cross-commit between the 2).
Git gives you all commands all at once, while Mercurial gives you just the functionality needed 90% of the time that can't really get you in trouble. Mercurial ships officially supported extensions with Mercurial that let you do history rewriting and other fun stuff that people are used to with git rebase.
I'm more a fan of Mercurial's CLI syntax/terminology, but Git has really won the popularity contest at this point. If you ever have questions about Git usage, the question has probably already been asked and has a lot more people that know and enjoy it.
Mercurial does have some advantages going for it still I believe. Being purely written in python makes it work a bit better on Windows. And as Facebook has said, it is easier to develop new plugins for Mercurial (at least given their skillset). I also like the Mercurial Largefile extension (if you have to deal with a lot of binary data). I know there are 3rd party modules like git-annex, but nothing officially part of Git.
[0] http://blog.fogcreek.com/kiln-harmony-internals-the-basics/
You have tools like Kiln Harmony[0] that lets you use git/mercurial for the same repo (looks like it cross-commit between the 2).
Git gives you all commands all at once, while Mercurial gives you just the functionality needed 90% of the time that can't really get you in trouble. Mercurial ships officially supported extensions with Mercurial that let you do history rewriting and other fun stuff that people are used to with git rebase.
I'm more a fan of Mercurial's CLI syntax/terminology, but Git has really won the popularity contest at this point. If you ever have questions about Git usage, the question has probably already been asked and has a lot more people that know and enjoy it.
Mercurial does have some advantages going for it still I believe. Being purely written in python makes it work a bit better on Windows. And as Facebook has said, it is easier to develop new plugins for Mercurial (at least given their skillset). I also like the Mercurial Largefile extension (if you have to deal with a lot of binary data). I know there are 3rd party modules like git-annex, but nothing officially part of Git.
[0] http://blog.fogcreek.com/kiln-harmony-internals-the-basics/
I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.
I use Git because everyone else does. And I'm not ashamed of that; I think it's pragmatic. However, I think I would prefer if the crowd had converged on Mercurial instead.
But being more popular is a reason groups will pick it. See Emacs's discussion on moving away from BZR [0]. While there are some people that like HG, Git popularity brings some benefits with it.
A larger user base and a large number of companies using it mean that there will be more investment in the tool. So there is a variety of companies that invest in it. There is a smaller chance development will stop on Git compared to HG. So basically the Emacs team concluded they don't want to be stuck with another BZR, and Git seems like a safer choice.
A variety of companies have bet on HG, but decided they needed to support Git along side it to get more sales (Fog Creek and Atlassian).
I feel like Github was the deciding tech that made Git the more popular code. There are a number of other companies supporting HG still, so it won't go away anytime soon, but it's hard to say if it'll be here as long as Git.
[0] http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg000...
A larger user base and a large number of companies using it mean that there will be more investment in the tool. So there is a variety of companies that invest in it. There is a smaller chance development will stop on Git compared to HG. So basically the Emacs team concluded they don't want to be stuck with another BZR, and Git seems like a safer choice.
A variety of companies have bet on HG, but decided they needed to support Git along side it to get more sales (Fog Creek and Atlassian).
I feel like Github was the deciding tech that made Git the more popular code. There are a number of other companies supporting HG still, so it won't go away anytime soon, but it's hard to say if it'll be here as long as Git.
[0] http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg000...
I like git because it stores objects, not diffs and you can recover from almost anything with reflog.
> I like git because it stores objects, not diffs
Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]?
[1]: http://git-scm.com/book/en/Git-Internals-Packfiles
Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]?
[1]: http://git-scm.com/book/en/Git-Internals-Packfiles
I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.
But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.
Yeah for sure. Mercurial is great too.
I was thinking of SVN which does store its commits as diffs, which makes it brittle (anyone that has tried to use the svn admin tools to rewrite the repository will know what I mean).
I was thinking of SVN which does store its commits as diffs, which makes it brittle (anyone that has tried to use the svn admin tools to rewrite the repository will know what I mean).
> Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite:
For everybody who does not like git there is one who does. I vastly prefer git over hg after having used hg for a few years and I did not regret switching a single bit.
For everybody who does not like git there is one who does. I vastly prefer git over hg after having used hg for a few years and I did not regret switching a single bit.
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.).
If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager (http://www.scm-manager.org/), which is free, supports both Hg and Git, and (IMO) pretty easy to put up on a Windows server. I have not tried others that use purely Git, though, and I've never tried setting SCM Manager up on a Linux server.
Personally, I have no problem if the whole team decides to use Git instead of what we're using now (TFS), but most of them, if not all, avoid the CLI like a plague. Even with excellent GUI frontends like Git Extensions and SourceTree.
If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager (http://www.scm-manager.org/), which is free, supports both Hg and Git, and (IMO) pretty easy to put up on a Windows server. I have not tried others that use purely Git, though, and I've never tried setting SCM Manager up on a Linux server.
Personally, I have no problem if the whole team decides to use Git instead of what we're using now (TFS), but most of them, if not all, avoid the CLI like a plague. Even with excellent GUI frontends like Git Extensions and SourceTree.
> 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=. --reuseaddr .
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=. --reuseaddr .
AFAIK, this does not work with Git in Windows. I will try it at home where I have Lubuntu and see. (If it works, I'll make an alias for it.) Thanks.
> If one needs to set up a local repo hosting service for internal use in a .NET company,
There's also (shameless plug follows) HgLab ( http://hglabhq.com/ ).
There's also (shameless plug follows) HgLab ( http://hglabhq.com/ ).
I was supposed to try this out after SCM Manager, but our IT admin has not replaced the server I was using after it broke. If I ever get access to one again, I'll try it.
SourceTree seems to get slower and slowerespecially if you have submodules and lots of branches. Not sure why. Any good alternatives out there?
If you're using just Git, have you tried Git Extensions (https://code.google.com/p/gitextensions/)? We don't use any submodules where I work, so I've never tried it with that.
I've been using both Git and Hg for different projects and found with recent releases (2.6 onwards) mercurial getting quite fast. I think hg commands are more sane and exposes only what it's required by users. Also there isn't anything you can do with hg but can't do with git and vice versa, if you look closely. These are just the tools that must help you get going, so if you/co-workers are comfortable with git, there is no reason to switch to hg. (and from hg to git as well). They both have pros and cons so we will never find THE BEST dvcs. Don't bother too much (they both are super capable) rather focus on problems that need more attention.
Mozilla does. It's been discussed numerous times on mozilla.dev mailing lists [1], with a lot of great discussion about it.
[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform...
[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform...
Facebook does as well.
https://code.facebook.com/posts/218678814984400/scaling-merc...
https://code.facebook.com/posts/218678814984400/scaling-merc...
Four reasons, all dating back to when I started using VC.
1) The GUIs were better, especially on windows. I think that gap has closed some in the last few years, but I think hg still has an edge.
2) Bitbucket offered free private repos and was hg only when they started out
3) The command line semantics were less imposing
4) I happened to find some really good introductory literature for hg.
I was a very, very green developer at the time so all of these points mattered a lot.
1) The GUIs were better, especially on windows. I think that gap has closed some in the last few years, but I think hg still has an edge.
2) Bitbucket offered free private repos and was hg only when they started out
3) The command line semantics were less imposing
4) I happened to find some really good introductory literature for hg.
I was a very, very green developer at the time so all of these points mattered a lot.
For me, it's:
1. The queues extension.
2. A bazillion other extensions.
3. The source code is pretty reasonable -- even mortal humans can contribute and write their own extensions.
I've found the queues extension to be really useful. It's like having multiple staging areas, which will later become multiple commits. I tend to change too many things, and then remember that I need to create specific commits. Queues makes that possible. I haven't found a good way of doing that in git, although I still use git every day without any big problems.
1. The queues extension.
2. A bazillion other extensions.
3. The source code is pretty reasonable -- even mortal humans can contribute and write their own extensions.
I've found the queues extension to be really useful. It's like having multiple staging areas, which will later become multiple commits. I tend to change too many things, and then remember that I need to create specific commits. Queues makes that possible. I haven't found a good way of doing that in git, although I still use git every day without any big problems.
git stash?
Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.
Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.
The exact same workflow works pretty much the same way in hg, with shelve (stash) and histedit (rebase -i). There is even a better way nowadays with hg evolve, but it's still beta.
Hows the backup story with Hg nowadays? Git uses an immutable storage solution, so rebasing or other commands to alter history doesn't delete anything. Hg doesn't have the same architecture, so how does undoing histedit work? Genuinly interested, not trying to start a flamewar.
We use hg because bitbucket.org offered free private repos (no git back then) and it completely meets our needs.
I'm also not familiar enough with git to know what benefits it provides over mercurial.
I'm also not familiar enough with git to know what benefits it provides over mercurial.
I consider hg far more easy to use than git, specially for the most used commands (status, fetch, push). I need to check the docs about how do the damm push each time with github.
My only gripe with mercurial? That everyone else asume git.
My only gripe with mercurial? That everyone else asume git.
check the docs? What is so hard to remember about "git push"?
This:
jordi@Iris:~$ git help push | wc -l
544
jordi@Iris:~$ hg help push | wc -l
50This is due to Git's tight integration with regards to branches and namespaced branches though isn't it? Hg push isn't aware of bookmarks as far as I know, so Git has more to explain compared to Hg, where lightweight branches are a plugin. Or am I wrong on this?
Wow. I use Mercurial so much, that I forget that some people have no idea about it at all.
No, hg bookmarks are not a plugin, although they were like four years ago. Hg push has this to say about bookmarks:
No, hg bookmarks are not a plugin, although they were like four years ago. Hg push has this to say about bookmarks:
If -B/--bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository.
It is still a plugin, it's just bundled/installed by default. I've worked with Mercurial for the better part of a year, I'm not clueless about it.
But yeah, since branches/bookmarks are an integral part of how you work with Git, you also have more options regarding branches/bookmarks in several git commands. Git allows you to push a local branch to a remote branch of a different name. This is helpfull when you're pushing to different remotes, and the some of the local branches should map to master on different remotes. But this of course requires more information to stand in git pull's documentation. There are, of course, other features as well.
Just because git push has some 'advanced' featues, doesn't make the actual push command difficult to understand though. Most of the time you just use 'git push', same as Mercurial, git just allows you to do more with git push than what Mercurial allows you to.
But yeah, since branches/bookmarks are an integral part of how you work with Git, you also have more options regarding branches/bookmarks in several git commands. Git allows you to push a local branch to a remote branch of a different name. This is helpfull when you're pushing to different remotes, and the some of the local branches should map to master on different remotes. But this of course requires more information to stand in git pull's documentation. There are, of course, other features as well.
Just because git push has some 'advanced' featues, doesn't make the actual push command difficult to understand though. Most of the time you just use 'git push', same as Mercurial, git just allows you to do more with git push than what Mercurial allows you to.
At work we have non-devs (mostly scientists) using our repos, and I didn't want to have to teach them git. Mercurial is much easier to pick up IME. With the right plugins enabled, there's not much I miss day to day compared with git.
At home I still use git. In part because of github, in part because I like some of the default behaviour better, and in part because being forced to learn how it works to dig my way out of holes broadens my understanding of DVCSs in general.
At home I still use git. In part because of github, in part because I like some of the default behaviour better, and in part because being forced to learn how it works to dig my way out of holes broadens my understanding of DVCSs in general.
Mercurial gives you complete DAG of history with enough tools (revsets) to filter and view it in any way.
Git lets you peep into the DAG of history through small windows, called 'branches'.
This was the biggest annoyance for me when I tried git. You cannot even ask git for the id of the currently checked out revision, ie if you are not on a branch tip.
And yes, the inconsistent cli is a big turnoff too.
Git lets you peep into the DAG of history through small windows, called 'branches'.
This was the biggest annoyance for me when I tried git. You cannot even ask git for the id of the currently checked out revision, ie if you are not on a branch tip.
And yes, the inconsistent cli is a big turnoff too.
I got used to how hg works and now, in comparison, git always confuses the hell out of me with its unintuitive commands and odd walls-of-text errors.
I 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
[1]: http://mercurial.selenic.com/wiki/ChangesetEvolution
I wish I knew what you are talking about- it sounds useful. I use mercurial- I've never used git.
For 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 way, not to mention the continuous integration goodness that comes with gitlab-ci.
There is, to my knowledge, no close equivalent for hg.
there is rhodecode.com, It's very nice product and I use it on a daily basis.
Has anyone used this (or something similar)?
the Hg-Git mercurial plugin
http://hg-git.github.io/
the Hg-Git mercurial plugin
http://hg-git.github.io/
I've tried to use it to mirror an old Hg repo in git, but ran into some really weird errors with branches in Hg causing vague errors. I couldn't get any help on the mailing list, and I ended up giving up right as the project said "Forget it, let's just move to Git."
This was about six months ago. I don't have the error message. I got the impression that the documentation and the support were pretty sparse for this plugin. Though, it may work well for more simple Hg repositories, I guess.
This was about six months ago. I don't have the error message. I got the impression that the documentation and the support were pretty sparse for this plugin. Though, it may work well for more simple Hg repositories, I guess.
Yes, it works great. If you prefer hg you can push your code to github and get pull requests, etc. from people who only know git.
hg-git works flawlessly as long as you are using hg-git _and_ python-dulwich from their repos heads. Their releases on PyPI are always somehow out of date.
I used this for a while to push from hg to heroku, but it screwed up in a major way at some point and left the repo essentially useless.
The monthly updates always scare me a bit for version control. Is that really prudent?
They're actually very big on backwards compatibility. It's quite straightforward to work with repositories created by old mercurial versions on and communicate with mercurial installs with different versions. The only thing that won't work is features that are only in the newer version.
The real effect of the monthly releases is that bugs get cixed in releases, new features get added, and I get to regularly see all of the awesome activity going on in the mercurial world.
The real effect of the monthly releases is that bugs get cixed in releases, new features get added, and I get to regularly see all of the awesome activity going on in the mercurial world.
This is something that has always made us a little nervous about updating here as well. Do you know whether the underlying data structures for repositories are generally maintained with both forward and backward compatibility?
Edit: For anyone else interested, I finally found the magic search term I never had before, which led me to this page about upgrading and compatibility:
http://mercurial.selenic.com/wiki/UpgradingMercurial
and this page about potentially breaking changes where they do occur:
http://mercurial.selenic.com/wiki/UpgradeNotes
The short version is that older and newer Hg clients and servers and mostly interoperable in all directions, but with a few specific caveats that are worth reading before you upgrade anything. There is also the ability to explicitly change the underlying repository format for compatibility reasons if you need to.
Edit: For anyone else interested, I finally found the magic search term I never had before, which led me to this page about upgrading and compatibility:
http://mercurial.selenic.com/wiki/UpgradingMercurial
and this page about potentially breaking changes where they do occur:
http://mercurial.selenic.com/wiki/UpgradeNotes
The short version is that older and newer Hg clients and servers and mostly interoperable in all directions, but with a few specific caveats that are worth reading before you upgrade anything. There is also the ability to explicitly change the underlying repository format for compatibility reasons if you need to.
The monthly releases are bugfix only. New features are released every three months (and release process has an extended freeze where only bug fixes are allowed for a couple of weeks before the release)