Step 1: do a search for ‘@yourname’ on summize, then copy the link for the feed. If you’re lazy, that link looks like this: http://summize.com/search.rss?q=%40your_username_here.

Step 2: use pingie, a free rss to sms converter. Put in the feed link you got in Step 1, your phone number, and your email. Confirm pingie service via the SMS they send you. You can also do this at Yahoo Alerts rss to sms

Step 3: Profit!

Update: after running this way for a couple days I disovered that pingie has completely failed to deliver any updates to my phone (maybe because of Helio/Sprint), while the Yahoo solution has delivered duplicates with extreme delay. Making both solutions an epic fail. Still looking for a solid rss to sms solution that does what it says it does.


alias gitrm="git stat | grep deleted | awk '{print $3}' | xargs git rm"


Update: turns out git add -u takes care of deleted files.

In your bash profile:

alias svnpull='git stash && git svn rebase && git stash apply'
alias svnpush='git stash && git svn dcommit && git stash apply'

Let’s say you made some changes in local-trunk and you want to merge them into your branch-1.5 which is your release branch. From the branch:

git cherry -v local-trunk
+ 08d7780de7e16a22b7e8ed1d42acebc4bc07573f  a changeset i haven't merged yet
- 78a7b285089c76664a530f68803259c53cbadb42 another change

Each line indicates a change. If it has a “+” it means they only exist in the local-trunk. A minus indicates changes that have already been merged in. Magic! Now that you know which changes you want, just cherry-pick them in.

git cherry-pick 08d7780de

Update: here’s another cool trick to see where every branch is at

git branch -v

Output looks like this:

branch        317544a #520 fix single page build

local-trunk   ec85f65 #520 fix single page build

]]>
			http://yanpritzker.com/2008/05/13/git-tips-tricks-part-4-more-on-cherry-picking/feed/
		0
		
		
		
		http://yanpritzker.com/2008/05/13/git-tips-and-tricks-part-3-working-with-svn-branches-and-cherry-pick/
		http://yanpritzker.com/2008/05/13/git-tips-and-tricks-part-3-working-with-svn-branches-and-cherry-pick/#comments
		Tue, 13 May 2008 03:37:01 +0000
		yan
				
		
		
		
		
		
		

		http://skwpspace.com/?p=151
		
			After several weeks of git usage, I’ve developed a nice workflow. First, we’ll start with working with several svn branches via git.

Working with svn branches via git
Assuming you’ve properly cloned your svn repository, you should have your trunk and remote branches fetched from svn. You can see the remote branches via 
git branch -r
If you have colorization turned on, then
git branch -a 
Will give you all your branches (local and remote) and color the remote ones in red. The way you want to work is to create a local git branch for every svn branch you’re working with. So you might do something like
git branch local-trunk trunk

git branch local-1.5 branches/1.5
This will create two local branches (called local-trunk, and local-1.5 respectively) that follow the corresponding remote branches (trunk, and branches/1.5).
Now we’ll switch to the trunk…
git checkout local-trunk
Do some hacking, and commit the change
git commit -a -m "this is my hack"
Let’s say this was a bugfix and you also need to apply it to the branch. Switch to the branch:
git checkout local-1.5
To pull individual fixes from trunk you can cherry-pick the fix by its commit hash, which you obtained when you committed or via a log.
git cherry-pick 234adsfa7s8dfasdf
This will automatically pull in the change and commit it to your branch. If you don’t want to immediately commit but want to mess with the files first, then use the -n switch, which merges in the fix but doesn’t commit it. Then you’ll want to git svn dcommit to push your change out to the svn branch. This procedure is much faster than using svnmerge.py.
Nonstandard or wacky branch structure
It so happens that my repository is set up in a slightly nonstandard way due to a particular legacy. Instead of having a structure such as foo/trunk and foo/branches, I have trunk/foo and branches/[branchname]/foo. As it turns out, git supports this very well as long as you specify the format using wildcards in your .git/config

