Blazing fast way of finding references to the current partial you’re viewing using this simple script. Requires git-grep.vim. Bonus: at the bottom of the script I also define “K” to git grep the current word. Very handy for fast function reference finding.

Like this post? Here are some more you might enjoy:

• Five ways to get insane productivity boosts
• Colorful ruby tests and debugging

Unfortunately I had to abandon the project due to lack of time, but the book remains alive, and is more or less accurate to the current version of git:

Please enjoy the book for free: The Git Workflows Book and feel free to comment on that page with your own thoughts, corrections, and favorite workflows.

Update: the url to the book is updated to a nicer format and ability to leave comments.

Update 2: I am mentioned on the Ruby 5 podcast! Thanks guys :)


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


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

What’s nice about GitHub is that first, it gives you an easy way to fork anyone’s codebase. The key feature of GitHub is fork network tracking, which lets you see everyone else who’s cloned a particular repo, and what changes they have made. The big benefit is that this prevents you from re-inventing the wheel when you see that someone is already working on the same feature you’re trying to submit. Instead of going and doing your own thing, you fork off of them and work with them. You might even fork off of a grandchild of the original project just because it has some feature that you need. It’s like the long tail of open source..you no longer have to wait for the original author to implement your obscure changes. Just find what you want out there and work with it.

The reciprocal benefit of this, of course, is that the original author can actually watch your changes as you’re making them. Instead of some disjointed patches, he sees your commits as you add them to your own line and can follow your progress visually. At some point, if the author likes your work he can merge your branch back into his code. And GitHub will show this on the network, so everyone else who is following the project can benefit. They’ve made it easy to notify the author that you have some good changes as well, with the pull request.

This very simple idea of tracking the forking network of a particular project, and doing it well, is why GitHub has made a radically cool contribution to the opensource community. Every day, more and more projects are added to the hub. And it’s viral…people who want to contribute to projects request that the project be put on GitHub because it’s the easiest way to track your contributions. Kudos to GitHub!

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/05/01/more-git-tips-and-tricks/
		http://yanpritzker.com/2008/05/01/more-git-tips-and-tricks/#comments
		Thu, 01 May 2008 21:05:51 +0000
		yan
				
		

		http://skwpspace.com/?p=147
		
			Here are a couple more fun git commands and configuration tricks.

Make some aliases because typing ‘checkout’ is a pain. In ~/.gitconfig:

Note the quicklog command below uses a custom log format which shows you a short hash, a relative date (“4 hours ago”) and the commit message. I created it by reading the git log formatting manpage.

[alias]
  ci = commit
  co = checkout
  b = branch
  nb = checkout -b
  stat = status
  sl = stash list
  sa = stash apply
  sd = stash drop
  quicklog = log --pretty=format:\"%h %cr %cn %Cgreen%s%Creset\"
  changes = log --pretty=oneline
  svnup = svn rebase
  svnpush = svn dcommit


I really love the ‘nb’ alias, which I use to mean ‘new branch’. It lets me very quickly create and switch to a new branch “git nb fixing_bug_123″.
Display the current branch in your bash prompt. Modified from here.

export MANPATH=/usr/local/git/man:$MANPATH
 function parse_git_branch {
   git branch 2> /dev/null | \
	sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1) /'
 }
export PS1='\u@\H:\w $(parse_git_branch)$ '

Get a nice list of change summaries, one line per change
git log --pretty=oneline --since="2 weeks ago" --until="yesterday"
See what changed from one commit set to another (these can be branch names)
git log my-branch..master
See which files changed in the log
git log --name-status
Browse your local repo with a web interface
git instaweb --httpd=webrick
Want to reorder previous commits, squash commits, and generally wreak havoc?

The following command opens up an interactive editor with the last 10 commits.
git rebase -i HEAD~10
]]>
			http://yanpritzker.com/2008/05/01/more-git-tips-and-tricks/feed/
		0
		
		
		
		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