PNFS Git tree recipies

From Linux NFS

Revision as of 23:55, 11 September 2008 by BennyHalevy (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Personal tools