Diff for "Freesurfer_github" - Free Surfer Wiki

Differences between revisions 27 and 28

Contents

Initial Setup
Committing Changes
1. Cleanup steps (Optional)
Developing
Data files

The official freesurfer source code repository can be found on the page:

https://github.com/freesurfer/freesurfer

Initial Setup

The initial setup for contributing to the freesurfer repository involves the user forking off the freesurfer GitHub repo, cloning the users fork into a local repository, then adding the freesurfer repository as an upstream remote. This setup is illustrated below, followed by a more detailed description of the steps involved:

Sign up for a github account if you don't already have one. When creating an account, you can use any email you want, but developers at the Martinos Center should eventually link their <username>@mgh.harvard.edu email to their GitHub account. This can be done after the account is created.
From your GitHub account, fork the freesurfer project repository by clicking on the 'Fork' button near the top right-hand of the page. This creates a copy of the freesurfer code base under your account on the GitHub server.
On your local machine, make a clone of your freesurfer repository (the one you forked):
```
git clone git@github.com:<git_username>/freesurfer.git
```
Add the main freesurfer repository as a remote to the local clone you already have on your local disk, and set it as the upstream remote:
```
git remote add upstream git@github.com:freesurfer/freesurfer.git
```

Type the following command to make sure you have the proper setup:

git remote -v

origin  git@github.com:zkaufman/freesurfer.git (fetch)
origin  git@github.com:zkaufman/freesurfer.git (push)
upstream        git@github.com:freesurfer/freesurfer.git (fetch)
upstream        git@github.com:freesurfer/freesurfer.git (push)

Committing Changes

To contribute the the freesurfer code base, users should create a new branch off the dev branch, push the branch to their fork (origin), then submit Pull requests into freesurfer/dev to get those changes into the freesurfer code base. This workflow is illustrated below, followed by a more detailed description of the steps involved:

When you start to make changes, the first thing to do is make sure you are in the dev branch and everything is up to date with the upstream repo:
```
git branch

* dev
```
```
git pull upstream dev
```
Then create a new branch (off dev) to hold your work and start making changes. Ideally, use a prefix signaling the purpose of the branch:
```
git checkout -b nf-my-feature
```
- nf- for new features
- bf- for bug fixes
- rf- for refactoring
- doc- for documentations contributions.
- test- for test related contributions.
Work on this copy on your computer using Git to do the version control. When you're done editing, commit the files to the local branch and push the branch to origin (your personal GitHub account):
```
git add <modified_files>
git commit -m "Commit message"
git push origin nf-my-feature
```
Finally, go to the GitHub web page of your fork of the freesurfer repo, and click Pull request to send your changes to the maintainers for review. Make sure you are submitting your newly created branch into the freesurfer/dev. This will send an email to the committers. You can commit new changes to this branch and keep pushing to your remote -- github automagically adds them to your previously opened Pull request.

Cleanup steps (Optional)

Once your pull request is accepted (you should get an email), feel free to delete the branch you created:
```
git branch -D nf-my-feature
```

Developing

Instructions on how to further work with the freesurfer source code, including building, testing, and adding a binary to the tree, should consult the Freesurfer Developers Guide:

https://surfer.nmr.mgh.harvard.edu/fswiki/DevelopersGuide_git

Data files

Data files represent a special case for source code repositories and generally speaking data files should not be stored in a source code repo. Rather they should be stored in a separate storage area, reserved for times when retrieval is required (e.g. updating test data, performing local installations, etc). Think of "source code" as files which are made up of text, are required for compilation, and can be easily inspected by the human eye (and diff'ed by the diff program). Think of "data files" as files stored as binary and not required for compilation.

A default clone of the repo will only give the user source code. Data files are stored in git annex, and exist as symlinks (by default), and need to be specially requested. They will look something like this:

ls -l testdata.tar.gz
  testdata.tar.gz@ -> ../.git/annex/objects/73/j9/SHA256E-s108571796--31df343ebab2d0f7f002f1d55c66100e23dc7eeacd4a8ede7723201ad09fd9b7.tar.gz/SHA256E-s108571796--31df343ebab2d0f7f002f1d55c66100e23dc7eeacd4a8ede7723201ad09fd9b7.tar.gz

The contents will be empty until specifically requested. To request a datafile, first add the remote repository that stores all the freesurfer data files:

(Users outside the Center)
git remote add datasrc https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/repo/annex.git
git fetch datasrc

(Users within the Center)
git remote add datasrc file:///space/freesurfer/repo/annex.git
git fetch datasrc

Then you can just specifically request whatever datafile you need:

git annex get GEMS2/Testing/test.txt.gz
  ########################################################################
  100.0%
    (checksum...) ok
    (recording state in git...)

Deletions are marked like this.	Additions are marked like this.
Line 129:	Line 129:
######################################################################## 100.0% (checksum...) ok (recording state in git...)	######################################################################## 100.0% (checksum...) ok (recording state in git...)