
Announcing Kiln Harmony: the Future of DVCS - df07
http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/
======
gecko
Kiln Harmony is complicated, and has lots of edge-cases it needs to handle.
We'll be publishing a whole series of blog posts that explore exactly how Kiln
Harmony works. In the mean time, though, just because I think it might spawn
some interesting discussion, here is a _non-exhaustive_ list of edge-cases we
translate:

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

There's more, but hopefully that gives you some idea what we were up against.
Again, I'll be publishing a series of articles that explore _how_ we handle
all the above edge-cases beginning really soon.

~~~
ay
This sounds like a great list of the technical challenges for Kiln
implementors (applause) and an awesome list of reasons for me to rationally
convince my team (if I had one) to use the single DVCS.

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 ?

~~~
gecko
I'm actually really happy with the workflow we came up with; that's something
we've been using for months now at Fog Creek with no real issues. The above is
a list of _data format issues_ , which your team doesn't have to deal with.

------
azov
Joel's very own article on the Law of Leaky Abstractions
([http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html))
comes to mind. Kiln Harmony might abstract away which VCS system you use, but
I think in the real world you will just end up having to know both systems (or
finally standardizing on one). Think of communication, for example:

\- 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 :)

~~~
HeyLaughingBoy
I'm having a really hard time seeing that. I use version control both at work
and for side projects at home.

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.

~~~
azov
If it really was that simple, mastering a new VCS would take 5 minutes. But it
isn't.

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.

------
noelwelsh
There are things you have to really care about and things that just have to be
good enough. Version control is in the latter.

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.

~~~
bsimpson
I don't have a horse in this race, but I feel like this ship has sailed.
Personally, I don't like jQuery's API, but it has become so popular that it's
the honorary JavaScript standard library. I'd be hesitant to start a new
project using MooTools, knowing that most people I might hire or most
frameworks I might want to incorporate later probably know/expect jQuery.

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.

~~~
philjohn
There are a fair few people who choose bitbucket over github because the
pricing structure is saner if you have a load of repos and a fixed (or
predictable) number of staff who require access.

~~~
veidr
And since last year, you can choose Bitbucket and still use git 100% of the
time.

THAT seems to me what Fog Creek is doing here -- realizing, _shit, we picked
wrong, but now we have all these users, how can we take a mulligan and pick
git?_

And they did it. So like somebody else here said, what they've done is change
the answer to "Does it work with git?" from no to yes.

