That's quite an oversimplification of the problem, copying stack/heap/etc. Anyways, check out CRIU as a starting point.

(and note that lxd/lxc allows migration based on it. Not sure about copying - I suspect you run into similar issues as fork - who owns the open file handles and other resources?)

Yeah, it's interesting how many people have had the same idea at some point or another. I was fiddling around with Rails and AWS for a bit around 4 years ago and used the same idea for a tiny project. It's a bit like deja vu. https://github.com/ehotinger/OldCode/tree/master/VariantChef

A lot of us have tried this idea, me included two years ago. It seems like a logical idea, but there really isn't enough people looking for it.

$120k in Seattle is not equivalent to $120k in the Bay Area...

No yet, but the cost of living in the Bay Area has leveled off somewhat (or even dipped slightly), while it continues to rise in Seattle.

Nothing unless you're rebasing upstream, but I think the point he was trying to make was that you should always run `git fetch` and then `merge` from there (again, there are some situations where the pull is fine IMHO).

git pull just runs git fetch then git merge.

At least that is what the docs say: http://git-scm.com/docs/git-pull

What am I missing?

but it tries to be smart about how to merge. and usually it's not what you want. i consider it the clippy of linus.

if you run merge/rebase/etc on its own, it will tell and ask you about anything out of the ordinary and then there's no surprise.

again, it's all about avoiding errors on the rare cases because you developed dangerous finger memory.

Beat me to it.

Why?