A collection of git recipes to do common git tasks.

• Introduction
• Excluding file(s) from git-cl, while preserving them for later use
• Method #1: Reset your current branch, and selectively commit files.
• Method #2: Create a new branch, reset, then commit files to preserve
• Method #3: Cherry pick changes into review branches
• Sharing code between multiple machines
• Reverting and undoing reverts

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.

1. git log # see the list of your commits. Find the hash of the last commit before your changes.
2. git reset --soft abcdef # where abcdef is the hash found in the step above.
3. git commit <files_for_this_cl> -m "files to upload" # commit the files you want included in the CL here.
4. git checkout -b new_branch_name origin/trunk # Create a new branch for the files that you want to exclude.
5. 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.

1. git checkout -b new_branch_name # This preserves your old files.
2. git log # see the list of your commits. Find the hash of the last commit before your changes.
3. git reset --soft abcdef # where abcdef is the hash found in the step above.
4. 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.

1. Make and commit a set of independent changes.
2. git log # see the hashes for each of your commits.
3. repeat checkout, cherry-pick, upload steps for each change1..n
1. git checkout -b review-changeN origin # create a new review branch tracking origin
2. git cherry-pick <hash of change N>
3. 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.

1. git checkout <working branch>
2. Make changes.
3. If the commit you want to update is the most recent one:
1. git commit --amend <files>
4. If not:
1. git commit <files>
2. git rebase -i origin # use interactive rebase to squash the new commit into the old one.
5. git log # observe new hash for the change
6. git checkout review-changeN
7. git reset --hard # remove the previous version of the change
8. cherry-pick <new hash of change N>
9. git cl upload

Sharing code between multiple machines

Assume Windows computer named vista, Linux one named penguin.

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

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.)