GitCookbook from google chromium
GitCookbook
http://code.google.com/p/chromium/wiki/GitCookbook
A collection of git recipes to do common git tasks.
-
- Introduction
- Excluding file(s) from git-cl, while preserving them for later use
- Sharing code between multiple machines
- Reverting and undoing reverts
- Retrieving, or diffing against an old file revision
- Checking out pristine branch from git-svn
- Making your git svn {fetch,rebase} go fast
- Reusing a Git mirror
Introduction
This is designed to be a cookbook for common command sequences/tasks relating to git, git-cl, and how they work with chromium development. It might be a little light on explanations.
If you are new to git, or do not have much experience with a distributed version control system, you should also check out The Git Community Book for an overview of basic git concepts and general git usage. Knowing what git means by branches, commits, reverts, and resets (as opposed to what SVN means by them) will help make the following much more understandable.
Excluding file(s) from git-cl, while preserving them for later use
Since git-cl assumes that the diff between your current branch and its tracking branch (defaults to the svn-trunk if there is no tracking branch) is what should be used for the CL, the goal is to remove the unwanted files from the current branch, and preserve them in another branch, or a similar.
Method #1: Reset your current branch, and selectively commit files.
- git log # see the list of your commits. Find the hash of the last commit before your changes.
- git reset --soft abcdef # where abcdef is the hash found in the step above.
- git commit <files_for_this_cl> -m "files to upload" # commit the files you want included in the CL here.
- git checkout -b new_branch_name origin/trunk # Create a new branch for the files that you want to exclude.
- git commit -a -m "preserved files" # Commit the rest of the files.
Method #2: Create a new branch, reset, then commit files to preserve
This method creates a new branch from your current one to preserve your changes. The commits on the new branch are undone, and then only the files you want to preserve are recommitted.
- git checkout -b new_branch_name # This preserves your old files.
- git log # see the list of your commits. Find the hash of the last commit before your changes.
- git reset --soft abcdef # where abcdef is the hash found in the step above.
- git commit <files_to_preserve> -m "preserved files" # commit the found files into the new_branch_name.
Then revert your files however you'd like in your old branch. The files listed in step 4 will be saved in new_branch_name
Method #3: Cherry pick changes into review branches
If you are systematic in creating separate local commits for independent changes, you can make a number of different changes in the same client and then cherry-pick each one into a separate review branch.
- Make and commit a set of independent changes.
- git log # see the hashes for each of your commits.
- repeat checkout, cherry-pick, upload steps for each change1..n
- git checkout -b review-changeN origin # create a new review branch tracking origin
- git cherry-pick <hash of change N>
- git cl upload
If a change needs updating due to review comments, you can go back to your main working branch, update the commit, and re-cherry-pick it into the review branch.
- git checkout <working branch>
- Make changes.
- If the commit you want to update is the most recent one:
- git commit --amend <files>
- If not:
- git commit <files>
- git rebase -i origin # use interactive rebase to squash the new commit into the old one.
- git log # observe new hash for the change
- git checkout review-changeN
- git reset --hard # remove the previous version of the change
- cherry-pick <new hash of change N>
- git cl upload
Sharing code between multiple machines
Assume Windows computer named vista, Linux one named penguin. Prerequisite: both machine have git clones of the main git tree.
vista$ git remote add linux ssh://penguin/path/to/git/repo
vista$ git fetch linux
vista$ git branch -a # should show "linux/branchname"
vista$ git checkout -b foobar linux/foobar
vista$ hack hack hack; git commit -a
vista$ git push linux # push branch back to linux
penguin$ git reset --hard # update with new stuff in branch
Note that, by default, gclient sync will update all remotes. If your other machine (i.e., penguin in the above example) is not always available, gclient sync will timeout and fail trying to reach it. To fix this, you may exclude your machine from being fetched by default:
vista$ git config --bool remote.linux.skipDefaultUpdate true
Reverting and undoing reverts
Two commands to be familiar with:
- git cherry-pick X -- patch in the change made in revision X (where X is a hash, or HEAD~2, or whatever)
- git revert X -- patch in the inverse of the change made
With that in hand, say you learned that the commit abcdef you just made was bad.
Revert it locally:
$ git checkout origin # start with trunk
$ git show abcdef # grab the svn revision that abcdef was
$ git revert abcdef
# an editor will pop up; be sure to replace the unhelpful git hash
# in the commit message with the svn revision number
Commit the revert:
# note that since "git svn dcommit" commits each local change separately, be
# extra sure that your commit log looks exactly like what you want the tree's commit
# log to look like before you do this.
$ git log # double check that the commit log is *exactly* what you want
$ git svn dcommit # commit to svn, bypassing all precommit checks and prompts
Roll it forward again locally:
$ git checkout mybranch # go back to your old branch again, and
$ git reset --hard origin # reset the branch to origin, which now has your revert.
$ git cherry-pick abcdef # re-apply your bad change
$ git show # grab the rietveld issue number out of the old commit
$ git cl issue 12345 # restore the rietveld issue that was cleared on commit
And now you can continue hacking where you left off, and since you're reusing the Reitveld issue you don't have to rewrite the commit message. (You may want to go manually reopen the issue on the Rietveld site -- git cl status will give you the URL.)
Retrieving, or diffing against an old file revision
Git works in terms of commits, not files. Thus, working with the history of a single file requires modified version of the show and diff commands.
$ git log path/to/file # Find the commit you want in the file's commit log.
$ git show 123abc:path/to/file # This prints out the file contents at commit 123abc.
$ git diff 123abc -- path/to/file # Diff the current version against path/to/file
# against the version at path/to/file
When invoking git show or git diff, the path/to/file is not relative the the current directory. It must be the full path from the directory where the .git directory lives. This is different from invoking git log which understands relative paths.
Checking out pristine branch from git-svn
In the backend, git-svn keeps a remote tracking branch that points to the the commit tree representing the svn repository. The name of this branch is configured during git svn init. The git-svn remote branch is often named origin/trunk for Chromium, and origin/master for WebKit.
If you want to checkout a "fresh" branch, you can base it directly off the remote branch for svn.
$ git checkout -b fresh origin/trunk # Replace with origin/master for webkit.
To find out what your git-svn remote branch name is, you can examine your .git/config file and look for the svn-remote entry. It will look something like this:
[svn-remote "svn"]
url = svn://svn.chromium.org/chrome
fetch = trunk/src:refs/remotes/origin/trunk
The last line (fetch = trunk/src:refs/remotes/origin/trunk), says to make trunk/src on svn into refs/remote/origin/trunk in the local git checkout. Which means, the name of the svn remote branch name is origin/trunk. You can use this branch name for all sorts of actions (diff, log, show, etc.)
Making your git svn {fetch,rebase} go fast
If you are pulling changes from the git repository in Chromium (or webkit), but your your git svn commands still seem to pull each change individually from svn, your repository is probably setup incorrectly. Make sure the entries in your .git/config look something like this:
[remote "origin"]
url = git://git.chromium.org/chromium.git
fetch = +refs/heads/*:refs/remotes/origin/*
[svn-remote "svn"]
url = svn://svn.chromium.org/chrome
fetch = trunk/src:refs/remotes/origin/trunk
Here, git svn fetch will update the hash in refs/remotes/origin/trunk as per the fetch = line under svn-remote. Similarly, git fetch will update the same tag under refs/remotes/origin.
With this setup, git fetch will use the faster git protocol to pull changes down into origin/trunk. This effectively updates the high-water mark for git-svn. Later invocations of git svn {find-rev, fetch, rebase} will be be able to skip pulling those revisions down from the svn server. Instead, it will just run a regex over the commit log in origin/trunk and parse all the git-svn-id lines. To rebuild the mapping. Example:
commit 016d28b8c4959a3d28d2fbfb4b86c0361aad74ef
Author: mpcomplete@chromium.org <mpcomplete@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Mon Jul 19 19:09:41 2010 +0000
Revert r42636. That hack is no longer needed now that we removed the compact
location bar view.
BUG=38992
Review URL: http://codereview.chromium.org/3036004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52935 0039d316-1c4b-4281-b951-d872f2087c98
Will be parsed to map svn revision r52935 to commit 016d28b8c4959a3d28d2fbfb4b86c0361aad74ef. The parsing will generate a lot of lines that look like rXXXX = 01234ABCD. It should generally take a minute or so when doing an incremental update.
For this to work, two things must be true:
- The svn url in the svn-remote clause must exactly match the url in the git-svn-id pulled form the server.
- The fetch from origin must write into the exact same branch that specified in the fetch line of svn-remote.
If either of these are not true, then git svn fetch and friends will talk to svn directly, and be very slow.
Reusing a Git mirror
If you have a nearby copy of a Git repo, you can quickly bootstrap your copy from that one then adjust it to point it at the real upstream one.
- Clone a nearby copy of the code you want: git clone coworker-machine:/path/to/repo
- Change the URL your copy fetches from to point at the real git repo: git set-url origin http://src.chromium.org/git/chromium.git
- Update your copy: git fetch
- Delete any extra branches that you picked up in the initial clone: git prune origin