[ << Working with source code ][Top][Contents][Index][ ? ][ Compiling >> ]
[ < Cleaning up multiple patches ][  Up : Advanced Git procedures ][]

3.4.9 Commit access

Most contributors are not able to commit patches directly to the main repository—only members of the LilyPond development team have commit access. If you are a contributor and are interested in joining the development team, contact the Project Manager through the mailing list (lilypond-devel@gnu.org). Generally, only contributors who have already provided a number of patches which have been pushed to the main repository will be considered for membership.

If you have been approved by the Project Manager, use the following procedure to obtain commit access:

  1. If you don’t already have one, set up a Savannah user account at https://savannah.gnu.org/account/register.php. If your web browser responds with an “untrusted connection” message when you visit the link, follow the steps for including the CAcert root certificate in your browser, given at http://savannah.gnu.org/tls/tutorial/.

    Note: Savannah will silently put your username in lower-case – do not try to use capital letters.

  2. After registering, if you are not logged in automatically, login at https://savannah.gnu.org/account/login.php—this should take you to your “my” page (https://savannah.gnu.org/my/).
  3. Click on the “My Groups” link to access the “My Group Membership” page. From there, find the “Request for Inclusion” box and search for “LilyPond”. Among the search results, check the box labeled “GNU LilyPond Music Typesetter” and write a brief (required) message for the Project Manager (“Hey it’s me!” should be fine).

    Note that you will not have commit access until the Project Manager activates your membership. Once your membership is activated, LilyPond should appear under the heading “Groups I’m Contributor of” on your “My Group Membership” page.

  4. Generate an SSH ‘rsa’ key pair. Enter the following at the command prompt: 
    ssh-keygen -t rsa

    When prompted for a location to save the key, press <ENTER> to accept the default location (‘~/.ssh/id_rsa’).

    Next you are asked to enter an optional passphrase. On most systems, if you use a passphrase, you will likely be prompted for it every time you use git push or git pull. You may prefer this since it can protect you from your own mistakes (like pushing when you mean to pull), though you may find it tedious to keep re-entering it.

    You can change/enable/disable your passphrase at any time with: 

    ssh-keygen -f ~/.ssh/id_rsa -p

    Note that the GNOME desktop has a feature which stores your passphrase for you for an entire GNOME session. If you use a passphrase to “protect you from yourself”, you will want to disable this feature, since you’ll only be prompted once. Run the following command, then logout of GNOME and log back in: 

    gconftool-2 --set -t bool \
  /apps/gnome-keyring/daemon-components/ssh false

    After setting up your passphrase, your private key is saved as ‘~/.ssh/id_rsa’ and your public key is saved as ‘~/.ssh/id_rsa.pub’.

  5. Register your public SSH ‘rsa’ key with Savannah. From the “My Account Configuration” page, click on “Edit SSH Keys”, then paste the contents of your ‘~/.ssh/id_rsa.pub’ file into one of the “Authorized keys” text fields, and click “Update”.

    Savannah should respond with something like: 

    Success: Key #1 seen Keys registered
  6. Configure Git to use the SSH protocol (instead of the GIT protocol). From your local Git repository, enter: 
    git config remote.origin.url \
  ssh://user@git.sv.gnu.org/srv/git/lilypond.git

    replacing user with your Savannah username.

  7. After your membership has been activated and you’ve configured Git to use SSH, test the connection with: 
    git pull --verbose

    SSH should issue the following warning: 

    The authenticity of host 'git.sv.gnu.org (140.186.70.72)' can't
be established.
RSA key fingerprint is
80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5.
Are you sure you want to continue connecting (yes/no)?

    Make sure the RSA key fingerprint displayed matches the one above. If it doesn’t, respond “no” and check that you configured Git properly in the previous step. If it does match, respond “yes”. SSH should then issue another warning: 

    Warning: Permanently added 'git.sv.gnu.org,140.186.70.72' (RSA) to
the list of known hosts.

    The list of known hosts is stored in the file ‘~/.ssh/known_hosts’.

    At this point, you are prompted for your passphrase if you have one, then Git will attempt a pull.

    If git pull --verbose fails, you should see error messages like these: 

    Permission denied (publickey).
fatal: The remote end hung up unexpectedly

    If you get the above error, you may have made a mistake when registering your SSH key at Savannah. If the key is properly registered, you probably just need to wait for the Savannah server to activate it. It usually takes a few minutes for the key to be active after registering it, but if it still doesn’t work after an hour, ask for help on the mailing list.

    If git pull --verbose succeeds, the output will include a ‘From’ line that shows ‘ssh’ as the protocol: 

    From ssh://git.sv.gnu.org/srv/git/lilypond

    If the protocol shown is not ‘ssh’, check that you configured Git properly in the previous step.

  8. Test your commit access with a dry run:

    Note: Do not push directly to master; instead, push to staging. See Pushing to staging. 

    git push --dry-run --verbose

    Note that recent versions of Git (Git 1.6.3 or later) will issue a big warning if the above command is used. The simplest solution is to tell Git to push all matching branches by default: 

    git config push.default matching

    Then git push should work as before. For more details, consult the git push man page.

  9. Repeat the steps from generating an RSA key through to testing your commit access, for each machine from which you will be making commits, or you may simply copy the files from your local ‘~/.ssh’ folder to the same folder on the other machine.

Technical details

Known issues and warnings

Encryption protocols, including ssh, generally do not permit packet fragmentation to avoid introducing a point of insecurity. This means that the maximum packet size must not exceed the smallest MTU (Maximum Transmission Unit) set in the routers along the path. This smallest MTU is determined by a procedure during call set-up which relies on the transmission over the path of ICMP packets. If any of the routers in the path block ICMP packets this mechanism fails, resulting in the possibility of packets being transmitted which exceed the MTU of one of the routers. If this happens the packet is discarded, causing the ssh session to hang, timeout or terminate with the error message 

ssh: connect to host <host ip addr> port 22: Bad file number
fatal: The remote end hung up unexpectedly

depending on precisely when in the proceedings the first large packet is transmitted. Most routers on the internet have MTU set to 1500, but routers installed in homes to connect via broadband may use a slightly smaller MTU for efficient transmission over ATM. If this problem is encountered a possible work-around is to set the MTU in the local router to 1500.

[ << Working with source code ][Top][Contents][Index][ ? ][ Compiling >> ]
[ < Cleaning up multiple patches ][  Up : Advanced Git procedures ][]

This page is for LilyPond-2.21.0 (development-branch).

We welcome your aid; please help us by reporting errors to our bug list.

<< Back to Documentation Index

LilyPond — Contributor’s Guide v2.21.0 (development-branch).