4 ms·

In what way doesn't hg's branch model compete? Are you going off FUD and "a brief time that [you] experimented with it" or do you have a real example?

cdavid 16y ago
In theory, you can use git's branching model, but in practice, it is preetty horrible in my experience (I have only one year experience with hg, though). The tip thing mentioned by Armin is a big UI wart when using "intree" branches, by which I mean any branching scheme not based on cloning. It is also pretty difficult to name branches in the various commands - as far as I know, you cannot easily diff between two names branches, for example. Nevertheless, I miss index much more than git's branching when using hg at work.
cookiecaper 16y ago
I'm going off of a brief time I experimented with it, I admit that I didn't use hg very long. I may come to like it better or learn more if I use hg for a serious project, though I know of no reason to do so voluntarily other than curiosity and education. The branch model doesn't compete because branches are ingrained, as this article discusses; the changeset always carries the branch name with it. Branches are also ingrained as "long-lived branches" and instead of the mere application of a label to divergent changesets, these branches appear tightly coupled and are meant to be merged and/or closed in the way hg expects. You can only get git-like flexibility such as cherry-picking by making another clone or by installing a variety of extensions. See http://mercurial.selenic.com/wiki/GitConcepts#Branch_model http://mercurial.selenic.com/wiki/GitConcepts#Branch_model , which explains that git-like branches don't have a direct equivalent in Mercurial unless you use the BookmarkExtension to apply names to a changeset; otherwise, you must use hg heads, which doesn't work in quite the same way, at least during my brief experience. On top of this, git is usually faster and usually has much smaller repositories (see https://git.wiki.kernel.org/index.php/GitBenchmarks https://git.wiki.kernel.org/index.php/GitBenchmarks), so I don't see much reason to prefer hg. git integrates fine with Windows if one installs msysgit, which includes a minimalist cygwinish environment and is not at all unreasonable.
- tednaleid 16y ago
  I think that extensions are sort of badly named in mercurial, but you're making them out to be much more difficult to work with/install than they actually are. Mercurial ships with a bunch of features ("extensions") turned off by default so that beginner users aren't confused with stuff before they're ready. Turning the bookmark extension on is as easy as putting "bookmarks=" in your ~/.hgrc file. So the bookmark branching model, which is equivalent to the git branching model and something I use every day, is a built-in part of mercurial. You just have to enable it to work that way. The "transplant" extension (similar to cherry picking in git) also comes with mercurial and is just a one liner in a config file to enable.

cdavid 16y ago

In theory, you can use git's branching model, but in practice, it is preetty horrible in my experience (I have only one year experience with hg, though). The tip thing mentioned by Armin is a big UI wart when using "intree" branches, by which I mean any branching scheme not based on cloning. It is also pretty difficult to name branches in the various commands - as far as I know, you cannot easily diff between two names branches, for example. Nevertheless, I miss index much more than git's branching when using hg at work.

cookiecaper 16y ago

I'm going off of a brief time I experimented with it, I admit that I didn't use hg very long. I may come to like it better or learn more if I use hg for a serious project, though I know of no reason to do so voluntarily other than curiosity and education. The branch model doesn't compete because branches are ingrained, as this article discusses; the changeset always carries the branch name with it. Branches are also ingrained as "long-lived branches" and instead of the mere application of a label to divergent changesets, these branches appear tightly coupled and are meant to be merged and/or closed in the way hg expects. You can only get git-like flexibility such as cherry-picking by making another clone or by installing a variety of extensions. See http://mercurial.selenic.com/wiki/GitConcepts#Branch_model http://mercurial.selenic.com/wiki/GitConcepts#Branch_model , which explains that git-like branches don't have a direct equivalent in Mercurial unless you use the BookmarkExtension to apply names to a changeset; otherwise, you must use hg heads, which doesn't work in quite the same way, at least during my brief experience. On top of this, git is usually faster and usually has much smaller repositories (see https://git.wiki.kernel.org/index.php/GitBenchmarks https://git.wiki.kernel.org/index.php/GitBenchmarks), so I don't see much reason to prefer hg. git integrates fine with Windows if one installs msysgit, which includes a minimalist cygwinish environment and is not at all unreasonable.

tednaleid 16y ago
I think that extensions are sort of badly named in mercurial, but you're making them out to be much more difficult to work with/install than they actually are. Mercurial ships with a bunch of features ("extensions") turned off by default so that beginner users aren't confused with stuff before they're ready. Turning the bookmark extension on is as easy as putting "bookmarks=" in your ~/.hgrc file. So the bookmark branching model, which is equivalent to the git branching model and something I use every day, is a built-in part of mercurial. You just have to enable it to work that way. The "transplant" extension (similar to cherry picking in git) also comes with mercurial and is just a one liner in a config file to enable.