Managing source code with Mercurial (developerWorks)
Mercurial's revert, backout, and rollback commands make it easy to return to previous versions of specific files or previous sets of committed changes. Git provides a single built-in revert command with its typical rocket-scientist-only syntax."
Posted Apr 20, 2011 13:56 UTC (Wed)
by robinst (guest, #61173)
[Link] (36 responses)
"Multiple, built-in undo operations": Git has just different command names here, it's not really all in "git revert". hg revert == git checkout, hg backout == git revert, hg rollback == git reset (or just ammend the commit, which you can't easily do in hg).
"History preservation during copy/move operations": Git just figures out the copies/renames when it needs it (e.g. log) and it's not required to use special "copy" commands to do that as in hg.
"Branches": That's actually an advantage of Git, that you can have local branches.
"Automatic repository packing": gc is done automatically when it's needed, so this point is moot as well.
Posted Apr 20, 2011 14:06 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (29 responses)
I agree. Explicitly tracking copies/renames means missing rm/add of a file in different places.
> "Branches": That's actually an advantage of Git, that you can have local branches.
I've been led to believe that what Mercurial labels as a "branch" is not what git labels as a branch. This[1] is an article which explains on developer's experiences with the differences fairly well. Compare git's branches to Mercurial's heads. Mercurial's branches would be, in git, more akin to some tool which managed a set of branches based on the history.
Posted Apr 20, 2011 14:54 UTC (Wed)
by nye (guest, #51576)
[Link] (25 responses)
Can anybody explain to this git user what the author actually means when he says 'family'?
Having no experience with Mercurial I think I may lack the concept required to understand what he's describing, so the article doesn't make much sense to me.
Posted Apr 20, 2011 15:50 UTC (Wed)
by jbardin (guest, #54917)
[Link] (24 responses)
What he's calling a family (a mercurial branch), may contain multiple paths through it's graph. Whereas a git branch is a single linear set of changes. I think it's laid out well if you take what it says when he defines his terms "lineage" and "family" literally. He didn't want to use the term "branch" for both, because a mercurial branch contains more information, and that was one of the main points he was making.
Posted Apr 20, 2011 16:19 UTC (Wed)
by nye (guest, #51576)
[Link] (23 responses)
I'm afraid I still don't understand what this means (I was being serious when I said I don't think I have the necessary concept).
Obviously a commit can have multiple parents (if it's a merge), so there can be multiple paths from root to leaf, but I'm pretty sure that's not what you mean since it's true for git...
Posted Apr 20, 2011 16:38 UTC (Wed)
by robinst (guest, #61173)
[Link] (22 responses)
To get to that information in Git, you have to analyze by what ref the commit is reachable. And if you deleted the feature-x branch sometime (because you merged it), you would only see that the commit is on master. If you then analyzed the path to the commit you would either find the merge commit ("Merge branch 'feature-x'") or no traces of its origin if it was merged using rebase and a fast-forward merge.
Posted Apr 20, 2011 17:07 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (8 responses)
Posted Apr 20, 2011 17:26 UTC (Wed)
by rvfh (guest, #31018)
[Link] (1 responses)
Would be useful also to find out what branch a commit is on _right_ _now_, when only given 7 hexa chars!
Posted Apr 20, 2011 17:33 UTC (Wed)
by robinst (guest, #61173)
[Link]
Posted Apr 21, 2011 17:03 UTC (Thu)
by vonbrand (guest, #4458)
[Link] (4 responses)
This "the patch has done on branch XYZ" doesn't make any sense in git, which doesn't track patches but contents. Yes, it would be useful for archaeology's sake to know that, just as it could be useful to know if the content that disappeared from file X and showed up in file Y was due to moving and editing, or removing and recreating. The costs of wiring this determination into the moment the change is recorded are too high for my taste.
Posted Apr 21, 2011 18:33 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
While git doesn't *track* anything other than content, it does store some other things; everything in a commit aside from the tree sha1 is metadata. (It isn't *tracking* it in the sense that the metadata can't change, while the point of storing all of the different trees is that the content is different in different commits.) It would be foolish to say, 'This "the commit was written/committed/signed-off by user on date" doesn't make any sense in git, which doesn't track patches but contents', and it's just as well-defined to collect and store the value of "branch.<x>.target" for refs/heads/<x> being the ref that the commit operation updates.
Posted Apr 21, 2011 20:02 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (2 responses)
What is the difference between "archaeology" and "history" in this case?
> The costs of wiring this determination into the moment the change is recorded are too high for my taste.
How is this costly? (did you ever taste these costs?)
Posted Apr 21, 2011 20:42 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
- I rebase, squashing two commits together. What is the label for this new commit in the general case? Is it rewritten? (I believe authorship is rewritten on a squash, so this might be the model to follow)
One could develop hooks that enforce branch names are unique over a set of repositories and I am unsure of how much workflows would be affected by the restrictions that would need to be placed on things. If you can't rename branches, what do you do when a developer is added to the set of "unique branch repositories" which has a branch which doesn't match the branch in the canonical set with the same name?
I think a lot of issues pop up because git is a *content* tracker, not a *patch* tracker. Without some ruleset (which would be the cost of adopting such a feature), tools which implement something like hg's branches will have hard corner cases which may just end up being failure cases. Whether those rules are acceptable or not would have to be seen.
Posted Apr 21, 2011 21:34 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
I think you see issues only because you try to hard. I understand the original suggestion as a purely informative, free form field pre-filled with the current branch name. So it does not need to be unique or "correct" in any way.
> - I rebase, squashing two commits together. What is the label for this new commit in the general case? Is it rewritten? (I believe authorship is rewritten on a squash, so this might be the model to follow)
So you just answer this question yourself, thanks! When you squash a large number of things are rewritten. This branch field would just be one of them.
> - I rename a branch. Do I rewrite all branch tags?
I would say no. Some people could say yes. Does it really matter?
> If I don't rewrite it, the tags are now invalid since the branch no longer exists.
Please define "valid" and why some rule is required.
> What if the tag doesn't match the original branch name?
Nothing?
> - When working on a team where each developer has their own repository, I pull non-origin branches with a prefix indicating who I pulled it from (e.g., gh/foobar is the remote repository of user foobar on github; I name my local branch foobar/some-branch-name). Do I use my name-prefixed branch name for the label or the remote branch name?
It would be nice to be able to choose between the basename or the fullname in git config.
> One could develop hooks that enforce branch names are unique over a set of repositories and I am unsure of how much workflows would be affected by the restrictions that would need to be placed on things.
Or rather: one could avoid developing any such hooks and not invent any problem related to them.
> Without some ruleset (which would be the cost of adopting such a feature), tools which implement something like hg's branches will have hard corner cases which may just end up being failure cases. Whether those rules are acceptable or not would have to be seen.
I do not think any rules or tools are needed for a free-form field.
Posted Apr 23, 2011 19:40 UTC (Sat)
by jthill (subscriber, #56558)
[Link]
Posted Apr 20, 2011 20:16 UTC (Wed)
by jengelh (subscriber, #33263)
[Link]
Posted Apr 21, 2011 12:40 UTC (Thu)
by nye (guest, #51576)
[Link] (11 responses)
That makes it a lot clearer, thanks.
Posted Apr 21, 2011 19:50 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (10 responses)
I create a private branch, let's called "branch/feature". I then merge this branch into my "main", before committing it to upstream main.
As far as the public history is concerned, this feature has only ever existed in "main". Any reference to "branch/feature" would refer to a transient entity that only ever existed on my machine - and has a good chance of colliding with an identically-named private branch on someone else's machine. Think NAT IP addresses - your address is meaningless in a global context.
Cheers,
Posted Apr 21, 2011 20:13 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (9 responses)
What "others" have said seems to be just the usual "I do not need this feature, so you do not need it either"
> As far as the public history is concerned, this feature has only ever existed in "main".
I am confused: which "main"? How is it any different from "feature"?
> Any reference to "branch/feature" would refer to a transient entity that only ever existed on my machine and has a good chance of colliding with an identically-named private branch on someone else's machine.
So what? I am still interested in the branch name you used when you were working on that commit. It is very likely to be an excellent and short description of what you had in mind at the time.
Posted Apr 21, 2011 21:53 UTC (Thu)
by BenHutchings (subscriber, #37955)
[Link]
It is kind of an anti-feature, because Mercurial relies on these embedded branch names rather than on history:
Posted Apr 22, 2011 22:13 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
Chances are it would appear as a bunch of commits, not just one, but I could squash it all into just one commit before sending it public.
I do take your point about you wanting to know, but the fact remains, what you are after is (from git's point of view, not necessarily yours) meaningless info. As such, it belongs in the commit message and, from what I've seen, it would be pretty trivial to add if someone could be bothered.
Cheers,
Posted Apr 26, 2011 9:47 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (1 responses)
OK, but git could help by better supporting metadata.
> As such, it belongs in the commit message and, from what I've seen, it would be pretty trivial to add if someone could be bothered.
Asking every developer to manually insert the branch name "somewhere" in the commit message is not reliable enough. It is also too difficult for scripts or viewers to parse.
I think what is needed is support for semi-structured data akin to extended attributes (xattr) or SVN properties.
Git would just carry these properties and not care about their content. It would make the job of commit hooks and third party extensions one order of magnitude easier. History rewriting like rebase and squash would preserve them on a "best effort" basis. User interfaces to rebase and squash could help. Otherwise a "reasonable default" would apply; for instance "newer wins". It would notably help gateways between git and other systems.
This would solve problems like this one:
Posted May 11, 2011 11:17 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Apr 23, 2011 3:50 UTC (Sat)
by vonbrand (guest, #4458)
[Link] (4 responses)
The idea of globally relevant branch names (in git terminology) is fundamentally at odds with a truly distributed VCS.
AFAIU, "main" is the master branch in the upstream repository, "feature" is just a throwaway branch for trying out a feature in my downstream repository. Throwaway branches should have throwaway names. If the project has the policy of recording in the commit message what the patch is all about, it can enforce that. Having the tool record information makes it relevant, and thus constrains the developer. "Can't name the branch try22, because the name will get into the upstream repo." "Can't rename branches." "Can't have a catchall branch for random experiments/fixes." "No decent way to cherry pick changes from all over the place and consolidate in a branch for publication." Too expensive for me.
Posted Apr 23, 2011 6:11 UTC (Sat)
by criswell (guest, #40091)
[Link] (3 responses)
And there are those of us who completely disagree that named branches have no place in a truly distributed VCS. There are those of us who not only have found uses for them, but also found them at times to be terribly important (for example, on a recent internal, closed-source project I did while on contract we had a very specific need to have multiple named branches that *each* developer had easy access to all stored in the same repository).
The big problem here that people who are so interested in starting up flame-wars don't seem to get is that git was something that was designed around a *highly* specific development methodology (the way the kernel developers work). There, things like named branches do NOT make sense (and other things, like rebase, are of the utmost importance).
Meanwhile, you have other tools like hg which arose out of different needs altogether, and were designed to satisfy completely different sets of problems.
Just because *you* may not see the need for a particular "feature" of one DVCS it's no reason to knock it. Both are equally valid, and both have their uses.
Everything else is just idiotic flame-wars (which, are nothing new, obviously, to the FOSS world).
Posted Apr 23, 2011 12:20 UTC (Sat)
by vonbrand (guest, #4458)
[Link]
If you have a need of sychronizing branch names, you can do so. That is different from being forced to do it by the tool, or being constrained in branch names, or being unable to create/rename/remove at will.
Posted Apr 23, 2011 16:32 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
If you need a global named branch, then you put it into your master repository. There's nothing to say that you can't have them. But private branches are NORMAL, and it doesn't make sense to put a private branch name into the global repository where that branch never existed.
The point about git is that it is TRULY distributed, and the master only exists BY CONSENSUS. And if you have a master repository, then every branch on that repository is available to every developer.
Let me ask you this - how on earth do you think you are going to create a truly global branch, when you don't have write access to my machine?
From what I've picked up about hg, it is very difficult NOT to synchronise your repository with upstream. You create a branch, it will sync with upstream, I will sync with upstream, and your branch will appear on my system. What you want makes sense in hg.
But in git, THERE IS NO UPSTREAM except by convention. And I have to sync EVERY BRANCH OF INTEREST MANUALLY. (I could automate it ...) If you haven't pushed your private branch (or given me read access to your machine) I can't even access that branch!
And the normal way of programming with git is to create a branch for every tiny little feature, test it, merge it into local main, then push it up to central main - or as in my case, send a patch from my feature branch for merging into main and then pulling back down again.
Global branches for private development just doesn't make sense, and that's the way git works.
Cheers,
Posted Apr 26, 2011 8:43 UTC (Tue)
by cmccabe (guest, #60281)
[Link]
In a truly distributed VCS, branch names are a local thing. Why should anyone else care what your branches are called, unless you publish them? And if you do publish them, assuming you have a central server, all the developers will be able to see them.
mercurial may well be very suitable for your small closed-source team. perforce might work pretty well too! But what does that have to do with the issue we are discussing?
Some people use git the way the kernel developers do. Other people use it more the way Google does, often in conjunction with tools like Gerrit. Your argument that "well, I'm not a kernel developer, therefore git is not useful to me" is very silly.
There are a few things that git can't do well, like storing large binary files. But mercurial can't do that well either.
Posted Apr 20, 2011 15:59 UTC (Wed)
by robinst (guest, #61173)
[Link] (2 responses)
Yes, but having local-only Mercurial heads (git branches) is really difficult, because they get pushed by default. I heard that the bookmark extension provides support for local branches.
So, all in all, in Mercurial, there are branches, named branches and bookmarks. To me, the way it's done in Git is much easier and cleaner.
Posted Apr 20, 2011 16:09 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 20, 2011 17:28 UTC (Wed)
by JohnLenz (guest, #42089)
[Link]
Just a note about bookmarks, they are no longer an extension. In version 1.8, bookmarks became part of core mercurial. With bookmarks becoming a core feature, I think the way mercurial does it works well with the distinction between bookmarks and named branches.
Posted Apr 20, 2011 17:42 UTC (Wed)
by PO8 (guest, #41661)
[Link] (4 responses)
I consider it a misfeature of git that on one hand it provides "git mv" and "git cp" but on the other hand they don't really do what they say they do. For example, use "git mv" to rename a file and also edit it extensively (say, put a comment character in front of all but a couple of lines). When you commit, you will find that git thinks you deleted the old file and created a new file. This is really annoying---you *told* it what happened, but it neither recorded that information nor payed attention to it. Your history is now slightly broken.
IMHO it would be really nice if using the "git mv", "git cp" and "git rm" commands resulted in the state being tracked the way I said it was, including recording this information in the repo. Heuristics are great, but when they disagree with explicitly-provided information, the latter should always win. An easier-to-implement alternative would just be to git rid of the above-mentioned git commands altogether, although that would mean that you would sometimes have to explicitly "git add" a file after a move or copy if the contents also changed enough to confuse the heuristic.
Posted Apr 20, 2011 18:04 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
[1]http://permalink.gmane.org/gmane.comp.version-control.git...
Posted Apr 21, 2011 21:55 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
Sounds great!
Now, if renames are indeed such a degenerated case which is always trivially solved, how come people keep complaining that their renames are not systematically found? When you dismiss help with a "I am much clever than that" argument, then you are not allowed to fail.
The other argument in the post is "files do not matter". Well, you wish. Files matter to compilers and a huge number of other tools. As a consequence, developers unfortunately have to care about files.
Posted Apr 22, 2011 9:37 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 21, 2011 18:03 UTC (Thu)
by chad.netzer (subscriber, #4257)
[Link]
For better or worse, the simple answer is don't do that, it's usually bad practice. The staging area can help here, if you forget to commit the rename before editing the file.
That said, I understand the people who don't like this feature, as Git does tend to enforce a different way of thinking than some other systems. But, since the idea from conception was to track content (not files), it's doing exactly what you'd expect. Those lines in 'a' did *not* move to a new file in a single commit, they were deleted from a, and a new file b got some new but mostly different content. So at least git is doing what it intended to do, and what some developers actually *want* to do, the debate then is whether that approach is preferable or not. By not explicitly tracking renames, git more easily allows content to enter the repo from sources that also don't do this tracking (ie. emailed patches), which is a feature.
Meanwhile, if you prefer to rename and edit content in one commit, you can control the "similarity index" (ie. "git log --summary -M30%") for detecting renames. So like most good heuristics, at least its tunable. :)
It'd be nice to have semantic tracking of content, not just line-by-line textual tracking. If git was smart enough to know that the changes you made to those lines were just commenting them out, it could then optionally factor that into it's similarity computation, and thus figure out that the file was renamed with some semantically related content modified. I think it can do this already with whitespace changes.
Posted Apr 22, 2011 12:20 UTC (Fri)
by Cato (guest, #7643)
[Link]
See http://hgtip.com/tips/advanced/2009-09-30-detecting-renam...
Posted Apr 20, 2011 15:08 UTC (Wed)
by eMBee (guest, #70889)
[Link] (5 responses)
the mercurial site has a nice table of command equivalents
greetings, eMBee.
Posted Apr 20, 2011 17:24 UTC (Wed)
by JohnLenz (guest, #42089)
[Link] (4 responses)
i am just starting to learn mercurial, after having used git for a long time. for the basic operations i find it not much different, but i doubt claims that mercurial is any easier. Having used both Mercurial and Git, for developers you are mostly correct, they both are about the same difficulty. But I have attempted to introduce version control to non-programmers (mainly math people to version a shared paper), and when I attempted to introduce them to git they had no clue what was happening and would shoot themselves in the foot constantly. When I tried introducing them to mercurial, they all seemed to get it. I have no idea why, and this is just an anecdote, but my experience is that for programmers mercurial and git are just as easy to understand but for some reason non-programmers can approach mercurial better. If I had to guess, it is because you can get started with mercurial using fewer commands and gradually work your way up to the more complicated commands. most mercurial commands listed are more complex than the git equivalents. from those commands that i use in git on a regular basis, 6 require an extension for mercurial, making me depend on that extension being available on whatever machine i end up working. Huh? When I look at the table, the commands look basically the same. The only one that is bad is log versus describe, but I don't know why they try and list the equivalent there. Just use hg log, the default template is just fine. For the extensions, most of the extensions from that table are included and distributed with mercuail, so they will always be there on every mercurial install. For the others, you can install extensions locally with easy_install, so even if you are on a computer without root, you can still install extensions.
Posted Apr 20, 2011 18:39 UTC (Wed)
by eMBee (guest, #70889)
[Link] (2 responses)
as for the comparison of commands, you are right, most are similar, and either hg or git version is slightly more complex (by requiring an extra argument) but then look at git commit --amend, git describe and git show, which all have incredibly complex solutions in hg, and that is significant when i use git commit --amend and git show almost daily.
greetings, eMBee.
Posted Apr 22, 2011 4:37 UTC (Fri)
by lindahl (guest, #15266)
[Link] (1 responses)
Posted May 2, 2011 16:21 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
Posted Apr 20, 2011 20:53 UTC (Wed)
by PhracturedBlue (subscriber, #4193)
[Link]
Posted Apr 20, 2011 15:25 UTC (Wed)
by bjacob (guest, #58566)
[Link] (7 responses)
Real advantages of Mercurial over Git include, depending on your use cases and target audience:
Posted Apr 20, 2011 16:12 UTC (Wed)
by robinst (guest, #61173)
[Link] (3 responses)
By the way, one of the little things that is seldom mentioned, but matters to me, is that Mercurial doesn't differentiate between committer and author of changes.
Posted Apr 20, 2011 19:17 UTC (Wed)
by eean (subscriber, #50420)
[Link] (1 responses)
Posted Apr 24, 2011 17:42 UTC (Sun)
by robla (subscriber, #424)
[Link]
By that reasoning, I think I'm almost perfectly qualified to comment, and I agree with you. I was a Subversion user who briefly dabbled with Git, but found the command syntax was too headspace-incompatible with Subversion for me to get my head around at first (given how little time I had to focus on learning). I then learned Mercurial, which ended up being good training wheels for learning DVCS concepts. Mercurial is far, far easier to use for anyone who is currently a Subversion or CVS user. What little dabbling I did with Git might have spoiled me for becoming a permanent Mercurial user, though that isn't what caused me to eventually switch. While I found Mercurial's syntax far easier to understand, and appreciate much about Mercurial's approach, I found myself getting frustrated with all of the Mercurial extensions needed for Git parity (many of which were of uneven quality at the time). I hadn't used Git enough to get as frustrated as the parent commenter and seriously consider switching, but I could definitely empathize. I was eventually won over to Git by Gary Bernhardt's "Why I Switched to Git From Mercurial". Prior to reading that, I was confident that the Mercurial developers would sort out the annoyances. Since Gary was someone who had taught me a couple of important Mercurial tricks (and is clearly a pretty smart guy), seeing him switch was the point at which I finally relented. I can't say that I'm a Git pro (or that I use Git enough yet to really count as a serious user), but it'll be pretty difficult to convince me to go back to Mercurial.
Posted Apr 30, 2011 11:15 UTC (Sat)
by oak (guest, #2786)
[Link]
Why that's a problem? You only need to do it once, and it requires just adding a single line ("rebase =") per extension to your "[extensions]" section in .hgrc file.
Posted Apr 20, 2011 21:10 UTC (Wed)
by robert_s (subscriber, #42402)
[Link] (2 responses)
I have found this to be a golden feature. If you're working on a python project, being able to introspect into the version control system in an incredibly robust and simple way is a great asset.
(Yes, I realize this is only applicable to python programmers and it could be thought of as a bad idea from a design point of view - but it's very useful to, e.g., give your backup code the ability to tag backups with the version of code that made them.)
Posted Apr 26, 2011 21:07 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (1 responses)
Misinformation
Misinformation
Misinformation
Misinformation
Misinformation
Misinformation
Misinformation
Missing the branch info
Missing the branch info
Misinformation
Misinformation
Misinformation
Misinformation
- I rename a branch. Do I rewrite all branch tags? If I don't rewrite it, the tags are now invalid since the branch no longer exists. What if the tag doesn't match the original branch name?
- When working on a team where each developer has their own repository, I pull non-origin branches with a prefix indicating who I pulled it from (e.g., gh/foobar is the remote repository of user foobar on github; I name my local branch foobar/some-branch-name). Do I use my name-prefixed branch name for the label or the remote branch name?
Misinformation
If you tag -a the first commit on a git branch, you've got the functional equivalent of an hg branch. Have the prepare-commit-msg hook add the tag data on new commits, collect them for merge commits etc, and then every commit references whatever administrative line-items cover the work.
Misinformation
Misinformation
Misinformation
Misinformation
Wol
Misinformation
Misinformation
What "others" have said seems to be just the usual "I do not need this feature, so you do not need it either"
Misinformation
Wol
Misinformation
http://svnbook.red-bean.com/en/1.5/svn.advanced.props.html
Please tame your instincts and do not reject this only because it comes from Subversion :-) I find that most of this page would apply well to git.
https://mail.gna.org/public/stgit-users/2011-01/msg00008....
Misinformation
Misinformation
> Which as others have said, doesn't make sense in git.
What "others" have said seems to be just the usual "I do not need this feature, so you do not need it either"
> As far as the public history is concerned, this feature has only ever existed in "main".
I am confused: which "main"? How is it any different from "feature"?
> Any reference to "branch/feature" would refer to a transient entity that only ever existed on my machine and has a good chance of colliding with an identically-named private branch on someone else's machine.
So what? I am still interested in the branch name you used when you were working on that commit. It is very likely to be an excellent and short description of what you had in mind at the time.
Misinformation
Misinformation
Misinformation
Wol
Misinformation
> no place in a truly distributed VCS. There are those of us who not only
> have found uses for them, but also found them at times to be terribly
> important (for example, on a recent internal, closed-source project I did
> while on contract we had a very specific need to have multiple named
> branches that *each* developer had easy access to all stored in the same
> repository).
Misinformation
Misinformation
Misinformation
Misinformation
Misinformation
Misinformation
At a guess, because they are expecting the tool to detect "I renamed this file and rewrote half of it, but didn't do separate commits for the rename and the rewrite" as a rename.
Misinformation
Misinformation
Misinformation
Managing source code with Mercurial (developerWorks)
http://mercurial.selenic.com/wiki/GitConcepts#Command_equ...
and that table alone belies any claims of mercurial being easier. most mercurial commands listed are more complex than the git equivalents. from those commands that i use in git on a regular basis, 6 require an extension for mercurial, making me depend on that extension being available on whatever machine i end up working.
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)
it's gonna take a while until i have memorized hg log -r rev -p, and i don't even want to think about the hoops i'll have to jump through if i ever want to change a commit.
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)
Again, it is only anecdotal, but that is my experience.
Managing source code with Mercurial (developerWorks)
1) hackability --- since it's almost all python, writing Mercurial extensions is very easy, and there are lots of them.
2) simple by default --- many important Git concepts such as the staging area are either not present or not exposed by default by Mercurial. The result is a simpler SCM system, that is easier to understand and harder to do stupid things with. This is of course a trade-off (simplicity/safety vs power).
3) Mercurial Queues --- I know that Git has many patch workflow options of its own, but MQ just works well for me. YMMV. Combined with the Crecord/QCrecord extension, this is a very powerful tool to manipulate patches.
Managing source code with Mercurial (developerWorks)
2) My experience was just the opposite. When I used it, I needed to have many extensions enabled just to make work with it bearable: rebase, purge, record, transplant.
3) I never really got into mq. With Git it's just a matter of branching, interactive rebase and interactive add. I don't really get why it has to be separate in Mercurial (may be the same reason that you can't rollback two commits).
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)
Managing source code with Mercurial (developerWorks)