Git

From HalyardWiki

Internally, the master copy of Halyard lives in a Subversion repository. But the public repository, and all the Halyard developers, use git.

See also Advanced Git.

Contents 1 Checking out Halyard 2 Setting up hooks 3 Working on a branch 4 E-mailing patches 5 Getting more branches 5.1 Applying patches using git am

[edit] Checking out Halyard

You can check out a copy of Halyard using git clone:

git clone git://imlsrc.dartmouth.edu/halyard
cd halyard

To update the copy, run git pull:

git pull

Here are some useful commands. For more, see the git tutorial or An introduction to git-svn for Subversion/SVK users and deserters.

git log                                   # Show log
git log --pretty=oneline --abbrev-commit  # Summarize log
git branch                                # List branches.
git diff HEAD^..HEAD                      # Show latest patch
git diff $COMMIT_ID^..$COMMIT_ID          # Show patch for $COMMIT_ID

[edit] Setting up hooks

The standard .git/hook/pre-commit won't work with Halyard. First, comment out these lines:

if (/[ \t]$/) {
    bad_line("trailing whitespace", $_);
}

Then add this line at the top of the file, immediately after the big block comment and before the other code:

# Check the tree for various style problems.
if ! tools/checktree; then exit 1; fi

[edit] Working on a branch

Please note that this workflow has not yet been tested.

First, make sure that git knows who you are:

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Then, create a new branch to hold your feature.

git checkout -b my-new-feature

Next, edit some files, and add any new files that you need.

git add my-new-file.ss
git diff
git commit -a

A good git commit message looks like this:

Add my spiffy new feature

A long description of your patch goes here.  It may run for
several lines, and may include paragraph breaks.  It should be
hard-wrapped somewhere between 70 and 75 columns.

You should use the commit message to explain why this patch is
useful, and give some idea of how it works.

If you want to merge upstream changes into your local version of Halyard, you have two choices. If your git repository is private, you can run:

git checkout master
git pull
git checkout my-new-feature
git rebase master

(There may be a simpler way to do this.) If your git repo is public, then you need to use git merge. Note that the Halyard developers will not pull code from public git repositories that routinely rebase branches.

[edit] E-mailing patches

First, make sure that your e-mail preferences are set up reasonably. The following may work for you, but please feel free to check the git send-email man page.

git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git config --global sendemail.smtpserver smtp.example.com
git config sendemail.to "halyard-dev@iml.dartmouth.edu"

Next, run git log, and find the last revision ID before the patch series you want to send.

Now run:

git format-patch $REV_BEFORE_SERIES

Now examine the generated patch files, and make sure they're reasonable before sending them to the list.

git send-email 0001-first-patch.diff 0002-second-patch.diff...

[edit] Getting more branches

We have some extra git-svn information available in our repo:

git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch

To list the branches:

git branch -r

[edit] Applying patches using git am

If you're using BlitzMail, you'll need to save each e-mail message separately. Be sure to save as MIME, not text.

To apply the patches, run:

git am saved-email...

To commit to Subversion, you'll need to create a .git/authors file with lines of the following form:

svnlogin = Full Name <email@example.com>

Then you can call dcommit as follows:

# Does not preserve author information!
# Does not fetch new revisions with compatible commit IDs.
git svn dcommit -A .git/authors

OK, maybe this isn't a good idea yet.