Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python now uses Mercurial

hg.python.org

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Python now uses Mercurial

#101

Post by prodigal_erik »

elehack wrote: post #77
Peaker wrote: post #59

Earlier quoted context omitted.

I meant "git reset --hard" as a prefix for useful . 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?

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.

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).

Re: Python now uses Mercurial

#102

Post by chousuke »

woogley wrote: post #32
vimalg2 wrote: post #31

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…

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/

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.

Re: Python now uses Mercurial

#103

Post by cageface »

chousuke wrote: post #102
woogley wrote: post #32

Earlier quoted context omitted.

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/

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…

Same. Branches are a dealbreaker.

Re: Python now uses Mercurial

#104

Post by lloeki »

burgerbrain wrote: post #54
js2 wrote: post #44

Earlier quoted context omitted.

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 So there's been a total of 31 octopus merges compared to 4409 typical two-parent merges.

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 9

Relative 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.

Re: Python now uses Mercurial

#105

Post by vimalg2 »

joske2 wrote: post #93
vimalg2 wrote: post #31

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…

Why would you choose Github over Bitbucket for your FOSS projects? I haven't used Bitbucket yet, so I'm interested in a comparison.

Large Hacker userbase.

Re: Python now uses Mercurial

#107

Post by megaman821 »

chousuke wrote: post #102
woogley wrote: post #32

Earlier quoted context omitted.

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/

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…

hg bookmarks are the equivalent of git branches for the most part. Check out those next time you use mercurial.

Re: Python now uses Mercurial

#108

Post by barake »

there wrote: post #34
burgerbrain wrote: post #10

Earlier quoted context omitted.

PHP + ...SVN? Gotta say, they deserve each other.

and OpenCOBOL uses CVS 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.

Re: Python now uses Mercurial

#109

Post by masklinn »

Peaker wrote: post #59
masklinn wrote: post #41

Earlier quoted context omitted.

hg histedit, hg revert, hg update -r{any revspec}

I meant "git reset --hard" as a prefix for useful . 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.

Re: Python now uses Mercurial

#110

Post by masklinn »

elehack wrote: post #77
Peaker wrote: post #59

Earlier quoted context omitted.

I meant "git reset --hard" as a prefix for useful . 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?

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.

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.

Post reply on HN