Notes on GlueX Git conversion

Notes on conversion from subversion to git for gluex.

  • What happens if a pull request has a conflict?
    • It cannot be merged on the github site. instructions on how to do it on the command line are available.
  • Should we use rebasing?
    • rebasing introduces possibilities for errors, commits are replayed on another branch, thus commits exist (in an operational sense) twice. Thus the admonition, do not rebase commits that exist outside your local repository. Pull requests generated on github satisfy this no-go situation for rebasing by construction. Rebasing an expert operation, IMHO.
  • How are we notified of pull requests
    • those interested in acting on pull should “watch” the appropriate repository. go to settings/notification to configure how you are notified. go to the repository page (after logging in) to mark the repository as being watched/not-watched/ignored by you using the pull down menu at the top of the page

Subversion to Git conversion notes

Names of repositories:

  • sim-recon
  • sim-recon-release
  • hdds
  • hdds-release

Proposed work flow:

  1. clone sim-recon
  2. create branch for development
  3. work on branch, checking in as you go
  4. push branch to github as branch of sim-recon
    1. never push to master branch at github
    2. you could do it, but don’t
    3. you need, at github
      1. an account
      2. have your account added to the gluex team
      3. previous steps do not require an account at github
  5. create a pull request on github for your new branch
  6. wait for your changes to be merged on the master at github
  7. pull your changes back on to your local master branch

admin group: Mark, David, Simon, Paul M., Justin, Sean

Conversion with author list

  • put author list in lorentz:/home/marki/.svn2git/authors
    • put script to generate: [?]
    • needed to add wolin, manak, weygand, jcummngs, bellis, futch, and (no author) by hand at end of script to succeed

old log entry:

lorentz:marki:BCAL> git log
commit 2dba218a8e140d53878b0be8eb5bac0031e15b3b
Author: wilevine
Date: Fri Sep 12 16:19:14 2014 +0000

Fix time calculation in DBCALShower_factory

new log entry:

lorentz:marki:BCAL> git log
commit 4169bd1bd4380e7814e0a13d49068cbfbbe4740b
Author: William Levine <>
Date: Fri Sep 12 16:19:14 2014 +0000

Fix time calculation in DBCALShower_factory

svn2git commands

svn2git file:///local/scratch/svn2git/svnroot --no-minimize-url --trunk trunk/sim-recon --branches branches --tags tags

or replace file:... with

git clone --bare file:///local/scratch/svn2git/sim-recon

Command to get all svn authors

svn log –quiet file:///local/scratch/svn2git/svnroot | grep “^r” | awk ‘{print $3}’ | sort | uniq | perl -n -e ‘print “=======”, $_; chomp; system “grep -s $_ /home/marki/.svn2git/authors”;’

Branch and Tag Filtering on Converted Git Repository

  • git branch | grep @ | xargs git branch -d
  • git branch | grep -v sim-recon | grep -v src | grep -v master | xargs git branch -d
  • git tag | grep @ | xargs git tag -d
  • git tag | grep -v sim-recon | grep -v release | grep -v src | grep -v master | xargs git tag -d

Random Notes

  • can svn repo be kept up to date from git?
  • can git repo be kept up to date from svn?
  • if so then dual repo transition period is possible
  • at end of latest svn2git got the following:

svn2git warning: Tracking remote SVN branches is deprecated.
In a future release local branches will be created without tracking.
If you must resync your branches, run: svn2git –rebase

Subversion to Git conversion

The magic command to convert from subversion to git:

svn2git $HDSVN --no-minimize-url -v --trunk trunk/home/marki/svn_test --nobranches --tags tags/home/marki

To prepare local repository for import to GitHub:

git clone --bare file:///home/marki/git_play/svn_import_test

Create new repository on GitHub to receive the bare clone.

To do the import, from the local host:

cd svn_import_test.git/
git push --mirror

Notes on Version Management System

copied from a long running gnote

  • do an eval to put environment definitions into environment, users can invent other schemes if they like
  • version.xml distribution
    • separate data from code repository
    • options:
      • new top level directory in repository
      • web page, distribution directory
      • standard “dist” directory
      • use standard “dist” directory for now
  • need perl-XML-Writer package on RHEL6
  • on lorentz, RHEL6, 64-bit, needed soft link to make in /usr/lib64
  • need the XML/ module on jlabl3