docs/internals/git-HOWTO.txt

   1 Introduction
   2 ------------
   3
   4 During the summer of 2017 the Valgrind source code repository was migrated
   5 from the Subversion source control system to the git source control system. In
   6 this document it is explained how to access the Valgrind git repository. For
   7 more information about the migration process, see also Ivo Raisr,
   8 Migrating Valgrind sources from SVN to GIT, valgrind-developers mailing list,
   9 June 16, 2017
  10 (http://valgrind.10908.n7.nabble.com/Migrating-Valgrind-sources-from-SVN-to-GIT-td57939.html).
  11
  12 Valgrind Users
  13 --------------
  14
  15 Valgrind users can clone the Valgrind source code repository as follows:
  16
  17 git clone https://sourceware.org/git/valgrind.git/
  18
  19 Valgrind Developers
  20 -------------------
  21
  22 Anyone who has been granted write access to the Valgrind repository on the
  23 sourceware server has been assigned a user name on that server
  24 (${swusername}). Read/write access to the Valgrind source code
  25 repository can be enabled as follows:
  26 * If you have not yet cloned the Valgrind git repository, run the following
  27   command:
  28   git clone ssh://${swusername}@sourceware.org/git/valgrind.git
  29 * If you have already cloned the Valgrind git repository, run the following
  30   command:
  31   git remote origin update ssh://${swusername}@sourceware.org/git/valgrind.git
  32
  33 Note: the ${swusername}@ part can be left out from the repository URL if the
  34 following information is added to $HOME/.ssh/config:
  35
  36 Host sourceware.org
  37         User ${swusername}
  38
  39 Preparing and publishing changes
  40 --------------------------------
  41
  42 For small changes, create a branch in your local repository and prepare the
  43 changes as one or more patches. Before publishing the changes, run git pull
  44 --rebase, resolve any rebase conflicts if needed, retest if necessary, and
  45 publish the changes by running git push HEAD:master. If anyone else has
  46 published changes after the rebase and before the push then the push will fail
  47 and the rebase, retest and push steps will have to be repeated.
  48
  49 For large changes, create a branch in your local repository and prepare the
  50 changes as a series of patches. Once all changes are ready, switch to the
  51 master branch, update it by running git pull --rebase, merge your branch with
  52 the master branch and publish the changes by running git push master. If
  53 anyone else has published changes after the update and before the push step
  54 then the push will fail and the update, merge and push steps will have to be
  55 repeated.