(Note I am also not saying that anybody choosing hg over git for their own
development 'chose wrong'. But if you are trying to do business by selling
people a mainstream DVCS service, hg isn't the best choice you could make.)

------
cjbprime
> This means that you never have to decide whether you want to use Git or
> Mercurial. Religious war: averted.

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

~~~
flurpitude
The Mercurial support is very welcome for those of us who found it a battle
getting our employers to switch from SVN to Mercurial and don't want to go
through that again. Unlike the transition from SVN to a DVCS, a transition
from Mercurial to Git would not really be of any great advantage. And our code
is not open source so it doesn't make much sense switching just because in the
wider world Mercurial is out of fashion.

~~~
crisnoble
>...those of us who found it a battle getting our employers to switch from SVN
to Mercurial...

Any tips for someone still fighting resistance to move to a DCVS?

~~~
larrywright
I think for an enterprise, the D part of DVCS isn't much of a selling point.
What _is_ a good selling point is all of the other stuff that makes Git/HG
awesome, like easy branching and merging. There's also Github Enterprise,
which if you can pay for it is really fantastic.

~~~
kscaldef
The D can be a selling point. Some things D enables:

Working offline is completely transparent. If your employees are on an
airplane, or if the wifi at the conference they are at is overloaded, or if
the central repository goes down for some reason, people can continue to work
normally.

Code review based on asking for permission, not forgiveness. While the UI is a
bit horrid, gerrit has been a huge win for us when it comes to code reviewing
changes before they are out "in the public". When code review happens after
something gets committed to the main repo, it's far to easy for issues to get
forgotten about and never addressed. (Of course, Github pull requests have a
better UI than Gerrit, but you might have reasons not to want to entrust your
code to Github. And, also of course, this isn't strictly something that can
only be done in a distributed VCS, but it seems to be a lot more natural in
that context.)

------
cgrubb
I've been doing Google searches every now and then to try to assess the
relative popularity of Git vs Mercurial. Two years ago it seemed to be 2:1 in
favor of Git. A year ago it seemed to be 3:1 in favor of Git. Now I think it
is about 5:1 in favor of Git. Here are my most recent Google hit counts:

    
    
        git 208M
        git revision 6M
        git version 56M
        git control 19M
        mercurial 29.5M
        mercurial revision 1M
        mercurial version 7M
        mercurial control 6M
    
    

Google trends of "git repository" vs "mercurial repository":

[http://www.google.com/trends/explore#q=git%20repository%2C%2...](http://www.google.com/trends/explore#q=git%20repository%2C%20mercurial%20repository&cmpt=q)

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
    

The decline in popularity of "mercurial" vs "git" seems real, but I agree that
"mercurial" searches may be under-reporting the popularity of Mercurial. The
top hits for "hg -mercurial revision" have nothing to do with Mercurial, tho.

~~~
ejp
You might want to include searches for 'hg revision' etc - mercurial suffers
from having its command-line invocation different from its name.

~~~
niggler
unsurprisingly, 'hg ____' shows fewer results than 'mercurial ____' for the
words the parent tested

~~~
thedufer

        hg - 338M
        mercurial - 30M
        hg revision - 5.5M
        mercurial revision - 1.1M
        hg version - 60M
        mercurial version - 7M
    

I'm seeing exactly the opposite. There's an argument to made to the effect
that `hg` picks up a lot of things that have nothing to do with source
control, but that's still a big difference.

~~~
niggler
Try searching for git as well:

[https://www.google.com/trends/explore#q=git%20version%2C%20m...](https://www.google.com/trends/explore#q=git%20version%2C%20mercurial%20version%2C%20hg%20version&cmpt=q)

~~~
thedufer
That's search volume. Parent was talking about search hits. I'd believe that
search volume is more important, but I stand by my point in the context of
this thread.

------
specialist
I'm interested. Which is a new thing.

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.

~~~
julianz
Yeah Joel was born to demo/present, wasn't he. I saw him at Webstock some
years ago and it was a fantastic presentation.

------
bsimpson
I have a hard time believing anything is the 'future' of version control if it
doesn't have a free, public open-source plan. GitHub and BitBucket have huge
amounts of inertia, and hence dominate in mindshare.

~~~
mhp
Github's workflow, features and terminology are focused on open source
projects and those projects tend to work in a specific way. Kiln is focused on
providing features that fit better inside a business environment. For example,
the idea of a pull request is a bit foreign in a business environment.
Internally, almost all the code written eventually gets shipped, so the social
interaction around pull requests doesn't fit exactly right.

Joel explains it better than I can:
<http://www.joelonsoftware.com/items/2013/03/11.html>

~~~
ajross
How is the "social interaction around pull requests" not just a synonym for
"code review?"

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.

~~~
mhp
No, we have code reviews _instead_ of pull requests, which as you point out is
mostly terminology. But that terminology is indicative of assumptions that are
baked into how the software operates. The assumptions and workflow of Kiln
assumes you are using it inside of a business. I just gave one superficial
example of a larger point I was trying to make about our intentions vs. people
creating open source solutions and how that translates into
defaults/workflows/usability of the software in different areas.

~~~
ak217
Give us some more examples, please. The pull requests vs. code reviews
distinction is unconvincing.

I'd love to find a DVCS SaaS that provides better integration with the
business software engineering workflow, and a UI that doesn't suck. So far I
don't see a whole lot of that going on in kiln+fogbugz.

------
nnq
Since everybody is always repeating it and one can take Git being the "winner"
of the DVCS "war" as a fact, I just have to ask: _why tf did Git win at this?_

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

~~~
laureny
> ...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

If a tool makes you productive, you make the effort to look beyond its flaws.

Windows and git are just two examples.

~~~
nnq
funny way of putting them together :) ...especially since Git is UNIXy to the
bone, in all the bad ways.

~~~
mercurial
I was thinking about the other day, and I disagree. The main beef I have with
git is that it's _NOT_ UNIXy enough. Instead of having one command for one
thing, it has one command for several different things (eg, git checkout)
which I find absolutely aggravating.

------
andrewgodwin
Interesting - I was trying to get this concept to work a few years ago after I
got a live SVN/Mercurial translator working, but it was very hard due to all
the differences they note in this post.

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.

~~~
gecko
I'll be publishing a series of articles that dive into the nitty-gritty of how
Harmony works in the coming days, so I don't want to answer every single "How
do you?..." question in this thread, but since you're the first one:

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.

~~~
andrewgodwin
That's how I thought it'd work, just curious. Looking forward to reading up
how it works - I hope it's not too fragile.

------
lifeisstillgood
This is likely to be a painless (if it works) transition mechanism for
companies that chose mercurial and now want to follow git.

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

------
cantastoria
Are there really that many dev teams that use Mercurial and git at the same
time? Honest question....

~~~
msy
Isn't the question more 'how many dev teams contain frustrated devs that would
be happier using git/mercurial but are forced to use git/mercurial?',

~~~
dscrd
Such people are silly, since those two options are almost identical.

~~~
nmcfarl
This sentiment seems to be common amongst people who fought their way through
git’s somewhat obtuse syntax first.

People coming from the other direction (hg first), I know a lot of people who
wish they could go back to mercurial, but for various reasons can’t.

~~~
tseabrooks
I went from hg -> git in the last couple of years. I'd say they are "almost
identical". The key difference is a slightly different mindset on merging and
branching IMHO. It can be non-trivial for some of my more hard headed dev
brethren to change their way of thinking once they've chosen a method and
gotten in the correct mindset.

------
krmmalik
Is having to make a binary choice between Git or Mercurial, really that big a
deal? I just assumed that teams would make a consensual decision, stick to one
and get on with it. Seems like a great feat of engineering, but is it that
wide a problem? (genuine question).

~~~
caw
Welcome to corporate.

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.

~~~
krmmalik
That would explain my naivete on the matter. I don't deal with corporate much
at all. I guess it makes sense for the corporate environment in that case
then.

Thanks for clearing it up.

------
peterkelly
This is _extremely_ impressive from a technical point of view, but I'm
wondering if it's the wrong solution, given that arguments over a version
control system are largely an organisational issue? Surely a better approach
would be for everyone involved to negotiate and come to an agreement on the
tool to be used, or have it mandated from on high.

(Please wait a couple of mins before replying while I don my flame-retardant
suit ;)

------
pjungwir
How does this compare to ESR's reposurgeon tool? [1] I understand Kiln Harmony
is a website, not a command-line tool, but it seems like they must have had to
solve many of the same issues.

[1] <http://www.catb.org/esr/reposurgeon/>

~~~
gecko
That's pretty radically different. A closer analog might be hg-git, but the
moment you say that you want the entire process to cleanly round-trip, you
have to preserve all kinds of weird and corrupt data that the modern
incarnations of the tools don't let you create (for good reason). There's also
a lot of internal metadata, especially in Mercurial, where there are multiple
valid ways to store a given concept, but only one will yield the right SHA for
a given changeset. Not only did no existing tool try to handle these issues;
they were all built in ways that would've made such preservation impossible.
That's why we had to write our own from scratch.

------
rbanffy
I suspect it'll be an uphill struggle. Like many pointed out, Git is good
enough, it's free (as in beer as well as in speech) and ubiquitous. Where it's
not is the domain of proprietary, hideously expensive and deeply entrenched
(sometimes bundled with IDEs that run on only one OS) solutions their users
hate, but corporate IT mandates the use nevertheless because it was not a
user-driven decision.

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.

------
orclev
I like the concept, but I have two objections to it. One, as pointed out by
others, I'm highly skeptical of some of those edge cases. They mention a few
of them at the end of that article, but they largely gloss them over saying
they're dealt with automatically. My other objection is with Kiln itself. Not
open source, not cross-platform, and even on Windows it seems to have strange
requirements (like you can't run it on the domain controller). Sorry, any
service that requires Windows is a automatic fail so far as I'm concerned.

~~~
mhp
Are you talking about the Kiln servers, or issues with client software? The
servers are hosted, so you don't need to worry about any requirements or cross
platform issues.

~~~
orclev
The servers. I was looking around on the site to try to find more info about
Kiln, and one of the FAQs was the system requirements for the server (for
companies that want to host their own Kiln instances I'd assume). With git or
Mercurial I can spin up my own host in a variety of ways, or if I want
something slicker I could host my own instance of github (not sure about
BitBucket, but I suspect it likewise can be self-hosted). With Kiln if I
wanted to go a similar route I need to have a Windows server with IIS and a
variety of other dependencies.

~~~
mhp
Ah, that's old documentation. We host Kiln on our servers now, so we don't
sell on premise versions that you'd have to install which makes this a bit
moot. But if we do start to do that again, you would be able to spin them up
the same way you'd spin up GitHub enterprise, with a VM:
<https://enterprise.github.com/faq>

~~~
atesti
When have you stopped that and what happened to the existing customers? Did
you ever announce that? I have noticed that FogBugz is now in very fine print
in the version for your own servers, so it looks like you want to kill that
off, soon. How long do I have until I have to find something else for bugs?
I'm very concerned about this!

~~~
gecko
We are not killing off FogBugz, I promise. There's a new _major_ release that
should come out very soon.

~~~
atesti
Of course you are not killing off FogBugz! But what about the version for your
own server? Is that going away or staying? I read your message like it's going
away, otherwise you could have written that FogBugz will still be available
for your own server!

~~~
gecko
As of today, there is no plan to kill FogBugz for your server. That's about as
clear as I can make it.

------
naner
Cool project, two criticisms:

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

~~~
mixmastamyk
Don't use it that way if you don't want. You can read the announcement as,
"kiln now supports git."

------
jiggy2011
Do git and mercurial users get into flamewars? I would assume they are pretty
well united in their hatred of centralised verion control systems.

~~~
zem
I was walking across a bridge one day, and I saw a man standing on the edge,
about to jump off. So I ran over and said "Stop! don't do it!" "Why shouldn't
I?" he said. I said, "Well, there's so much to live for!" He said, "Like
what?" I said, "Well...are you religious or atheist?" He said, "Religious." I
said, "Me too! Are you christian or buddhist?" He said, "Christian." I said,
"Me too! Are you catholic or protestant?" He said, "Protestant." I said, "Me
too! Are you episcopalian or baptist?" He said, "Baptist!" I said,"Wow! Me
too! Are you baptist church of god or baptist church of the lord?" He said,
"Baptist church of god!" I said, "Me too! Are you original baptist church of
god, or are you reformed baptist church of god?" He said,"Reformed Baptist
church of god!" I said, "Me too! Are you reformed baptist church of god,
reformation of 1879, or reformed baptist church of god, reformation of 1915?"
He said, "Reformed baptist church of god, reformation of 1915!" I said, "Die,
heretic scum", and pushed him off.

\-- Emo Phillips

------
Camillo
Well, at least we can all agree that bzr is dead.

------
rockhymas
Kiln Harmony won't save as much money and angst as a DVCS that automatically
converts tabs to spaces and back, based on personal settings, or one that
changes bracket code formatting, but it's a start.

~~~
McP
It's not too hard to write a Mercurial extension to do that kind of thing.
Copying the code for the EOL extension
(<http://mercurial.selenic.com/wiki/EolExtension>) and modifying it would be a
good start.

------
jhancock
If being fully git/hg interoperable was holding back sales, I can understand
their year-long investment. What is holding back me buying into FogCreek's
products is tightly integrated Trello-Kiln-FogBugz. Hope you get to this soon.

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.

~~~
mhp
trello -> FogBugz integration - should adapt to any and all usages:
<https://github.com/danlec/Trello-Bookmarklet>

kiln could have something more interesting. We're working on it.

------
cmbaus
The war was over before this release. Git won.

------
cmars
I'd rather have the opposite -- a client that can use multiple DVCS
repositories while preserving the identity of commits.

------
daigoba66
It seems as though having members of the same team mixing up mercurial and
git. They have their own language and idioms. Think about trying to work
together in such an environment. For some tools it's simply better for the
team to homogenize than stay diverse. We're not talking about a text editor.

------
atesti
Since when is the version to be installed on our own servers unavailable? I
always wanted to buy it once I have the svn conversion problems figured out.
How long do existing FogBugz users have until the non-hosted version is
removed from the market, too and how long are we able to get updates?

------
cheez
Is this really such a big need... Tech lead picks, and fills team with people
who agree. Done.

------
rscale
I could be wrong, but I don't think the git/mercurial integration is the big
point of Kiln.

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.

~~~
diminoten
It opens doors which were, until now, closed to the Fog Creek people. I bet
this was said a _ton_ :

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

~~~
jwr
As someone who said exactly that and pays for FogBugz, but uses GitHub: now I
read about what they did and think "why would they do that? It's a horribly
complicated technical problem, I can't be sure they got it right, I'll stick
to GitHub".

So, still no money from me, unfortunately.

~~~
erikvanzijst
> I can't be sure they got it right, I'll stick to GitHub

I guess you could just not use the feature and only use git clients. Who cares
if the redundant hg clone they keep on their end gets out of sync.

------
martinced
It's really tiring to see what the Spolsky and Atwood offsprings are coming up
with...

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.