[svn-remote "svn"]
  url = http://www.myrepo.com/svn/parent
  fetch = trunk/foo:refs/remotes/foo/trunk
  branches = branches/*/foo:refs/remotes/foo/branches/*


The format of this file basically has two parts separated by a colon. The first part tells git what the repo looks on the svn side. The second tells it what to call the branches that git creates to correspond to the ones out in svn. You’ll notice the placement of the wildcard on the third line is what generates all the branches correctly.
Note: Please see all posts tagged git for the rest of the series.
]]>
			http://yanpritzker.com/2008/05/13/git-tips-and-tricks-part-3-working-with-svn-branches-and-cherry-pick/feed/
		1
		
		
		
		http://yanpritzker.com/2008/04/22/useful-git-commands-and-quirks/
		http://yanpritzker.com/2008/04/22/useful-git-commands-and-quirks/#comments
		Tue, 22 Apr 2008 05:00:34 +0000
		yan
				
		
		
		
		

		http://skwpspace.com/2008/04/22/useful-git-commands-and-quirks/
		
			Things I’ve learned from my first git experiences. First of all, git is inconsistent as hell. Every command has its own quirks and syntax, so I’m attempting to catalog some of them here. We’ve been using git svn at Planypus as a way to maintain local developer branches and still push to our svn as a central place which then triggers our integration server rebuild, cruise control, and so on.

First, make it look nice



$ git config --global color.diff auto

$ git config --global color.status auto

$ git config --global color.branch auto

$ git config --global color.interactive auto



via tpope
Onwards to the commands…
If you’re using git svn and you want to see changes that you have comitted locally but have not yet dcomitted
git svn dcommit -n
This might give you output that looks like this

diff-tree e784cfa... e784cfa...
BUT, if you want to actually see the changes, what you want is apparently the ‘patch’ output:
git diff-tree -p e784cfa... e784cfa...
If you have uncomitted changes, it’s easy to see them
git diff
BUT, if you’ve already created your commit set (git add) but not comitted, you how have to use
git diff --cached
If you’ve accidentally added  some files to your commit set and want to remove them from the index (untrack them), but leave the changes in your working tree
git reset HEAD [file/dir]
To undo local changes (revert in the svn sense)
git checkout [files]
Note that this works as long as the file is not yet in your index. If you’re already tracking it for commit, you’ll need to untrack it first using git reset HEAD [file] before you’re able to check it out.
You can also use this command to check out files from the past by specifying any commit hash:
git checkout [hash] [files]
It’s just that when you don’t specify the hash, it assumes HEAD.
If you’ve got changes you want to just throw away permanently, you can just reset:
git reset --hard
But reset is a powerful command that can also take you back in time. Let’s say you messed up the last commit, you can take yourself back to the way things were right before you comitted:
git reset HEAD^
Notice I didn’t use --hard because that throws away the changes. Instead, this form of the command throws away the commit by taking you to HEAD^ (one commit before HEAD), but it leaves the changes in your working tree. If you want the changes also to be left in your index (ready to be comitted) you can use
git reset --soft HEAD^
If you’re working on something and you decide you want to scrap it or work on it later
git stash
There are lots of fun things you can do with stashes but they’ve been covered on other blogs.
on merging…
If you’ve done a git merge and have some conflicts, launch git mergetool which will take you through the conflicted files one by one using your default merging tool (FileMerge, usually, on OSX) and let you merge them. However be careful. Either because of a misconfig on my end or some other quirk, FileMerge shows the file I pulled from svn as “LOCAL” while my file with changes is “REMOTE” which is counterintuitive to me and caused me to fubar a merge the first time I tried.
Take note that after the merge, you will have files ending with .orig left on your system so you’ll have to manually delete them, unless you have the config mergetool..keepBackup set, but I haven’t tried this yet. Also, after the merge I was getting error messages about having a .git/MERGE_HEAD file, which I couldn’t find enough docs online for, so I just deleted it..and hopefully that did not fubar me.
Well that’s all for now. More might come as I learn to stop worrying and love the git.
P.P.S Many of these commands are not necessary if you use The Git Textmate Bundle and GitNub which integrate together and work very well!
]]>
			http://yanpritzker.com/2008/04/22/useful-git-commands-and-quirks/feed/
		9
		
		
		
		http://yanpritzker.com/2007/08/16/mailapp-quickfind-your-reply/
		http://yanpritzker.com/2007/08/16/mailapp-quickfind-your-reply/#comments
		Thu, 16 Aug 2007 02:03:02 +0000
		yan
				

		http://skwpspace.com/2007/08/16/mailapp-quickfind-your-reply/
		
			 Maybe I’m just obtuse but I accidentally discovered this awesome Mail.app feature today only after a year of using it :-). You know the little arrow that indicates that you replied to an email? Well it turns out it’s not just an indicator…if you mouse over it, it highlights and clicking on it takes you right to the reply you sent. 

]]>
			http://yanpritzker.com/2007/08/16/mailapp-quickfind-your-reply/feed/
		0