Thursday, March 22, 2012

Sync a fork with the original repository on Git

A seemingly simple operation that I just can't seem to get right.

This page gives me useless information:

$ git checkout -b upstream/master
$ git remote add upstream git://github.com/upstream_maintainer/master.git
$ git pull upstream remote
$ git checkout master
$ git merge upstream/master


If you do that, it frankly doesn't work. Why? "upstream/master" etc. all have special meanings.

Here's the real process & explanation (thanks to Erik Tollerud for some help):

git checkout master # (assuming you have a local branch named master - otherwise, pick whatever branch you want synced)
git remote add original git@github.com:thing/thing.git # "upstream" = "original" = "remote" - the place you're trying to sync from
git fetch original # 'original' being the name YOU gave for the "remote/original" repository
git merge master original/master # now merge the "original/master" branch (they should have a branch named "master" too, otherwise you have to figure out which branch to get) into your master
git push # push your now-merged stuff back to github

# I was instructed to use these commands. They didn't work.
# git reset original # the word "original" here matches the word "original" on the previous line
# git reset --hard original # this will overwrite local changes

NaN-friendly convolution

NaN-friendly convolution is important for, e.g., masked data sets in which you want to interpolate across the masked region.

Astropy has gained this functionality with pull request 155:
https://github.com/astropy/astropy/pull/155
but this is a "direct" convolution parallel to IDL's 'convol' routine.

My FFT-based version now works in N dimensions and is a little cleaner:
http://code.google.com/p/agpy/source/browse/trunk/AG_fft_tools/convolve_nd.py

I'm still working on writing unit tests, and I'm really not sure what the "correct" behavior at the edges is for the different cases... right now, it seems counterintuitive to me, but the code is doing what I expect it to.

Also, Boxcar kernels always result in shifts for me... they're never supposed to. This is a bug.

Currently, other links to these codes:
http://stackoverflow.com/questions/1100100/fft-based-2d-convolution-and-correlation-in-python/8454010#8454010