How to move commits after git filter-branch

I’ve read that you’re supposed to be able to use git rebase to move commits from an old repo to a one after using git filter-branch. But I couldn’t get that to work.

The backstory: Our repo was bloated because we started by forking a different project, and then deleted unneeded parts. This was an easy way to get started, but we ended up with all the history of the old project. So I ran git filter-branch and some other tools to clean up the history and remove empty merge commits. While I was preparing that, the rest of the team kept working on the old repo.

So I had to move those commits the rest of the team made onto the new, filtered repo. I used git format-patch and git am. Like this (assuming cwd is the new repo):


( cd ../old-repo; git format-patch --stdout -k commit id on old-repo of last shared commit ) | git am -k

Puppies

A new phase in my life starts…

20140218-091613.jpg

Leo (short for Leonard, in honor of Leonard Nimoy) on the left, and Chester on the right.

20140218-091635.jpg

Me with Leo (Leo has the science-officer blue collar).

20140218-091656.jpg

These best buds comforted each other on the scary ride from the farm outside of New Ulm where they grew up.

XMLHttpRequest access-control-allow-origin cocoa webview

Yes, those are the search terms that had me scratching my head for several hours today…

You see, once upon a time, we trusted each other on the internet. Internet browsers were built optimistically, that no one would try to do foolish things or cheat anyone.

And then came cross-site scripting attacks. That’s where a nice site, like a banking site, gets attacked remotely simply by virtue of someone making an exploit in a comment field or some other innocuous thing. The browser would start sending data to another computer. That is bad.

So browsers got less trusting. They won’t let you send data to another computer unless that computer says it’s okay. (Wait.. what? Isn’t that backwards?) Oh, ok, so that kind of attack is still possible.

But what it does do is protect you from fake sites (e.g. a domain name where they start out recognizable, like www.mybank .. but then instead of going to dot-com, they go to dot-flibbertygibbet.com..)

But today I wasn’t trying to steal your credit card numbers. Honest. I was trying to make a webview control in a Mac app send some data to a server. It was almost working but I kept getting the error


access-control-allow-origin

Searching the internet wasn’t helpful. But I finally found the answer:


[WebView registerURLSchemeAsLocal:request.URL.scheme];

This was really handy, because I was using NSURLProtocol to deliver content via a custom sheme anyhow. But that’s a story for another day.

I hope someone finds this useful.

Ignore SIGPIPE in LLDB

Both GDB and LLDB by default will stop when a debugged process receives a signal. Some libraries, such as the mongoose HTTP server, will generate SIGPIPE as a matter of course and that can be “normal”. However, the debuggers stop anyhow.

Google result currently shows this GDB command can be entered to stop the behavior:

handle SIGPIPE nostop

The LLDB equivalent is not obvious, but I found that this will do it:


process handle SIGPIPE -n true -p true -s false