Add git helper scripts and update Doc/Contributing
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 16 Mar 2016 17:40:10 +0000 (13:40 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 16 Mar 2016 17:40:10 +0000 (13:40 -0400)
This updates the Contributing guidelines, providing instructions and
examples for how to submit code to the mailing list, e.g. send-email and
request-pull.

Of the scripts/git files, contributors will be most interested in
git-checkpatch and git-akaros-request-pull.  All of the git scripts will
work as git subcommands if you put them in your PATH.  e.g.

$ git checkpatch master..my_branch

or

$ git akaros-request-pull master my_repo my_branch

akaros-request-pull is just like the request-pull, but with an added
github URL for those who want to look at the patches on the world wide
web.

The other scripts, such as track-review, are mostly useful for code
reviewers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
12 files changed:
Documentation/Contributing.md
scripts/git/README [new file with mode: 0644]
scripts/git/bashrc-git-compl [new file with mode: 0644]
scripts/git/config [new file with mode: 0644]
scripts/git/git-akaros-request-pull [new file with mode: 0755]
scripts/git/git-checkpatch [new file with mode: 0755]
scripts/git/git-track [new file with mode: 0755]
scripts/git/git-track-review [new file with mode: 0755]
scripts/git/git-untrack [new file with mode: 0755]
scripts/git/mbox-to-patches.sh [new file with mode: 0755]
scripts/git/post-am.sh [new file with mode: 0755]
scripts/git/pre-se.sh [new file with mode: 0755]

index fff84a5..84ba6cc 100644 (file)
@@ -1,6 +1,6 @@
 Akaros Contribution Policies
 ===========================
-**2015-04-27** Barret Rhoden (`brho`)
+**2016-03-14** Barret Rhoden (`brho`)
 
 Interested in contributing to Akaros?  This document covers coding standards,
 version control usage, and other contribution policies.
@@ -19,6 +19,9 @@ Contents
     - Oh No, I Committed and Pushed Something I Want to Change
     - Crap, Someone Reset a Branch I was Tracking!
     - What Happens When Two People `push -f`
+    - Before You Submit Patches: checkpatch
+    - How To Submit Patches: git send-email
+    - How To Submit Patches: git request-pull
 
 
 Licensing
@@ -35,6 +38,8 @@ All new code should be licensed "GPLv2 or later".
 You (or your employer) may retain the copyright to your contributions, if
 applicable.  We do not require copyright assignment.
 
+Your git 'Sign-off' indicates your agreement with these rules.
+
 
 Contribution Philosophy
 ---------------------------
@@ -60,9 +65,11 @@ Attacking people is not.
 
 Contribution Steps
 ---------------------------
+Contributing to Akaros is much like contributing to the Linux kernel.
+
 The short version of adding code to Akaros:
 + Email the list early and often
-+ Push to a remote branch (not master)
++ Send-email or push to your own repo/branch and request-pull
 + Get someone (brho) to shepherd your work
 + Fix up your commits until they are merged
 
@@ -76,22 +83,32 @@ applies cleanly to `origin/master`.  Sane, means there are not a lot of "oh wait
 this patch is wrong, reverting".  The patch series should tell a story of
 getting from A to B, where each patch is easily reviewable.
 
-Push your changes to a separate branch, and email the list asking for advice or
-review.  Someone, usually me, will shepherd your work, providing feedback and
-TODOs.  Name your branch something reasonable (e.g. `inferno-b` and
-`inferno-r`).  Your username is a suitable branch name, if you don't want to
-bother with a title.  If you do not have access to the `brho:origin/` repo, then
-push it somewhere else on github and email us your git remotes info.  The only
-people with push access are those I know personally.  As the group grows, that
-will not scale and people will need to start using their own repos.  For now, a
-central repo works fine.
-
-Thanks to git's fast and simple branching, we can work and rework on branches
-that are not master.  Reworking branches includes rewriting commits and git's
-history.  (See below for some git commands).  The general rule is that there is
-no expectation of stability in any branch other than master.  Those branches
-may be rebased without warning by people working on the branch.  You 'own'
-whatever branch you push.
+If your change is minor, like a bug fix, then feel free to just fix it and
+submit the patch; you don't need to ask before fixing a bug.
+
+Before you submit your patch, run scripts/checkpatch.pl on it.  Checkpatch has
+both false positives and false negatives, but at least run it and fix the
+obviously incorrect changes.  Email the mailing list if you have any questions.
+See below for how to use checkpatch.
+
+To submit your patchset, you have two options: git send-email or git
+request-pull.  Send-email will take each of your patches and send it to the
+mailing list.  Request-pull requires you to push your work to a branch in your
+own repo (probably on github), and it will output a block of text.  You then
+email that output to the mailing list with a suitable subject.  See below for
+how to do a send-email or request-pull.
+
+Once your patches or request-pull has been emailed to the list, someone, usually
+me, will shepherd your work, providing feedback and TODOs.  The TODOs usually
+consist of fixing commits, such that your patchset does not introduce errors at
+intermediate patches.  This means you will need to rewrite commits and git's
+history.  It is not enough to just add an extra commit on top of broken patches
+in your patchset. (See below for some git commands and examples).
+
+After you fixed a patchset, you send-email or request pull again, and you do so
+in response to your original email.  For request-pull, this is easy: you just
+hit reply to the first message.  For send-email, you use the --in-reply-to=
+option.
 
 In general, I prefer not to merge, but it may be necessary based on the age of
 the changed branch.  If we scale out and have various submaintainers, we'll
@@ -99,19 +116,32 @@ merge those branches into the main repo.  But at this point, the `brho:origin/`
 repo is a 'leaf' (the one and only leaf).  We'll hold off on merging until we
 have many leaves.
 
-For minor changes and bug fixes, just push them or email a patch.  Use your
-better judgement.
+If you bring in code from another project:
++ First add the code, unaltered if possible, in a single commit.  That commit
+must say where you got the code from, such as a URL, project name and version,
+etc.  Do not add the .c files to Kbuild yet.  Otherwise, you'll break the build.
+
++ Run spatch, if applicable, in a single commit.
+
++ Run clang-format, if applicable, in a single commit.  It's much easier to
+diagnose problems if spatch and reformatting was done before any other changes.
 
-When adding new patches to a branch, you should rebase your commits on top of
-the branch's latest commit, then do a fast-forward merge.
++ Add your own changes, such that it compiles.  This is the point where you add
+the .c files to Kbuild so that we actually build the files.
 
-Your commits should be of a reasonable size.  Try to isolate your commits to
+
+A few final notes:
++ You must sign-off your commits.
+
++ Your commits should be of a reasonable size.  Try to isolate your commits to
 logically consistent, easily verifiable changes.  Each commit should compile,
 but you don't want to change everything in one commit.
 
-If a patch relied on spatch, provide the commands or scripts used.
++ If a patch relied on spatch, provide the commands or scripts used in the
+commit message.  If the script is likely to be useful beyond your patch, then
+put it in scripts/spatch/ so we can reuse it or learn from it.
 
-Remember that someone other than yourself has to look at each of these
+Remember that someone other than yourself has to look at each of these
 commits.
 
 
@@ -120,10 +150,11 @@ Coding Standard
 Our coding standard is similar to the Linux kernel style (but with a tabstop of
 4), so when in doubt, do what they do.
 
-+ If you are bringing in code from a project other than Linux, run
-  `scripts/lindent.sh` on it.  Lindent isn't perfect, but it's close enough.
-  Linux code is usually fine (even with 8 space tabs), and lindent sometimes
-  does more harm than good on that code.
++ If you are bringing in code from another project other than Linux, such as
+Plan 9, run clang-format on it.  We have a format file in the root of the Akaros
+repo.  clang-format isn't perfect, but it's close enough.  Linux code is usually
+fine (even with 8 space tabs), and formatters sometimes do more harm than good
+on that code.  You can try clang-format for Linux code and see how it works.
 
 + You'll note that old code may lack the correct style, especially due to the
   large bodies of code from other systems involved.  Typically, we fix it when
@@ -186,7 +217,11 @@ Git Workflow
 ------------------------------------
 Git allows us to do a lot of cool things.  One of its primary purposes is to
 provide a means for us to review each others code.  In this section, I'll
-describe how I use git to make changes to Akaros.
+describe how I use git to make changes to Akaros and send those changes to the
+mailing list.
+
+There are a bunch of scripts and tools in scripts/git/.  I'll use some of them
+below.
 
 ### Setup
 
@@ -242,7 +277,9 @@ working directory.
 Take a look at things before you commit; see if you missed any files or added
 anything you don't want.
 
-`$ git commit`
+`$ git commit -s`
+
+The -s is to append your "Signed-off-by" line.
 
 Write a descriptive message, with a short, one-line summary first.  e.g.
 
@@ -294,13 +331,13 @@ Now you want to add some, but not all, of your changes to `monitor.c`:
 
 Select only the changes you want, then commit:
 
-`$ git commit  # write message`
+`$ git commit -s  # write message`
 
 Then make further commits:
 
 ```
-$ git add -p kern/src/monitor ; git commit
-$ git add -p kern/src/monitor ; git commit
+$ git add -p kern/src/monitor ; git commit -s
+$ git add -p kern/src/monitor ; git commit -s
 
 $ git push origin monitor-change
 ```
@@ -547,3 +584,112 @@ case, nothing).  Check out `git help push` for more info.
 
 Again, these techinques work well with small groups, but not for big branches
 like `origin/master`.
