I spent a few years developing tooling and processes around Mercurial, then moved to a new role some months ago where Git is used exclusively. I am afraid that I still prefer hg; while git is, as a rule of thumb, faster, hg takes better care of your data (Much harder to lose changesets) and presents a cleaner UI out of the gate.
Much harder to loose changesets? The reflog keeps changesets for up to 90 days (default, can be configured), if you don't notice that changesets are missing for 90 days, then chances are they don't matter :/
I am utterly flummoxed by the idea of a version control system that autonomously discards versions at all, even if it keeps them in a mysterious trashcan for 90 days.
Last week, some colleagues of mine 'lost' some commits because some other colleagues had misused a forced push. They could probably have got them out of the reflog, if someone had told them about the reflog in time; before i could, they recovered a diff from their console history. If they'd been using Mercurial, the situation just wouldn't have arisen; they would have had a branch with two heads, and they could have resolved that straightforwardly.
The fact that is would possible to recover from this situation using a command that one never has any other need to even know about is no excuse for the fact that it is even possible.
> If they'd been using Mercurial, the situation just wouldn't have arisen; they would have had a branch with two heads, and they could have resolved that straightforwardly.
The would have this situation in Git too. If the Git-server was setup to only allow fast-forward merges, then they wouldn't be able (little uncertain here) to force it through either. Forcing something is never a good idea, even in Hg.
> The fact that is would possible to recover from this situation using a command that one never has any other need to even know about is no excuse for the fact that it is even possible.
So... Git provides a feature, allowing you to clean up history before merging (what it is mostly used for anyway). Git even provides an option to recover from these changes... And you're upset because colleagues of you who apparently didn't know Git, fucked up?
Atlassian Stash comes with a plugin that exposes a "Disable Force Push" toggle. I have that on for all the repositories it hosts. Nobody complains that force push doesn't work (~10 devs) because if you're doing force push you're probably doing something wrong.
>> some other colleagues had misused a forced push
> Git has a learning curve.
That sounds a bit like a euphemism for "is hard to use".
However, that's not what i'm getting at. The first pair of people misused a forced push because they're clowns. They are never going to learn to use any version control system properly, even if the learning curve was down a slide. If we disabled force push, they'd probably have reenabled it (they're sysadmins, so it would be hard to stop them).
The problem is that the second pair of developers, who are not clowns, but are also not Git power users, nor have any interest in becoming Git power users, got screwed by the first pair's mistake, and could only have got out of it by using an obscure feature known only to Git power users.
> and could only have got out of it by using an obscure feature known only to Git power users.
Obscure? I spent one afternoon reading the Pro Git book that is available free online. The first thing you learn, after learning to alter history, is the reflog.
Look, everything people in our business do is based on trust. It's fairly easy to mess up for everyone, and this includes Mercurial as well. Like switching bookmarks around or messing with hg strip.
This is not an acceptable solution as a plan. It is, instead, a terrible hack to deal with expected error. Better yet is to plan for errors to be exceptional things.
git bills itself as the stupid content tracker. It's much better to add a small amount of smarts to ensure that you and your friends don't have to reach in the trash and get the changesets you erroneously deleted.
And it's not an error that the user tells git (s)he wants to remove or squash or whatever some commits. Git gives you that flexibility, which alot of people like, and at the same time gives users an undo-history in case they mess up.
On the other hand, I've used the reflog once in the last four months. For me, the use of reflog really has been exceptional.
