Let My People Go: the Hg to Git evacuation process.

circular firing squad captain — Fri, 13 Sep 2019 04:53:31 +0000

When bitbucket recently announced the impending doom of mercurial support come May 2020, I knew my time had come. My various projects and Open Source contributions could abide bitbucket no more.

It was time -- cringe -- to figure out how to export my mercurial repositories to git.

(TL;DR — fast-export worked for me, but with a catch. See below.)

I’ve been observing for some time how bitbucket.org cannot quite measure up to the potential of github.com when it comes to promoting the building of Open Source Software. It seems I've just been waiting for that proverbial kick in the pants to get off my adverbial butt and lead my ragtag bunch of repos out of the feature-desert of bitbucket and into the Open Source promised land of github.

(Now, I too shall have all manner of pieces of CI/CD flair on my READMEs!)

My procrastination all centered around transitioning from mercurial (hg) to git. I have no shortage of experience in git, here in 2019 where we are long past the ambiguity of whether mercurial or git would become the source control worship of choice.

However, dark ominous clouds swirled around shuttling my repository histories from one system to the next.

For when I went looking for utilities to help with this process, I found but two:

fast-export
hg-git

Very quickly did I audition both, and out of the box both were failures.
Argh! Why, O great and powerful Open Source, do you torment me so?

As ultimately I did not get hg-git working, this article will simply detail the steps I took to get fast-export to perform the correct rituals, along with the main problem I encountered and how I solved it.

https://dzone.com/articles/convert-a-mercurial-repository-to-git-using-hg-fas

The Logical Steps

or, what we’re trying to accomplish:

Create a new empty git repo to serve as the target container for your export.
Locally, set up your mercurial repo as a git repo. Set settings to make sure git ignores hg effluvia.
Configure the repo to take the newly-created git repo from step 1 as its remote.
Perform the export of HG history using fast-export.
git commit && git push —set-upstream origin master
Check new repo on github to make sure everything’s there.

The Practical Steps

or, what we actually have to do.

First off, you should go create a new empty git repo on whatever service you're using. Make sure you keep handy the remote information for use later on in the process.

Now I'm going to take the unusual step of starting with the problem that occurs in the middle, so that the instructions as a whole make more sense.

When running the fast-export.sh script, many people encounter the following unhelpful error message:

 Traceback (most recent call last):
   File "/home/nthmost/fast-export-190107/hg-fast-export.py", line 7, in <module>
     from mercurial.scmutil import revsymbol
 ImportError: cannot import name revsymbol

This means it definitely didn’t do the export. What should we do?

Well, it turns out that several releases of the fast-export tool over the past year or more have been unreliable. I found, by poking around the Issues, that the only reliable recent-enough release is tagged “v180317”.

So what you should do is the following:

git clone https://github.com/frej/fast-export.git
cd fast-export
git checkout tags/v180317

Once you have this specific version of fast-export, now you can continue on with the next steps:

cd /your/target/repo
git init
../fast-export/hg-fast-export.sh -r /your/hg/repo
git remote add origin https://github.com/user/repo.git
git commit
git push —set-upstream origin master

Note that it’s entirely kosher simply to do all the git work directly within the mercurial directory you started with. If so, you can just replace /your/hg/repo with a . for the fast-export command.

If you want to keep on using mercurial with git, then you should probably get hg-git working; otherwise, I’d recommend only continuing to develop this project after you’ve cloned from the git repo afresh and wiped out all traces of your former mercurial life. 🙂

That’s all! I hope that’s perhaps saved you a few minutes of banging your head on a keyboard. Keep the faith!

How to Turn Onboarding Into Hazing and Gaslighting

circular firing squad captain — Fri, 02 Aug 2019 20:23:31 +0000

A guide for the discerning CTO or Engineering Director who knows the value of a 6-month employee turnover rate.

Many people in the software industry believe the onboarding process for new engineers takes at least 30 days. Balderdash! We can’t have people wasting time learning how to relate to one another or -- worse -- figuring out how their skills might make them uniquely useful.

What you need are employees with a proper fear of being fired at any time, who think of themselves as interchangeable cogs in a productivity machine. To get there, you need to make sure your new recruits never learn how others in your company are motivated or what the company's big picture needs really are. That's YOUR job!

Many tyrants underestimate the value of a quick onboarding process for achieving that key level of existential dread in their employees.

In this guide, you'll learn how to shorten that onboarding process to 2 weeks (or less!) and inspire a healthy respect for authority by picking up a few of these easy tips we’ve sourced from various real employers over the years.

Never change your onboarding expectations with the number of people and lines of code in your repositories. Assume that onboarding is going to be just the same for employee 100 as it was for engineers #1, #23, and #99.
Demand they be producing important new features within 2 weeks, setting standards of productivity that haven’t been reevaluated since the company began and all of the projects were greenfield projects.
Copy your onboarding process verbatim from whatever company you were a director of before you were hired here. Make sure all the managers under you feel like idiots for not being magically already socialized to your previous company's culture, so they can efficiently pass that frustration right along to their direct reports!
When people can’t find the documentation you linked to a year ago due to the natural forces of entropy, send them on a days-long odyssey to track it down for themselves. Make sure you don’t account for that time when you consider how long it’s taking them to become productive.
Ignore all turbulence being experienced in your department due to personnel changes. People getting fired or changing responsibilities is no reason why things shouldn’t continue exactly as they did before. Institutional memory is a myth.
Make semi-oblique reference to their salary and/or job title as an indication of their worth as a human being vis-a-vis how long it’s taking for them to implement their first real feature. Teamwork is a zero-sum game, so go ahead and set up implicit competitions between new and existing engineers as a means of motivating people to work harder.
Send all critical feedback or do-ocratic attempts at improving the process directly to /dev/null. We don’t have time to update onboarding when there’s real work to do.

Remember: all of your decisions have always been perfect. When multiple people trip over the same pieces of company shrapnel, that’s a good sign that everyone is less smart than you.

Your newest hires need plenty of pointless challenges and bewildering antagonism to remind them of their commitment to the company based on how bad it would look to quit now.

For months to come, they’ll be bonding over onboarding with their coworkers over the 20 minutes you allow them to walk out of the office to get lunch and bring it back to their desks.

Because, hey: it’s not your fault you promised 200% more than you can reasonably deliver this quarter!

DEV Community: circular firing squad captain

Let My People Go: the Hg to Git evacuation process.

The Logical Steps

The Practical Steps

How to Turn Onboarding Into Hazing and Gaslighting