+
+
+### Before You Submit Patches: checkpatch
+
+scripts/checkpatch.pl is modified from Linux's checkpatch and takes a patchfile as input.  I wrote a wrapper script for it that operates on a branch: scripts/git/git-checkpatch.  I have it in my path, so I can call it like a git subcommand:
+
+```
+$ git checkpatch master..my_branch_head
+```
+
+That will generate the patches from master..my_branch_head and run checkpatch on each of them in series.
+If you don't have the git scripts in your path, you'll have to do something like:
+
+```
+$ ./scripts/git/git-checkpatch master..my_branch_head
+```
+
+Some developers have a checkpatch pre-commit hook.  It's a personal preference.  This [site](http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html) suggests the following:
+```
+       $ cat >.git/hooks/pre-commit
+       #!/bin/bash
+       exec git diff --cached | scripts/checkpatch.pl --no-signoff -q -
+       ^D
+       $ chmod 755 .git/hooks/pre-commit
+```
+If checkpatch throws false-positives, then you'll have to bypass the precommit hook with a -n.
+
+For more info on checkpatch, check out http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel.  We use it just like Linux.
+
+
+### How To Submit Patches: git send-email
+
+git send-email is a simple way to send patches.  It works from the command line
+and you don't need a github account or remote repo.
+
+Akaros is no different than Linux or any of a number of projects in our use of
+send-email.  For a good overview, check out:
+https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/.
+
+Here's the basics for Akaros:
+
+Use the config stub for sendemail in scripts/git/config to send emails to the mailing list.
+
+If your patchset consists of more than one patch, use the --cover-letter option.
+This will send an introductory email, called PATCH 0/n, in which you explain
+your patch a bit.  If you have just one patch, you don't need to bother with a
+cover letter.  Make the subject and message for the cover letter reasonably
+descriptive of your overall change.
+
+If you have a remote branch tracking your patchset and are not overwhelmed with
+git commands yet, you can put the output of scripts/git/pre-se.sh in the
+cover-letter email.  This provides a convenient github link to browse the changes.
+
+If you are using send-email to send new versions of a patch, do it in-reply-to
+your original email.  See git help send-email for an example.
+
+Here's an example.  Say I have a branch called 'vmm' and want to send the patches from master to it:
+
+```
+$ git send-email --cover-letter master..vmm
+```
+That sent emails to the mailing list, thanks to the config setting for sendemail.
+For your first time, you can send-email to yourself instead:
+
+```
+$ git send-email --to=you@gmail.com --cover-letter master..vmm
+```
+
+If you want to send a single patch from the tip of the vmm branch:
+
+```
+$ git send-email -1 vmm
+```
+
+For more info, check out:
++ git help send-email
++ https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/
++ http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel  
+
+
+### How To Submit Patches: git request-pull
+
+If you have a github account or any place where you can push a branch, you can
+use request-pull to submit a patchset.  We also have a custom version of
+request-pull that adds extra info into the output:
+scripts/git/git-akaros-request-pull.
+
+The usage is simple.  Make sure your branch is up to date on your repo, then do
+a request-pull.  'FROM' is the point from which your branch diverges from the
+Akaros mainline.  Usually, it'll be 'master'.
+
+```
+$ git push REPO BRANCH
+$ git akaros-request-pull FROM REPO BRANCH
+```
+
+Here's how I would do a request-pull for my example 'vmm' branch:
+
+```
+$ git akaros-request-pull master origin vmm
+```
+
+Then copy-paste the output into an email and send it to the mailing list.
+
+If you don't have scripts/git/ in your PATH, you can either:
+
+```
+$ ./scripts/git/git-akaros-request-pull master origin vmm
+```
diff --git a/scripts/git/README b/scripts/git/README
new file mode 100644 (file)
index 0000000..521ddeb
--- /dev/null
@@ -0,0 +1,20 @@
+These scripts are for working with Git with Akaros.
+
+You may want to copy the scripts to somewhere in your path, especially for the
+git-scripts.  Anything named git-foo that is in your path will be executable
+as:
+
+       $ git foo
+
+Some of the scripts expect you to run them from the root of the Akaros repo.
+Others use directories for storing patches.  You can override the location of
+those directories with an environment variable or just by editing your own copy
+of the scripts.
+
+If you'd like bash autocompletion for the git-foo commands, source the bashrc
+fragment in your setup.  You might need to relaunch a shell for them to take
+effect.
+
+The config file contains example git configs.
+
+Some of these scripts and configs are rather niche, YMMV.
diff --git a/scripts/git/bashrc-git-compl b/scripts/git/bashrc-git-compl
new file mode 100644 (file)
index 0000000..9150ee1
--- /dev/null
@@ -0,0 +1,33 @@
+
+_git_untrack ()
+{
+       _git_branch
+}
+
+_git_track ()
+{
+       local remote=""
+       local trim_remote=""
+
+       if [[ $cur =~ ^.+?/ ]]
+       then
+               remote=${BASH_REMATCH[0]}
+       fi
+
+       # We have no remote, let's get one and append the /
+       if [ -z "$remote" ]; then
+               __gitcomp_nl "$(__git_remotes)" "" "$cur" "/"
+               return
+       fi
+       # remove the / for the ls-remote
+       trim_remote="${remote::-1}"
+       remote_branches="$(git ls-remote --heads $trim_remote | grep -o '[^/]*$')"
+       # arg3: generate completion matches, should be current string minus remote/
+       __gitcomp_nl "$remote_branches" "$remote" "${cur#$remote}"
+}
+
+_git_track_review ()
+{
+       _git_track
+}
+
diff --git a/scripts/git/config b/scripts/git/config
new file mode 100644 (file)
index 0000000..312b563
--- /dev/null
@@ -0,0 +1,16 @@
+Example config for send-email with Gmail.  You can put this in
+akaros-repo/.git/config.
+
+If you use the same email account for multiple projects, you can put all of the
+settings except the 'to' in your global ~/.gitconfig file.
+
+[sendemail]
+       smtpEncryption = tls
+       smtpServer = smtp.gmail.com
+       smtpUser = YOUR_ADDRESS@gmail.com
+       smtpServerPort = 587
+       smtpPass = YOUR_PASSWORD
+       suppresscc = self
+       annotate = true
+       confirm = always
+       to = akaros@googlegroups.com
diff --git a/scripts/git/git-akaros-request-pull b/scripts/git/git-akaros-request-pull
new file mode 100755 (executable)
index 0000000..7bdefd8
--- /dev/null
@@ -0,0 +1,21 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Wrapper around git request-pull that adds in a github URL to view the
+# patchset
+
+OUTPUT=`git request-pull $*`
+LINEMATCH="----------------------------------------------------------------"
+
+if [ $? -ne 0 ]
+then
+       echo "$OUTPUT"
+       exit $?
+fi
+
+FROM_SHA=`git log --format=format:%h -1 $1`
+TO_SHA=`git log --format=format:%h -1 $2/$3`
+URL="https://github.com/brho/akaros/compare/$FROM_SHA...$TO_SHA"
+
+echo "$OUTPUT" | sed "/$LINEMATCH/aView this online at:\n$URL\n\n$LINEMATCH"
diff --git a/scripts/git/git-checkpatch b/scripts/git/git-checkpatch
new file mode 100755 (executable)
index 0000000..1fbd5d2
--- /dev/null
@@ -0,0 +1,31 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Runs checkpatch on a set of commits, (From, To].
+
+
+TMPDIR="${TMPDIR:-/tmp/fp-cp}"
+
+usage()
+{
+       echo "$0 <from>..<to>"
+       exit -1
+}
+
+if [ $# -ne 1 ]
+then
+       usage
+fi
+
+if [ ! -f ./scripts/checkpatch.pl ]
+then
+       echo "Run from the root of the Akaros repo"
+       exit -1
+fi
+
+mkdir -p $TMPDIR
+
+git format-patch -o $TMPDIR $1
+./scripts/checkpatch.pl $TMPDIR/*.patch
+rm $TMPDIR/*patch
diff --git a/scripts/git/git-track b/scripts/git/git-track
new file mode 100755 (executable)
index 0000000..a41d566
--- /dev/null
@@ -0,0 +1,40 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Tracks a branch in a remote repo.
+#
+# If the remote is already set up, then you only need to pass it remote/branch.
+# If the remote is new, you will need to pass the URL for the repo.
+
+
+usage()
+{
+       echo "$0 <remote>/<branch> [<url>]"
+       exit -1
+}
+
+if [ $# -lt 1 ]
+then
+       usage
+fi
+
+REMOTE=`echo $1 | cut -f 1 -d '/'`
+BRANCH=`echo $1 | cut -f 2- -d '/'`
+
+git remote | grep $REMOTE > /dev/null
+if [ $? -ne 0 ]
+then
+       if [ $# -ne 2 ]
+       then
+               echo "Remote $REMOTE not tracked yet and no URL passed"
+               echo "  Try again with the repo's URL or add the remote manually"
+               usage
+       fi
+       URL=$2
+       git remote add -t $BRANCH $REMOTE $URL
+else
+       git remote set-branches --add $REMOTE $BRANCH
+fi
+
+git fetch $REMOTE
diff --git a/scripts/git/git-track-review b/scripts/git/git-track-review
new file mode 100755 (executable)
index 0000000..c17b64c
--- /dev/null
@@ -0,0 +1,55 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Tracks a remote branch and runs checkpatch on the commits from the merge
+# point of master to the tip of the remote branch.
+
+PATCHDIR="${PATCHDIR:-../patches}"
+
+usage()
+{
+       echo "$0 <remote>/<branch> [<url>]"
+       exit -1
+}
+
+if [ $# -lt 1 ]
+then
+       usage
+fi
+
+if [ ! -f ./scripts/checkpatch.pl ]
+then
+       echo "Run from the root of the Akaros repo"
+       exit -1
+fi
+
+REMOTE=`echo $1 | cut -f 1 -d '/'`
+TO=`echo $1 | cut -f 2- -d '/'`
+
+git track $REMOTE/$TO $2
+
+if [ $? -ne 0 ]
+then
+       exit -1
+fi
+
+FROM=`git merge-base master $REMOTE/$TO`
+
+if [ $? -ne 0 ]
+then
+       echo "From failed; $FROM"
+       exit -1
+fi
+
+ls $PATCHDIR/*.patch 2>/dev/null
+
+if [ $? -eq 0 ]
+then
+       echo "$PATCHDIR has patches, remove and try again"
+       exit -1
+fi
+
+git format-patch -k -M -N -o $PATCHDIR $FROM..$REMOTE/$TO
+
+./scripts/checkpatch.pl $PATCHDIR/*
diff --git a/scripts/git/git-untrack b/scripts/git/git-untrack
new file mode 100755 (executable)
index 0000000..dae316a
--- /dev/null
@@ -0,0 +1,35 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Stops tracking a remote branch
+
+usage()
+{
+       echo "$0 <remote>/<branch>"
+       exit -1
+}
+
+if [ $# -ne 1 ]
+then
+       usage
+fi
+
+REMOTE=`echo $1 | cut -f 1 -d '/'`
+BRANCH=`echo $1 | cut -f 2- -d '/'`
+
+git remote | grep $REMOTE > /dev/null
+if [ $? -ne 0 ]
+then
+       echo "Remote $REMOTE not tracked at all!"
+       usage
+fi
+
+if [ "x$BRANCH" == "x" ]
+then
+       echo "No branch!"
+       usage
+fi
+
+git branch -dr $REMOTE/$BRANCH
+sed -i "/$REMOTE\/$BRANCH/d" .git/config
diff --git a/scripts/git/mbox-to-patches.sh b/scripts/git/mbox-to-patches.sh
new file mode 100755 (executable)
index 0000000..1cd75c2
--- /dev/null
@@ -0,0 +1,73 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Converts an mbox to a patch set.
+#
+# Mostly, it is just git mailsplit, but it also processes the patches to remove
+# a lot of the email headers and to rewrite any From: headers that were mangled
+# by the mail server.
+
+PATCHDIR="${PATCHDIR:-../patches}"
+
+usage()
+{
+       echo "$0 <mbox>"
+       exit -1
+}
+
+if [ $# -ne 1 ]
+then
+       usage
+fi
+
+MBOX=$1
+
+ls $PATCHDIR/*.patch 2>/dev/null
+
+if [ $? -eq 0 ]
+then
+       echo "$PATCHDIR has patches, remove and try again"
+       exit -1
+fi
+
+git mailsplit -o$PATCHDIR $MBOX > /dev/null
+cd $PATCHDIR
+for i in `ls`
+do
+       # Remove all the header crap above From:
+       FROMLINE=`grep -n "^From:" $i | cut -f 1 -d':' | head -1`
+       FROMLINESUB=$(( ${FROMLINE} - 1 ))
+       sed -i -e "1,${FROMLINESUB}d" $i
+
+       # Gmail sucks and rewrites some Froms.  We'll catch it and replace From
+       # with X-Original-From
+       ORIGFROM=`grep "^X-Original-From" $i`
+       if [ $? -eq 0 ]
+       then
+               ORIGFROM=`echo $ORIGFROM | sed 's/^X-Original-From:/From:/g'`
+               sed -i "/^From:.*/c$ORIGFROM" $i
+       fi
+
+       # Remove header crap before the first blank
+       # X- stuff
+       SPACELINE=`grep -n "^$" $i | cut -f 1 -d':' | head -1`
+       sed -i -e "1,${SPACELINE}{ /^X-.*/d }" $i
+
+       # List stuff
+       SPACELINE=`grep -n "^$" $i | cut -f 1 -d':' | head -1`
+       sed -i -e "1,${SPACELINE}{ /^List-.*/d }" $i
+
+       # space-indented stuff for the X and List headers
+       SPACELINE=`grep -n "^$" $i | cut -f 1 -d':' | head -1`
+       sed -i -e "1,${SPACELINE}{ /^ .*/d }" $i
+
+       # grep subject, remove [akaros], remove " [PATCH xxx] ", (matching anything
+       # other than a ], so we get only the first ]), then changes
+       # non-letters/nums to -
+       SUBJECT=`grep "^Subject:" $i | cut -f 2- -d':' | sed 's/\[akaros\]//' |
+                sed 's/^ *\[[^]]*\] //' | sed 's/[^[:alnum:]]/-/g'`
+
+       mv $i $i-$SUBJECT.patch
+done
+cd - > /dev/null
diff --git a/scripts/git/post-am.sh b/scripts/git/post-am.sh
new file mode 100755 (executable)
index 0000000..0be6f03
--- /dev/null
@@ -0,0 +1,37 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# I run this after doing a git am and after I am OK with merging.
+# 
+# Prints a blob of text describing the changes from (FROM..TO].
+# By default, it applies to master..origin/master, but you can override that.
+
+FROM="origin/master"
+TO="master"
+
+usage()
+{
+       echo "$0 [<from>..<to>]"
+       exit -1
+}
+
+if [ $# -gt 1 ]
+then
+       usage
+fi
+
+if [ $# -eq 1 ]
+then
+       FROM=`echo $1 | cut -f 1 -d '.'`
+       TO=`echo $1 | cut -f 3 -d '.'`
+fi
+
+FROM_SHA=`git log --format=format:%h -1 $FROM`
+TO_SHA=`git log --format=format:%h -1 $TO`
+
+echo "Merged to master at $FROM_SHA..$TO_SHA (from, to]"
+echo ""
+echo "You can see the entire diff with 'git diff' or at" 
+echo "https://github.com/brho/akaros/compare/$FROM_SHA...$TO_SHA"
+echo ""
diff --git a/scripts/git/pre-se.sh b/scripts/git/pre-se.sh
new file mode 100755 (executable)
index 0000000..fa72f94
--- /dev/null
@@ -0,0 +1,37 @@
+#!/bin/bash
+# Barret Rhoden (brho@cs.berkeley.edu)
+# Copyright 2016 Google Inc
+#
+# Spits out a blob of text describing a patchset.  I'll use this with
+# send-email's cover-letter for large patchsets.
+
+usage()
+{
+       echo "$0 <from>..<to>"
+       exit -1
+}
+
+if [ $# -ne 1 ]
+then
+       usage
+fi
+
+FROM=`echo $1 | cut -f 1 -d '.'`
+TO=`echo $1 | cut -f 3 -d '.'`
+
+FROM_SHA=`git log --format=format:%h -1 $FROM`
+TO_SHA=`git log --format=format:%h -1 $TO`
+
+echo ""
+echo "------------"
+echo "You can also find this patch set at:"
+echo ""
+echo "git@github.com:brho/akaros.git"
+echo "From: $FROM_SHA"
+echo "To: $TO_SHA $TO"
+echo ""
+echo "And view them at: "
+echo ""
+echo "https://github.com/brho/akaros/compare/$FROM_SHA...$TO_SHA"
+echo ""
+echo "------------"