Like any text added into the Manual, you should always spell check! Note that "aspell check filename.tex" is an effective spellchecker on CSL supported machines and will automatically ignore TeX commands. If you use Vim or Emacs, {link: http://toddshobbies.blogspot.com/2008/01/easy-spell-checking-with-latex.html Todd's Geek Blog shows how to spell check on the fly} just like MS Word.
 
-{subsection:What's the right branch of the manual for my change?}
+{subsection:What is the right branch of the manual for my change?}
 
 See SourceCodeBranches - typically it should go in the same branch as the corresponding code.
 
 {subsection:Does my code change really need a corresponding version history entry?}
 
-In general, the answer is 'yes'.  The only things that should NOT be in the history are:
+In general, the answer is 'yes'.  The only things that should *not* be in the history are:
 
 *: Bug fixes to bugs that were introduced between public releases.  e.g. 6.7.9 is out, you add a new features (which SHOULD be in the version history), your new feature breaks something else, you fix the new bug, we ship 6.7.10.  No need to document *that* bug fix, since no one ever saw the bug.
 
 *:Bug fixes to code that isn't being used, but someday might (e.g. defensive programming).
 
-*: Anything that there's no way a user or admin could know you changed.  For example, you had to refactor a bunch of code to make something shared for another use (the other use probably needs an entry, but the code refactoring does not), or to make it more maintainable.  You added a big comment to the source to explain something confusing.  You fixed the build system to add -Wall to our compiler flags.  You made some part of the code slightly more efficient/scalable without changing semantics of how people use it (of course, significant scalability improvements should be noted).
+*: Anything that there is no way a user or administrator could know you changed.  For example, you had to refactor a bunch of code to make something shared for another use (the other use probably needs an entry, but the code refactoring does not), or to make it more maintainable.  You added a big comment to the source to explain something confusing.  You fixed the build system to add -Wall to our compiler flags.  You made some part of the code slightly more efficient/scalable without changing semantics of how people use it (of course, significant scalability improvements should be noted).
 
 *: New features that we specifically do NOT want to be user-visible.  e.g. "BIOTECH=true" was never (and should never be) documented in the manual, even the version history.
 
 
-{subsection:What if i don't know LaTeX?}
+{subsection:What if I don't know LaTeX?}
 
 Any staff member who does know latex would be happy to help you get your version history into the Manual.  You can always ask Karen for help. In the long term, however, plan on learning LaTeX as at least all members of the core development team are expected to also be capable of documenting their changes in the Manual.
+
+{subsection:Using Git to determinine where version history goes}
+
+This is pretty easy, if the Gittrac ticket number is in the corresponding commit message.
+
+First, you find which commits holds the relevant ticket: so to find the commits pertaining to #2004, you do
+
+{code}
+git log --oneline --grep=2004 --all
+{endcode}
+
+This will produce a list:
+
+{code}
+85bad3f Ticket #2004: Update param table w/SHADOW_RUN_UNKNOWN_USER_JOBS
+14f8eed Ticket #2004: Allow priv switching on shadow to nobody when SHADOW_RUN_UNKNOWN_USER_JOBS=TRUE.  By default it is off.
+<Irrelevant stuff...>
+{endcode}
+
+From this log, it looks like =85bad3f= and =14f8eed= are the relevant commits, and there are others listed that are not pertinent.  (If the ticket numbers are not in the commit message, the =git log= command is useless for this.)
+
+Now you can do
+
+{code}
+git branch -a --contains 85bad3f
+{endcode}
+
+which produces the list
+
+{code}
+<Snipped, for brevity>
+remotes/origin/V7_6-winslotuser-publicbranch
+remotes/origin/V7_6_1-branch
+remotes/origin/V7_6_2-branch
+remotes/origin/V7_7-allow_cleanup_final_dag_node-branch
+<Again snipped for brevity>
+{endcode}
+
+Thus it appears the feature introduced in #2004 was first released in 7.6.1.
+
+Old branches get 'bag-and-tag'-ed: the branches are moved from =/refs/heads= to =/refs/tags=, and suffixed with "=-tag=".  You can use =git tag --contains= instead of =git branch --contains= above to find the tags that contain the commit.