PNFS Git tree recipies
From Linux NFS
pNFS Git Tree Recipies
please use git version 1.5.0.2 or higher
Notes for the latest git tree
git clone git://linux-nfs.org/~bhalevy/linux-pnfs.git
The tree has two main branch: nfs41 and pnfs that are based one on top of the other while the master branch is kept in sync with linus' 2.6 tree.
git branch -r
origin/master
origin/nfs41
origin/pnfs
plus some other branches that may contain work in progress.
The tree also contains tags pointing at historical heads, kept for reference. This is useful for looking at or testing old versions of the tree, after the main branch were rebased or modified in any other way.
To get the list of relevant tags, try
git tag -l "*nfs*" (or "git tag -l nfs" in older git version, e.g. 1.5.2.x)
The main motivation behind this structure is maintaining clean patchsets for nfs41 and pnfs.
The qgit tool is highly recommended for browsing the tree structure, individual patches, or annotated files (a-la git blame).
For your patches you can create a local branch equal to a tracking branch, like
git checkout -b local-nfs41 origin/nfs41
and then create a branch off of it with
git checkout -b my-branch local-nfs41
Submit your patches into my-branch and organize them neatly using, e.g.,
git rebase --interactive to edit or squash your patches combined with git commit -a --amend to modify them if needed.
When you pull origin, use
git remote update
origin/nfs41 may change at this point if it was rebased or more patches were submitted to it.
To rebase your patches, you can run (long version):
# create a tag on the old head (for reference if you want to look at it later) git tag my-branch-old my-branch
# rename old baseline git branch -m local-nfs41 local-nfs41-old
# create new baseline git checkout -b local-nfs41 origin/nfs41
# do the actual rebase git rebase --onto local-nfs41 local-nfs41-old my-branch
After this point my-branch will be rebased on top of local-nfs41 (== new origin/nfs41) and my-branch-old (tag) will be based on top of local-nfs41-old (== old origin/nfs41)
To cleanup, run:
git tag -d my-branch-old git branch -D local-nfs41-old git prune
If you aren't interested in keeping track of the old version, you can just run (short version):
git tag local-nfs41 origin/nfs41 git checkout -b my-branch local-nfs41
# submit patches into my-branch...
git remote update git rebase --onto origin/nfs41 local-nfs41 my-branch git tag -d local-nfs41 git tag local-nfs41 origin/nfs41
---
If you keep several branch, I recommend to use git-rebase-tree, available here: http://git.linux-nfs.org/?p=bhalevy/git-tools.git;a=blob_plain;f=git-rebase-tree;hb=HEAD
Notes for the old 2.6.18.3 git tree
git clone git://linux-nfs.org/linux-pnfs.git
then edit .git/config and change to ssh.
We want to continue development on the prototype while keeping the sessions/pnfs split. Here's some basic git recipes for doing that.
Say your git tree looks like this:
git branch -r
origin/4.1-sessions
origin/HEAD
origin/master
The idea is to create your own parallel branches for 4.1-sessions and master to do your work in, and each day to update the origin/4.1-sessions and origin/master.
Contents:
1) working on your own copy of origin/master (pnfs + sessions).
2) working on your own copy of origin/4.1-sessions, and merging
results into master for testing.
3) updating your tree with patches committed by CITI.
1) working on your own copy of origin/master (pnfs + sessions)
Run "git fetch origin" first to make sure origin/master is up to date, then:
git checkout -b my-master origin/master
to be sure...
git branch
* my-master
then make changes to existing files if add a file
git add <filename>
if remove a file
git rm <filename>
when done,
git commit -a
(Note: it'll give you a chance to edit the commit message. The first line should be a *short* description of the patch (will be used as email subject line); skip a blank line then write at length with any other comments about the branch.) this commits the changes to your local tree.
to show last commit: (review the patch)
git show
compile, test.
create a patch for review:
git format-patch -n origin/4.1-sessions
(This tells it to produce patches for all commits on your current branch ("my-sessions") that aren't in origin/4.1-sessions--so that's all the commits you've made. Maybe just one in the example above.)
NOTE: SAVE THOSE PATCHES!
mail to the list
git send-email --to pnfs@linux-nfs.org --from <yourself> <filelist from format patch>
note: the <filelist from format-patch> is usually 00*.
compile, test.
create a patch for review. (everything from the previous commit to this latest commit in my-master diff against origin/master)
git format-patch -n origin/master
NOTE: SAVE YOUR PATCHES!
mail to the list
git send-email -- to:pnfs@linux-nfs.org --from:<yourself> <filelist from format patch>
note: the <filelist from format-patch is usually 00*.
2) work on your own copy of origin/4.1-sessions
Run "git fetch origin" to make sure origin/4.1-sessions is uptodate, then:
git checkout -b my-sessions origin/4.1-sessions
to be sure...
git branch
* my-sessions
then make changes to existing files, git add, commit -a, and make a commit message as in step 1.
compile, test with NFSv4.1 (no pnfs)
Create patches for review, save them, and mail to the list as above.
Next, to merge your changes with your local origin/master (e.g the pnfs branch)
git checkout -b my-master origin/master
git merge 4.1-sessions
If you have conflicts due to the merge, it will tell you the file names. The conflicts will show up in files as arrows.
fix conflicts
git commit -a
(Note: git will automatically produce a commit message for you in this case. You can add comments if you want, but usually the message it creates is fine on its own.)
Please, if there were non-trivial conflicts, note merge changes and send them to the list to help us do the repeat the merge on the citi repo:
git show > <file>
email <file> to list...
(git format-patch doesn't deal with merge commits.)
the command
gitk v2.6.18.3.. &
will bring up a nice little browser and show the merge.
