develop7

A healthy person's lungs^W Rails.

Um, that's not quite true: https://www.mercurial-scm.org/doc/evolution/sharing.html#pub...

The limits imposed by phase are not going anywhere; you still cannot edit published history.

> The major deciding point between the two is that Mercurial see history as an immutable truth.

That view is quite outdated[1]. It's true for _published_ history though, but that's it. Couldn't help but note Mercurial did it right, _again_ :)

1: https://www.mercurial-scm.org/doc/evolution/

It's easy to understand, I just don't get why do I need it for anything but Git development. I mean I was perfectly able to be productive with Mercurial without the single shred of knowledge of it's internals. True, I've learned them anyway, but because I _wanted_ to, not because I've _had_ to in order to be able to do anything beyond these 5 commands mentioned in every git tutorial or understand what git output actually means. And, oh, these internals actually are leaking abstractions, multiple episodes. "You had one job" ©

Decided or followed the crowd, absolute most of them probably would defend their choice with teeth and nails (seen that lots of times).

Mercurial is actually more capable (see "phases" and "changeset evolution"). From the standpoint of the end user, that is.

All right, I stand corrected; git master of TopIcons Plus actually does work.

> If you want or need to continue using status icons, you should feel free to use the TopIcons GNOME Shell extension. This will continue to work and the extension offers a better status icon experience than the current default anyway.

I've just updated to 3.26 and, well, neither of mentioned extensions (TopIcons and TopIcons Plus, referred here and there, incl. this post and GNOME wiki) don't (just have tried it personally) therefore I must call bullshit. Also comments in OP were conveniently disabled. I'm so frustrated and disappointed to even think to start writing the bug report that would be probably closed as "wontfix" or would stay in "new" forever.

Sure, there's C++ here and there underneath, so what?

In which git is rendered obsolete (pun intended)

Oh, that's why (vanilla) Git can't have nice things like rename/copy tracking, let alone "commit publishedness" flag[1]?

1: https://github.com/peff/git/wiki/SoC-2012-Ideas#published-an...

So it makes two of us! I've kickstarted it back in 2011 and it so far it feels like one of the best $20 ever spent.

Have you tested PragmataPro¹?

¹: http://www.fsd.it/shop/fonts/pragmatapro/

https://bitbucket.org/facebook/ not for these at least

> Not sure if those were committed back.

Some were for sure: [1]

1: https://selenic.com/hg/log?rev=fb.com

That's true in case you've created some changesets, played with them locally and pushed them upstream. But, say you've played with changesets already available upstream, the unmodified changesets do not go away.

> _it is such a huge success_

GitHub _is_ a huge success, and git is merely comes along in a bandwagon (English isn't my native, hope I've made this clear)

> Whereas in mercurial, I feel pretty much lost when I want to do something that has not been an implemented workflow.

Interesting, could you give an example?

I second using Mercurial as they've also got selective commits in both simpler and more flexible way: https://www.mercurial-scm.org/wiki/CrecordExtension#For_Merc...

> yet another UI takedown without mention of underlying content-adressable arch

I'm wondering how nice architecture under the hood can be an excuse to have an Boeing-747-cockpit-style UI?

I'm quite certain most of these are sure they are using github and see no difference between it and Git; and "version control" term gives them headaches in same way as "currying" or "first-class function".

Nah, it's not _that_ bad. Only way one may realize Git is hard is to compare it with other DVCSes, so avoiding that makes him confident enough to spread wishful speculations of it's something is wrong with people, not Git.

> Why shouldn't an engineer be paid?

shouldn't he? EDIT: fixed bad wording. sorry, English is not my native.

> Please explain to me how they could monetize this on par with the effort put into developing this and still have it be open source.

paid closed-source plugins supporting enterprisey protocols, paid support, custom functionality. these are from top of my head, so pretty sure wirefloss devs could think of something as well.

well, all these points valid for all DVCS, not just Git.

despite Go isn't actually an answer, good for him anyway

Everything is better with Bluetoo…^W Git

well it could be named git-unfuck (1)

It does rely on history? Well, it won't work for me then — in my history there's only frequently-used commands.

Soon in Mercurial. Years later (probably never) in Git.

> to be able to go back to a previous state whenever I need to

as I've said, old commits are backed up.

> This works great with Git's reflog.

except git reflog is cleaned on git gc

Not mentioning http://mercurial.selenic.com/wiki/ChangesetEvolution feature is being in development.

> there was some command that left .orig files lying around

Only way .orig files may pop up is failure to replay rebased commit(s). No way these are backups — their purpose is to make user able to fix things and continue.

Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit.

> Histedit extension which is meant to provide this feature has warnings all over the place

Ignore them — you do know, what are you doing, right?

> changeset backups written to locations in the working tree

That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.

> Overwhelming at times? Absolutely.

"At times"? Well, maybe, if you have plenty of time, no paid work to do and no deadline approaching.