* Git octopus merges
* Mercurial descriptions that are not UTF-8
* Git commits whose messages aren't in their nominal encoding
* Mercurial and Git having invalid timestamps
* Git having a different author from committer
* Git and Mercurial commits and changesets with extra metadata
* Mercurial usernames that are not valid Git usernames
* Mercurial bookmarks that are not valid Git refs
* Mercurial named branches
* Git annotated tags (requires an not-quite-yet-released extension to fully round-trip; the non-annotated part of the tag works today and will be forwards-compatible)
* Mercurial changesets/manifests/filelogs with bad parent data
* Git trees that are just flat-up invalid
* Subrepos and submodules (100% preservation, but we can only
translate Git submodules/subrepos cleanly to/from each other,
since Git submodules have to be Git)
Anyone intelligent enough to use git or hg should be pragmatic enough to learn the other one for the benefit of the smooth workflow, when presented with this list ?
"Git master branch in sync with the Mercurial repository’s tip transparently. So far, so good."
Did you mean "default" instead of "tip"?
(This is hard to handle for normal git users as well, but it can be nice in some edge cases)
- How do I do blah? - Well, you type hg blah-blah - What's hg?
- I fixed this bug on master - Where? - Oh, are you using mercurial? It's called a tip in your world
IMHO this stuff alone makes using two almost identical but different version control systems within a team a bad idea. Then there's that another layer that is supposed to work transparently, but when you have a problem you're never quite sure... is there a bug in hg? git? kiln?..
Really, just pick one system and use it. (hint - pick git :)
The only things I need to know are how to check out code, check in code, label and branch. Occasionally I create a repository. Rarely.
If you gave me a GUI that just had those four functions, I wouldn't give a rat's ass what VCS was living under the hood.
If you need to branch, you also need to know how to merge. Then you'll need to know how to resolve conflicts. You probably need to know what branches are there and how to diff them. And since you know how to check in, it's just a matter of time before you'll need to know how to revert. That's just you alone - once you collaborate with someone else, you'll need to learn how to share code, push, pull, remote branches... There's a reason why your VCS has more than four commands.
"Ohhh, you know hg, great! Lets get started, so our workflow consists of ... 35 minute explanation of 28 community plugins and 4 custom corporate ones".
Just use Git. Or Mercurial. It doesn't matter. They are just about the same and the minor improvement you might get from one over the other is just not worth the effort of thinking about it. Now go do something more useful with the cycles you save.
In summary: anyone who has a pressing need for this product has their priorities wrong.
I feel like GitHub has done the same thing for Git. Mercurial is in Python, which in theory would make it easier for me to hack on if I ever needed to, but the community has settled on Git. I think the fact that Atlassian bought BitBucket, which was a boutique version control tool for Pythonistas, and the very first thing they did was add Git support and position it as an alternative to GitHub speaks volumes to this.
I know that there are people who prefer Mercurial, and I'm glad they have that choice, but I feel like choosing Mercurial over Git for a new project is swimming upstream without any real benefit.
Exactly! That's the whole point of Kiln Harmony. Use whatever you want, and let the rest of your team and company do the same.
Allowing developers to use the tools they want to use and the ones that allow them to work the fastest should be your highest priority.
That's just silly. Both Git and Mercurial take a fair amount of effort to learn to use fluently, and if someone is already an expert in one, they are likely to feel that being forced to learn something else that's completely different and yet exactly the same will take a lot of useless effort and distract them from more important things. Something that solves this problem and lets programmers focus on their real work is certainly useful!
I imagine that understanding how this tool deals with whatever the idiosyncrasies are between the two systems would be higher friction in the long run than just reading the mercurial manual.
Most of the tools out there in DCVS land seem to have as a prerequisite that you already know how to do it the hard way. If I've already climbed the learning curve for the hard, but powerful, way I'm probably just going to keep doing it that way.
The opportunity is for a tool that makes easy things easy. I signed up for the SourceTree Windows beta, hopefully that's it.
I think the religious war is already over, and Git won. The only time I hear about Mercurial is when Fog Creek talks about it; approximately everyone else is on Github.
(Update: For the record, I don't think Git winning this war was due to it being technically superior in any significant way -- but neither is Mercurial superior enough to make it worth teaching everyone how to use two different DVCSes. Git was good enough, and then it won the mindshare war, and now it's the standard.)
Any tips for someone still fighting resistance to move to a DCVS?
And this is how Fog Creek adapts to that reality without alienating their existing customers. They were headed directly at a tar pit. This this is the step sideways which will allow them to continue moving forward.
git 208M
git revision 6M
git version 56M
git control 19M
mercurial 29.5M
mercurial revision 1M
mercurial version 7M
mercurial control 6M
http://www.google.com/trends/explore#q=git%20repository%2C%2...
update:
hg revision 5M
hg version 55.5M
hg control 63.M
hg OR mercurial revision 6M
hg OR mercurial version 70.5M
hg OR mercurial control 74M
Joel Spolsky's live demo of FogBugz & Kiln is the single best product demo I've ever seen. Ever. It's so good, anyone doing demos should watch it, just because.
http://www.fogcreek.com/fogbugz/
(just the video) http://fogcreek.wistia.com/medias/z6o7hhvio5
I don't know if I care about evidence based estimating. And I'm pretty sure FogBugz is overkill for my team's needs. And I'd rather eat glass that do anything Windows.
But hot damn the (apparent) integration and workflow of these two products are quite polished. Very well thought out and very well executed.
Joel explains it better than I can: http://www.joelonsoftware.com/items/2013/03/11.html
Now, I recognize that much code written in a "business environment" does indeed ship without review. I just don't think that's a good thing.
If what you're saying is that you've yanked code review tools because customers don't want them, my only reply is that I'm afraid I'm unlikely to be a customer.
If you want to compete with BitBucket and GitHub, you guys might want to feature the startup plan more prominently on your pricing page. The mention of it is so far below the fold that I didn't even see it on my tablet.
(If you are primarily focused on enterprise, that's cool too. I just feel like the mindshare for DVCS is trapped in the more community-centric players.)
...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages (yeah, they make sense after you dive into the docs to search for the thing mentioned in the message or you google for it, but that's not how it should be) ...and for anything more complicated you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho ...it's a great tool but at the same time utterly nightmarish if you stop to think about it instead if just using it on auto-pilot
Actually, I think you are perfectly wrong about that "sin". You just hit upon the exact reason why Git is good.
Git's point is that the data model is the tool. There is no abstraction (or at least very few), because it would only serve to camouflage what is important about it. It's just a data model and tools to manipulate it.
The way to explain Git is to start with the database: blobs, commits, references, and so on. The neat thing is that the way Git implements version control -- that is, linear version control (there are exceptions, like Darcs) -- is how version control must necessarily work.
In other words, if you understand Git, you understand how version control, and vice versa.
Of course you can have a VCS that is a completely black box. But even a black box needs a sort of public data model that the user understands ("files", "versions", "branches"), and I think Git's transparent, open-engine-approach is better than any other approach so far. For one, it makes it really extensible.
(I used to be a Darcs user, which requires that you become a quantum phycisist to understand its data model. I loved Darcs, but it meant that it broke, and it often did, it was almost impossible to fix the problem by hand.)
Now, I absolutely admit that Git's UI is terrible. It's geared towards hard-core developers who work on things like the Linux kernel. There little middle ground between the easy and the hard, and the learning curve is steep. But this is the fault of the command-line tools, and my thesis applies regardless of the UI.
Git has gotten better over the years. Just the fact that a newly created branch now has a default origin branch (so you don't have to set up the two .gitconfig keys you would need manually) is an amazing usability improvement that should have existed from the start.
I would call myself a power user - I am the clearcase->hg transition guy in what I do, I've designed/maintained an enterprise hg extension (guestrepos, look 'em up, they are amazing), use mq, etc. But I think that the fundamental win for git is that they don't abstract, and this allows clearer understanding of what is happening when things go pear-shaped.
But, that's my opinion. I use both on a daily basis.
We discussed this a bit on the last mercurial sprint.
In jest, someone said that a lot of git users have what they'd call a "Helsinki syndrome". Probably that is not very far from the mark.
I think that what git brings in functionality is good enough (specially compared to non DVCSs) to make people want to use it and put the effort to understand it. On the other hand it is hard enough to use that when people finally manage to wrap their heads around it they are so proud that they must tell everybody about it.
It is actually quite brilliant if you think about it: Make a SW that does something really well, better than most other similar tools, but wrap it in a horrible UI to keep your users on their toes and make them proud that they are able to use it! This starts an incredible self-congratulatory feedback effect which gives notoriety to your tool.
If you add to that the fact that git was created by one of the most famous hackers of all time, plus the creation of GitHub, and then you get the perfect storm to make git the open-source tool of choice.
Mercurial on the other hand is just as useful (if not more) than git, but it is just not as hard to use. People use it, like it, but they do not need to feel proud about it. It is just easy. There is no need to talk about database details, reflogs, etc. There is no need to blog about it. It just works. This should be great and make mercurial the better tool but it has the perverse effect of not making it cool to talk about it. There is no challenge, there is no achievement in learning how to use mercurial. This makes it hard to get the same sort of buzz that you get from a tool such as git.
In my opinion it is a little surprising that such a knowledgeable bunch such as the Hacker News readers and the open source contributors in general are not able to evaluate both tools just in their technical merits and instead follow the buzz. Understandable, but surprising nonetheless.
If a tool makes you productive, you make the effort to look beyond its flaws.
Windows and git are just two examples.
> why tf did Git win at this?
https://en.wikipedia.org/wiki/Comparison_of_revision_control...
One thing they don't mention is "octopus merges" - Git allows a merge to have more than two parents, while Mercurial does not. I'm sure there are other tiny edge cases, too; I wonder how they handle those?
Perhaps more to the point, I'm concerned that this means you're stuck using the lowest common denominator of both systems - for example, no hg bigfiles stuff.
Git octopus merges of N parents are exploded into N-1 commits, each of which has some Harmony-specific metadata in its changeset extras field. We then use this data both to reassemble the octopus merge, and to prevent you pushing a changeset that has one of the "fake" octopus merges as a parent.
I respect fogcreek and avidly read everything Joel wrote at the turn of the century. But I had a years free kiln hosting that I must have used twice after setup and I just found GitHub so much cleaner and, well, it worked with git.
Being quiet for a year is not the sign of excellent planning and product management either - if they had this great plan 12 mths ago and knew it would take this long then go do it fine, but hire some oter guys to keep inching the rest of the product along - 12 mths is just dead. I am guessing they realised they had backed the wrong horse and tried to make a compatible product - when really just cloning GitHub and aiming at Joel's core sme market would work.
Edit Should not be knocking the technical effort and work here - just the strategy...
It's a situation I imagine a lot of development agencies find themselves in.
I prefer git, but my team opted for mercurial. Now(since we use kiln) I get to use git and my teammates can continue to use merc.
And the (admittedly slight) gains in productivity for some of your developers is a nice bonus.
For my home projects, I used Mercurial for a year since I preferred its command-line tools to Git. When workable GUI tools for Git appeared (starting with Github for Windows), I migrated to Git.
Also, a small bravo to Fogcreek for using a screen grab from Windows. Windows is so uncool that we need some Windows screen shot affirmative action.
For business group A, I use RCS. For business group B, I use SVN. For my own personal stuff I use git.
No joke.
Mercurial, Perforce, Clearcase are also in use depending who you ask. I'm sure we have some CVS still in use somewhere, and I think Bazaar may be installed, though I don't know who uses it. Basically if it exists, we have it installed, and someone might be using it, somewhere among the order of 100k employees worldwide.
Thanks for clearing it up.
(Please wait a couple of mins before replying while I don my flame-retardant suit ;)
This is crucial: it; s hard to sell software ir services to these clients by providing something great. You sell by making the CEO feel capable of making decisions like what DVCS their IT department should use.
- Nobody is asking for this. Why would I want my team to use two different DVCS interfaces to work on the same project?
- It is difficult to trust that a Frankenstein DVCS will handle corner cases well.
-- Emo Phillips
There's a "winner take all" rally amoung certain git fans, whom have lost their sense of history, equating popularity with quality. Ironic, since the creater of git should have just switched to Windows in the '90s, because it "won already".
oh, and for the love of all of us doing dev in China, can some of these SaaS's please put a server over here so we can reliably use your products. Trello's single page app works pretty well from China. Most don't. I'm stuck with redmine and other things I can self-host.
kiln could have something more interesting. We're working on it.
Rather, harmony seems like an interesting side effect generated when Fog Creek built some swank tools for mercurial-based corporate developers, and git won the war while they were doing so.
Most of the value I see in Kiln is in the activity filters, the notifications, the code review tools, the ACLs, and FogBugz integration. Git/Mercurial interoperability is just a cute feature.
"I like their tools, but does it support git?"
Now, the answer is: "Yes, it does."
I'd say that's a tad more than a "cute feature".
So, still no money from me, unfortunately.
Fog Creek's emphasis on how they achieved git support steered the discussion to be about the value of git/hg interoperability, rather than the value of Kiln for corporate developers. And it seems like the consensus is that git/hg interoperability is, at best, a nice-to-have.
It's nearly always the same "idea": try to prevent users from having opinions and individuality.
Atwood's discourse.org was supposed to be the "next generation of forums because the current forum aren't civilized enough": people supposedly aren't "civilized" enough to be able to have their own forums. No, one should use a forum engine made for and by control freaks that shall enforce civilized discourses.
Now this Kiln Harmony thing is supposed to "end the flamewar" between git/hg: people are allowed to have their own preferences anymore. Everybody is going to "win" because they'd be using the system created by and for control freaks.
And StackOverflow is preventing individuality and allowing a few control freaks to reign king and decided what kind of thoughts people are allowed to have.
In other words these guys think they've identified a "problem": individuality and personal opinions. And they think they have a "solution": control.
Interestingly enough when I just entered discourse.org to see how that one is catching up it seems to be the better ranked in... The republic of China! (no kidding here).
Which is normal: control freaks are going to love software restricting choices and individuality.
But I love my freedom. I love individuality and I think everyone should be free, including free to chose and say why they prefer hg over git or vice-versa.
So their "solutions" (discourse.org, Kiln Harmony) aren't going to be the "next gen anything" because there are too many individuals who value their individuality.
Oh and, and even though I was an early hg adopter, I have to admit that git (and github) won big times.
It's as if they realized they didn't bet on the correct horse (inherent qualities aside, I'm purely talking about market share here) and that hence they've been "owned" by people pointing out to them that git / github was winning. It's an argument they couldn't win: there's no way hg is as succesful as Git (once again: I haven't switched yet to git... I'm a long time hg user but I have to admit defeat here). So because they couldn't admit that they were wrong they decided to create an utterly complicated solution: "To put an end to the flamewar".
I really hate the Spolsky and Atwood of this world because to me they love dictatorship.
I'm for freedom and individuality, not for control freaks trying to decide how people should think / talk / code / use DVCSes etc.
And thankfully there are way enough people like me so that these control freaks are never going to win.
Even SO is going to be replaced the day something less bent on dictatorship comes along.