Python now uses Mercurial(hg.python.org)
hg.python.org
Python now uses Mercurial
http://hg.python.org/cpython/
113 comments
Git and Hg accomplish essentialy the same thing.
The platform support and tool/utility support for Mercurial on windows in important to note.
I decided to choose Mercurial as the VCS for my 'work'. This was a team that had no prior exposure to VC before. And works in a mixed environment. Hg follows the 'one true way' philosophy of Python; so there's just a single command to learn for each task. Plus, Bitbucket's new Free pricing plan for tiny teams convinced me to go with it for online hosting(rather than roll our own hg server over vpn)
Though, If I had to choose a host/vcs for 'my awesome FOSS community project', it would go on Github.
I decided to choose Mercurial as the VCS for my 'work'. This was a team that had no prior exposure to VC before. And works in a mixed environment. Hg follows the 'one true way' philosophy of Python; so there's just a single command to learn for each task. Plus, Bitbucket's new Free pricing plan for tiny teams convinced me to go with it for online hosting(rather than roll our own hg server over vpn)
Though, If I had to choose a host/vcs for 'my awesome FOSS community project', it would go on Github.
This is basically where I stand as well. Git has no real appeal for me, but GitHub does. Plus, with the ridiculously easy hg-git[1] tool, I'm able to take advantage of GitHub while staying in my Hg comfort zone :)
[1]: http://hg-git.github.com/
[1]: http://hg-git.github.com/
Heh, I'm the exact opposite. I use a hg-to-git tool to access hg repositories, because I'm much more comfortable with git.
I often hear people claiming hg is easier to use and has a better interface, but every time I have to use hg it rubs me the wrong way because I can't use it like I use git :/ (In particular, I find hg branches needlessly complicated and cumbersome compared to git's "just a pointer" model)
I guess between the two you'll end up using the one you first bother to learn beyond memorising basic commands.
I often hear people claiming hg is easier to use and has a better interface, but every time I have to use hg it rubs me the wrong way because I can't use it like I use git :/ (In particular, I find hg branches needlessly complicated and cumbersome compared to git's "just a pointer" model)
I guess between the two you'll end up using the one you first bother to learn beyond memorising basic commands.
Same. Branches are a dealbreaker.
hg bookmarks are the equivalent of git branches for the most part. Check out those next time you use mercurial.
As someone who hasn't used Hg before, I'm curious -- what are some examples of Git commands that are better executed in Hg?
No specific commands really, but I think the whole hg UI is just more consistent. I use both, yet with git I have to revert to `man` almost every day :/
Compare: `git branch xxx / git branch -a`, `git tag xxx / git tag -l`, `git show-ref --heads`
To: `hg branch xxx / hg branches`, `hg tag xxx / hg tags`, `hg heads`
There are also "duplicates" that I'm not sure why aren't folded into one command: `show-branch/branch`, `show xxx` which is `diff -c xxx` in many other systems, etc.
These are just simple cases, but there's loads of situations where you have to find out yet another command in git / yet another parameter to do what you want. Hg has better defined defaults and the whole list of commands looks like it was designed, while git looks like everyone just added what they needed... Auto-expanding commands in hg is also nice - I hate it when git tells me 'ci' or other short name is not a command (yeah, I know about aliases).
In some situations I also think that git does exactly what it's programmed to do... which isn't always the same as - what workflow makes sense in a specific case. For example `branch` creates a branch, but you still need to do `checkout` (or just `checkout -b ...`). Why? What's the common use case for creating a branch you're not going to work on? Which behaviour do you expect more often?
All in all, not the end of the world, but when you use the tool every day, it becomes annoying, especially if you see it can be done better.
Compare: `git branch xxx / git branch -a`, `git tag xxx / git tag -l`, `git show-ref --heads`
To: `hg branch xxx / hg branches`, `hg tag xxx / hg tags`, `hg heads`
There are also "duplicates" that I'm not sure why aren't folded into one command: `show-branch/branch`, `show xxx` which is `diff -c xxx` in many other systems, etc.
These are just simple cases, but there's loads of situations where you have to find out yet another command in git / yet another parameter to do what you want. Hg has better defined defaults and the whole list of commands looks like it was designed, while git looks like everyone just added what they needed... Auto-expanding commands in hg is also nice - I hate it when git tells me 'ci' or other short name is not a command (yeah, I know about aliases).
In some situations I also think that git does exactly what it's programmed to do... which isn't always the same as - what workflow makes sense in a specific case. For example `branch` creates a branch, but you still need to do `checkout` (or just `checkout -b ...`). Why? What's the common use case for creating a branch you're not going to work on? Which behaviour do you expect more often?
All in all, not the end of the world, but when you use the tool every day, it becomes annoying, especially if you see it can be done better.
There have been times that I've created a branch just to have a stopping point to which I can go back, but I wasn't going to do any work on it, at least not yet, like two choices on how to re-factor something, try one, if it fails try the other, but keep both around for testing.
Hope this helps, then:
git tag -a tagname
git push --tags
git checkout tagname
http://git.or.cz/course/svn.html
BTW, it's also worth noting that hg can have tag merge conflicts (http://mercurial.selenic.com/wiki/GitConcepts), which is just weird.
For anyone looking to learn more about git, I haven't found a better resource than this talk: (video) http://blip.tv/file/4094854 (slides) http://www.slideshare.net/chacon/getting-git
That said, I migrated from hg to git, and I love them both way more than svn.
git tag -a tagname
git push --tags
git checkout tagname
http://git.or.cz/course/svn.html
BTW, it's also worth noting that hg can have tag merge conflicts (http://mercurial.selenic.com/wiki/GitConcepts), which is just weird.
For anyone looking to learn more about git, I haven't found a better resource than this talk: (video) http://blip.tv/file/4094854 (slides) http://www.slideshare.net/chacon/getting-git
That said, I migrated from hg to git, and I love them both way more than svn.
`show xxx` which is `diff -c xxx`
An example that I just came across in normal usage:
git show <branch_name>:<filename>
I use both git and hg - and like both of them (though I have more experience with hg). Github is far and away the best hosted distributed version control service, with a constant stream of innovative features for open-source developers over the last 2 years.
Git has had two main drawbacks in my mind. 1) Much of it is implemented as script commands, and I think it still requires you run an emulated shell in Windows to use it (by contrast, Mercurial is a pure python app, and is ultra-portable). 2) Coming from the Linux community, it seems a little heavy weight for small projects. Some command require what seem like extra steps on Git as compared to Hg. For example, Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).
For complex scenarios, Git's system does provide a bit more control in packaging up exactly the set of changes you want in each atomic revision.
Besides these minor historical differences, I think they both are excellent, and are really a matter of personal or team preference.
Git has had two main drawbacks in my mind. 1) Much of it is implemented as script commands, and I think it still requires you run an emulated shell in Windows to use it (by contrast, Mercurial is a pure python app, and is ultra-portable). 2) Coming from the Linux community, it seems a little heavy weight for small projects. Some command require what seem like extra steps on Git as compared to Hg. For example, Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).
For complex scenarios, Git's system does provide a bit more control in packaging up exactly the set of changes you want in each atomic revision.
Besides these minor historical differences, I think they both are excellent, and are really a matter of personal or team preference.
Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).
This is one of the features of git I most appreciated when I started using it (my first VCS was Mercurial).
I get distracted easily. While I'm rooting through the code base trying to do something, I'll notice something else to fix. And something else. And something else. By the time I've finished whatever I was trying to do in the first place, I've got 5 or 6 different things I've actually done.
In git, it's trivial to split these up - `git add` separate files, or `git add -p` when you only want to stage some of the changes in a file. This leads to cleaner commits.
I've heard people decry this, saying that you should be testing each individual state of your codebase. git being the powerful sonuvabitch it is, you can do that:
* `git stash --keep-index` will store away all of your modifications, other than the ones you're getting ready to commit. Run your tests, commit, `git stash pop`. * Checking out different revisions and running tests isn't a bad option, either, whether you use `git bisect` or do it manually. With the amazing power of `git rebase -i`[0], you can easily fix any little issues without disrupting other commits.
[0]: http://schacon.github.com/history.html
You will change their SHA1 sums, so they'll become different commits. This isn't a problem, though, if you haven't pushed them up to a shared repository.
This is one of the features of git I most appreciated when I started using it (my first VCS was Mercurial).
I get distracted easily. While I'm rooting through the code base trying to do something, I'll notice something else to fix. And something else. And something else. By the time I've finished whatever I was trying to do in the first place, I've got 5 or 6 different things I've actually done.
In git, it's trivial to split these up - `git add` separate files, or `git add -p` when you only want to stage some of the changes in a file. This leads to cleaner commits.
I've heard people decry this, saying that you should be testing each individual state of your codebase. git being the powerful sonuvabitch it is, you can do that:
* `git stash --keep-index` will store away all of your modifications, other than the ones you're getting ready to commit. Run your tests, commit, `git stash pop`. * Checking out different revisions and running tests isn't a bad option, either, whether you use `git bisect` or do it manually. With the amazing power of `git rebase -i`[0], you can easily fix any little issues without disrupting other commits.
[0]: http://schacon.github.com/history.html
You will change their SHA1 sums, so they'll become different commits. This isn't a problem, though, if you haven't pushed them up to a shared repository.
The differences on commit both have good arguments. hg is going for ease of use and is very much like the non-dvcs's that came before it, like CVS and Subversion where a commit commits all changed files.
git add just adds the file to the index and stages it for commit, this means you can group files logically depending on what has changed, you can even using git add -p have only certain parts of a files modifications be committed and the rest be staged for the next commit. This can be very powerful.
For example, if I did a full refactoring of a class, and fixed a quick bug rather than committing them both at the same time in the patch I can just keep the bug fix and then later commit the re-factored code even if it is in the same file.
git add just adds the file to the index and stages it for commit, this means you can group files logically depending on what has changed, you can even using git add -p have only certain parts of a files modifications be committed and the rest be staged for the next commit. This can be very powerful.
For example, if I did a full refactoring of a class, and fixed a quick bug rather than committing them both at the same time in the patch I can just keep the bug fix and then later commit the re-factored code even if it is in the same file.
Exactly. And if you know that you just want the SVN/HG commit-everything, just add a -a. Pretty intuitive.
Once you get used to having the ability to create arbitrary commits from a huge changeset, you'll find it aggravating when everyone else commits "3 bug fixes to core, swapping out a style sheet, and cleanup in database code" :)
Once you get used to having the ability to create arbitrary commits from a huge changeset, you'll find it aggravating when everyone else commits "3 bug fixes to core, swapping out a style sheet, and cleanup in database code" :)
Unfortunately people working with git at work are still doing exactly that. Not sure how to make them stop either, since so far telling them it is wrong hasn't helped ...
It's interesting that each major web language seems to have paired off with a different VCS:
- Python + Hg
- Ruby + Git
- PHP + ...SVN?
- Python + Hg
- Ruby + Git
- PHP + ...SVN?
PHP + ...SVN?
Gotta say, they deserve each other.
Gotta say, they deserve each other.
You know, comments like that disparage by implication anyone who finds value in PHP or SVN. That's a big chunk of the development community. It tears people apart rather than bringing them together. Maybe you should redirect your energy from snark and criticism toward something more constructive.
You can simultaneously find value in something, and have a sense of humour about that something's shortcomings. Learning to laugh at ourselves is probably the greatest thing humanity could do to further peace and happiness.
That's a fair point, when it applies. But I perceive this joke as coming more often from a sense of superiority and an emotionally ill-conceived attempt to improve others by insulting them.
Or perhaps it comes out of pent up frustration at having to use them myself in work environments ;)
You know, comments like that disparage by implication anyone who finds value in PHP or SVN.
Maybe if we disparage them enough they'll switch to a real programming language and version control tool.
Maybe if we disparage them enough they'll switch to a real programming language and version control tool.
Why is PHP not a "real" programming language? Why is subversion not a "real" version control tool?
Yes, I've programmed in PHP and know it has some downsides, and that it has some big warts that are ugly, but it is a real programming language. Real projects are built with PHP.
Now I understand the frustration with Subversion, but it still is a version control system that is used in the real world. Would I love it if everyone decided to move away from SVN and onto something more capable like Git or Mercurial, yes, but that doesn't mean we have to belittle people who are using those tools.
Yes, I've programmed in PHP and know it has some downsides, and that it has some big warts that are ugly, but it is a real programming language. Real projects are built with PHP.
Now I understand the frustration with Subversion, but it still is a version control system that is used in the real world. Would I love it if everyone decided to move away from SVN and onto something more capable like Git or Mercurial, yes, but that doesn't mean we have to belittle people who are using those tools.
PHP is the Walmart of languages, everyone uses it because everyone uses it, but nobody really has anything _good_ to say about it.
I wasn't going to jump into this discussion but that isn't very fair. I don't use PHP myself and am not a fan of it but here are some reasons why I think it is popular:
1) It's very easy to get started with, even if you're not a great programmer (or even if you have never programmed before). Just start with pure HTML and then add a few <?php> tags. 2) Lots of PHP hosting available, much of it free. 3) Loads of frameworks and libraries available.
I'm sure a PHP fan could come up with a few more.
1) It's very easy to get started with, even if you're not a great programmer (or even if you have never programmed before). Just start with pure HTML and then add a few <?php> tags. 2) Lots of PHP hosting available, much of it free. 3) Loads of frameworks and libraries available.
I'm sure a PHP fan could come up with a few more.
2 and 3 are not really advantages for PHP, as the same can be said for most any language.
I think #1 is the big reason that PHP is as popular as it is, but that "feature" has a funny smell among programmers who don't like to mix languages.
I think #1 is the big reason that PHP is as popular as it is, but that "feature" has a funny smell among programmers who don't like to mix languages.
If "real programming language" advocates spent more time creating equivalient/better alternatives to projects like Drupal or Wordpress in their preferred environments, they'd advance their goals much more than any HN/Proggit comment could.
Real programming language as in a language that powers a large chunk of the most visited web sites on the internet?
I don't do any PHP myself and my few forays into it didn't leave me impressed but I don't see how you can disparage it as not a "real language".
I don't do any PHP myself and my few forays into it didn't leave me impressed but I don't see how you can disparage it as not a "real language".
PHP developers can probably take comfort in the fact that much like Java, Perl, C, Snooki, and others, even though PHP is long past its "sexy" stage, it's well into its "many billion-dollar companies are built on this" stage.
SVN users, well, they probably just don't know any better. :)
SVN users, well, they probably just don't know any better. :)
Oh, geez. Lighten up.
and OpenCOBOL uses CVS
http://www.opencobol.org/ (http://sourceforge.net/projects/open-cobol/develop)
maybe a language older than that still uses RCS
http://www.opencobol.org/ (http://sourceforge.net/projects/open-cobol/develop)
maybe a language older than that still uses RCS
The ERP where I work wraps RCS with a bunch of scripts. It's used for source control (of course) but also schema migrations, source generation, and a million other things
I've checked files out that were last modified before I was born.
I've checked files out that were last modified before I was born.
Because they both have widespread adoption?
Because both are commonly perceived as a step backwards from the current state of the art, but more importantly because it's good sport to make cheap jabs at both of them :P
- Tcl + Fossil http://code.activestate.com/lists/tcl-core/10108/ :-)
That is an excellent choice for them. Dr. Hipp (author of SQLite) is the author of Fossil and a big Tcl fan. Tcl is maintained by a small core team of developers. Just an overall good fit for them.
The C Ruby implementation is actually on subversion with an official git mirror. Granted, most Ruby projects are hosted using git repositories these days.
There is a reason Python is paired with Mercurial.
Hg is written in Python. As for why Mercurial was chosen over Bazaar, it came down to popularity. As the core developer survey shows, hg was preferred over bzr.
Hg is written in Python. As for why Mercurial was chosen over Bazaar, it came down to popularity. As the core developer survey shows, hg was preferred over bzr.
That's not really the reason, and I believe it's even stated in the PEP.
Perl also uses Git.
And Go uses mercurial.
An explanation for that might be that Go, being a Google Project, is hosted on Google Code, where Mercurial is the only supported DVCS.
http://googlecode.blogspot.com/2009/04/mercurial-support-for... http://code.google.com/p/support/wiki/DVCSAnalysis
http://googlecode.blogspot.com/2009/04/mercurial-support-for... http://code.google.com/p/support/wiki/DVCSAnalysis
So nobody is using Monotone?
- .NET + VSS?
Codeplex, which is Microsoft's open source site, supports Mercurial, SVN and TFS.
Holy freaking cow, Microsoft has an open source hosting site?
it has more to do with corporate affiliations:
hg seems to be strong at Google github was done in ruby php ... whatever
hg seems to be strong at Google github was done in ruby php ... whatever
Java?
Java is a specification, the Oracle JRE/JDK is not open source. The OpenJDK uses Hg. When they talk about Python they are talking about the cpython or main implementation. Pypy, another Python implementation uses Hg as well
Interesting to note that bzr got close to mercurial in the votes in spite of this being bzr version 1. Version 2 is much improved in speeds (comparable to git/hg).
I myself am quite partial to bzr espeically since tortoise-bzr uses my favorite diff tool by default
http://doc.bazaar.canonical.com/explorer/en/guide/qbzr/qdiff...
I would be interested to know about other's impressions of bazaar and why most people seem to share the same sentiment towards it as those at pycon that year
While no one said they did not want bzr chosen, no one said they did either.
http://doc.bazaar.canonical.com/explorer/en/guide/qbzr/qdiff...
I would be interested to know about other's impressions of bazaar and why most people seem to share the same sentiment towards it as those at pycon that year
While no one said they did not want bzr chosen, no one said they did either.
I have been using bzr for 2+ years now. For personal projects I am quite happy with bzr+launchpad. At work, we have been using bzr on Linux.
The move from 1.x to 2.x brought in significant performance and memory improvements.
The move from 1.x to 2.x brought in significant performance and memory improvements.
I did detailed evaluation of bzr, git, hg and svn. And found bzr to be good too (at least equally good). Most comparisons I found online have been too old to be using older version of bzr which was very slow in comparison.
I am still unclear on the impact of a "branch" being the key concept in bzr as opposed to "repository" in git/hg.
Git's support on Windows has improved considerably (although I could not find a good GUI). So I rather find not much reason to use Hg!
I am still unclear on the impact of a "branch" being the key concept in bzr as opposed to "repository" in git/hg.
Git's support on Windows has improved considerably (although I could not find a good GUI). So I rather find not much reason to use Hg!
Announcement in Python-Dev:
http://mail.python.org/pipermail/python-dev/2011-March/10873...
http://mail.python.org/pipermail/python-dev/2011-March/10873...
via Guido (http://twitter.com/#!/gvanrossum/status/44169137240551424)
For those asking "why not git", read http://www.python.org/dev/peps/pep-0374/
For those asking "why not git", read http://www.python.org/dev/peps/pep-0374/
But why are they using Mercurial and not Git? I want to what are the advantaged for them to choose Hg.
http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...
Basically, they wanted a tool that was equally usable on all platforms, which excluded Git on Windows.
They also wanted something written in Python, of course, although they would have sacrificed that in the interest of pragmatism.
Basically, they wanted a tool that was equally usable on all platforms, which excluded Git on Windows.
They also wanted something written in Python, of course, although they would have sacrificed that in the interest of pragmatism.
In all fairness, I'd like to point out it's quite possible to make Git work on Windows. If one can adjust the path, it is also reachable through the same command line Windows folks are used to.
Quite possibe to make work and works equally well are not the same thing. Mercurial is a breeze to install on Windows and any other platform, and with TortoiseHg's recent move to Qt, full cross-platform GUI support is also there (right now there are no Mac installers, but there should be some soon).
As far as I know, Git was a lot more awkward to use on Windows when they started discussing this move a few years ago.
I've found git to be a ---- nightmare to use. Part of that is inexperience, part of that its UX is a turd compared to hg.
The last time I looked, Git on Windows required you use a different shell than the native Windows command shell (not that I'm a fan of the crappy Windows shell, but it does make it more awkward and feels less "native").
I've been using MsysGit (Windows) for about 18 months as a "local vcs" wrapper around a sucky vcs (Accurev). Until the most recent MsysGit release, I used the "git bash" shell exclusively: for each Accurev workspace, I had a CMD shell where I ran builds in the w/s, and a git bash shell where I operate git for that w/s. This was mostly satisfactory (being able to write true bash scripts to automate git a tiny bit was cool), but when working with sometimes a dozen or more workspaces, it can get a little time consuming to locate the respective shell's mate. Anyway, MsysGit has mostly worked quite nicely for my limited purposes. However I am now evaluating hg as a possible replacement for Accurev (I'm running a quasi-import over the weekend). I'm also running a git import in parallel (mostly to compare repo size growth over time), and to do that (in lockstep) I'm running git from a CMD shell; so far I've not had any problems using git in CMD (wait, git's interpretation of the %EDITOR% environment variable in CMD is broken). Why hg, after all my experience with git? As mentioned elsewhere in this discussion: MsysGit (git for Windows) is like a "second class citizen"; it's pretty clear that the git creators have a negative religious attitude about Windows, thus expecting equal functionality and support on Windows is folly. The MsysGit discussion threads reflect a shoestring operation, with overwhelmed developers solely scratching their own itch (fair enough as far as it goes). Whereas hg treats Windows as a first class platform (presumably because it was designed and built with that in mind). I still like git's branching feature (which is why I chose it initially over hg), but between hg and git, hg is IMHO the only pragmatic choice for a "Windows shop".
Most people that use SVN on Windows seem to use TortoiseSVN instead of a command line.
Similarly, most Windows developers that I encounter who run Git just use TortoiseGit. (And TortoiseHg for Mercurial for that matter).
The whole "Git on Windows" issue? Completely overblown.
Similarly, most Windows developers that I encounter who run Git just use TortoiseGit. (And TortoiseHg for Mercurial for that matter).
The whole "Git on Windows" issue? Completely overblown.
Yea, I do think that being written in Python was a big thing. It would be for me, if I were in their place. :)
I think it's called Git Bash. It isn't so bad though, you get some working Unix commands with it. Come to think of it, I think it's better than CMD, to an extent.
I find the way your phrase that question interesting. Git and Mercurial are nearly identical in terms of functionality, to the point that converting back and forth between them is pretty trivial. (Example: here's Git's repository in Mercurial https://mirrors.kilnhg.com/Repo/Mirrors/From-Git/Git)
The only real difference between the two are the ecosystems. Mercurial, being written is Python, is very portable and easily extensible. I feel like, because of that, the tools for Mercurial are better. Git has GitHub, and the incredible open source community they've developed there.
* Note, the rainbow road is due to one of the few differences between Git and Hg: Hg does not allow octopus merges, so the conversion turns them to a sequence of two at a time merges. Also, in the interest of full disclosure, I'm one of the devs on Kiln, so I'm certainly biased towards Hg.
The only real difference between the two are the ecosystems. Mercurial, being written is Python, is very portable and easily extensible. I feel like, because of that, the tools for Mercurial are better. Git has GitHub, and the incredible open source community they've developed there.
* Note, the rainbow road is due to one of the few differences between Git and Hg: Hg does not allow octopus merges, so the conversion turns them to a sequence of two at a time merges. Also, in the interest of full disclosure, I'm one of the devs on Kiln, so I'm certainly biased towards Hg.
octopus merges are rare in the git.git repo:
$ git rev-list --merges --parents --tags | awk '{print (NF-1)}' | sort | uniq -c
4409 2
22 3
5 4
3 5
1 6
On the other hand, roughly an entire 2% of merges on linus's linux tree have been octopus merges. Hardly something to scoff at.
5 10
6 11
5 12
3 13
2 14
1 18
14592 2
1 20
1 21
1 24
129 3
1 30
50 4
25 5
21 6
13 7
18 8
7 9Relative occurence numbers don't say much about the need for octopus. Maybe they're rare but when the need arises it proves to be an invaluable feature.
How many Octocat merges have there been?
Wow! Nice to meet you. I wish my work was as interesting as yours.
See http://www.python.org/dev/peps/pep-0374/ for the rationale; but keep in mind it's more than two years old so some of the criticisms may not longer apply.
Why would Git be any better? They're both tools that ultimately accomplish the same thing.
git rebase -i, git reset --hard, git checkout <any-refspec>
hg histedit, hg revert, hg update -r{any revspec}
I meant "git reset --hard" as a prefix for useful <refspecs>.
Can hg set the current branch to point anywhere in time?
Does histedit do exactly what "rebase" does? Does it also work with "--onto" and other rebase features?
Can hg set the current branch to point anywhere in time?
Does histedit do exactly what "rebase" does? Does it also work with "--onto" and other rebase features?
`histedit` does what `rebase -i` does, `hg rebase` does what `rebase` does.
There are a few limitations to `histedit` compared to `git rebase -i` I think: I believe it's possible to split revisions using `rebase -i`, I don't think that can be done using histedit (it has pick, edit, drop and fold). Histedit also misses the (pretty recent I believe) `exec` action of git's rebase -i.
There are a few limitations to `histedit` compared to `git rebase -i` I think: I believe it's possible to split revisions using `rebase -i`, I don't think that can be done using histedit (it has pick, edit, drop and fold). Histedit also misses the (pretty recent I believe) `exec` action of git's rebase -i.
hg branches are entirely different from git branches, so resetting them in that way doesn't make sense. The closest approximation - bookmarks - can indeed be reset (hg bookmark -f).
histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
Hg seems to have evolved several vaguely similar but isolated optional features (named branches, local branches, bookmarks, patch queues) which I guess means they haven't arrived at one everybody's happy with. Some people even prefer to keep hg branches in cloned repos, which sounds very painful. Git handles all those use cases by binding a ref to a commit and calling it a branch (even stashes are stored as branches, just more difficult to push).
> histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
That is correct. In Mercurial, git's `rebase` is (sensibly, as far as I am concerned) split into two different commands: `histedit` handles the history edition within a branch and `rebase` handles the rebasing of a branch on a revision of an other branch.
That is correct. In Mercurial, git's `rebase` is (sensibly, as far as I am concerned) split into two different commands: `histedit` handles the history edition within a branch and `rebase` handles the rebasing of a branch on a revision of an other branch.
hg: unknown command 'histedit'
If nothing else it's because Mercurial itself is written in Python.
Not true.
While mercurial being written in python is noted[1] , it is made explicitly clear, its not the reason behind the main selection of Hg as the version control.
[1] - http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...
While mercurial being written in python is noted[1] , it is made explicitly clear, its not the reason behind the main selection of Hg as the version control.
[1] - http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...
"First, git's Windows support is the weakest out of the three DVCSs being considered which is unacceptable as Python needs to support development on any platform it runs on."
This is FUD! The support for git on windows is pretty good and there is nothing obstrusive in it. You can use git on Windows fairly well. Sad to see this kind of comment written by smart people.
This is FUD! The support for git on windows is pretty good and there is nothing obstrusive in it. You can use git on Windows fairly well. Sad to see this kind of comment written by smart people.
Git's Windows support is clearly the weakest since it requires either MinGW or Cygwin. The platform itself is unoptimized for native Windows performance. It may not be terrible but it's certainly the weakest of the DVCSs, as they say.
Yes, but when I read the PEP, sounded like this is the biggest motivation to not use Git.
Because... we all know Windows Python users are stylin with the Windows command shell.
I agree with the grandparent, this decision was political.
I agree with the grandparent, this decision was political.
Last time I tried TortoiseGit, adding a file either didn't work or just crashed hard. Mercurial, on the other hand, just got TortoiseHg 2.0, which is a pleasure to work with.
It is true that git works on Windows, but that doesn't mean it works well.
It is true that git works on Windows, but that doesn't mean it works well.
Just curious, have you ever tried GitCheetah?
https://git.wiki.kernel.org/index.php/MSysGit:GitCheetah
I've never experienced the crashes you describe but I've never used Tortoise either. YMMV, I suppose.
I've never experienced the crashes you describe but I've never used Tortoise either. YMMV, I suppose.
"Last-Modified: 2010-01-07 23:33:01 +0100 (Thu, 07 Jan 2010)"
I've been working on a prject last year which involved a few developers using Windows.
It was a nightmare. Myself using Linux, i had no problem.
But git on Windows..
It'd definitely behind other VCS.
[deleted]
makes sense since mercurial is written in python, it's like eating your own dogfood in some senses.
http://mail.python.org/pipermail/python-dev/2009-March/08793...
But I see from http://www.python.org/dev/peps/pep-0385/ that it's taken that long to migrate away from svn.