CSE 504: Compiler Design

The remote repository will be hosted on a CS department server (not github or a similar hosting service). We will not use outside services for homework submission. You are welcome to use such services for your own internal use, but homework submissions should be to the official remote repository.

Important!

Please read up on Git. There are tons of tutorials and introductions out there. The Pro Git book is a good resource; send me recommendations of other tutorials or documentation that you find especially helpful, and I'll update this space.

The purpose of the introductory paragraphs on Git is to introduce the notions of local and remote repositories, and working copy. This is in no way complete; see the book linked above!

Git is a distributed version control system. Earlier version control systems such as CVS and Subversion are centralized systems. In those systems, you typically have a local working copy, and a central repository, perhaps on a remote shared server. You can modify the local files to your heart's content, without connecting to the repository. You can bring in changes others have made to the repository by "updating" your working copy. An update may simply replace a file on your working copy if the file was unchanged in the working copy since the last update, or merge the changes with changes you may have locally made. To publish your changes to the repository, you do a "commit". The important point is that your working copy is local, and under your control. Changes are propagated only on commit. The repository is sacred and is has the authoritative versions. Repositories are typically maintained on remore servers. The version control system has sufficient controls to manage concurrent commits without clobbering the repository.

Git is different. As a distributed system, it has three places where things are kept: (1) your local working copy; (2) a local repository that is full-fledged and has all the information necessary to construct the entire update history of the files in its control; and (3) one or more remote repositories. You publish changes from the local working copy to the local directory by doing "commit". You sync the local and remote repositories by doing "push" (local to remote) and "pull" (remote to local).

Step 1: Send me information to prepare a remote repository for you.

1. The subject of the email should be your NetID (the username you use to log into blackboard). Note this is not your SOLAR id or the user id for the CS grad/undergrad machines. Do not include anything else in the subject line.

2. An attachment with your SSH public key. If you do not already have SSH keys, note that you can generate a public/private pair using ssh-keygen. See GitHub's Generating SSH Keys for more info.

   The public key will have a .pub suffix. Under no circumstance send me, or any one else for that matter, your private key!

   When you attach your public key to the email, please rename the attachment as netid.pub, where netid is your NetID (as in the email subject).

3. DO NOT EMAIL ME A CUT/PASTE VERSION OF PUBLIC KEY. THE MAILER MAY INSERT FORMATTING CHARACTERS THAT WILL CORRUPT IT. Please attach the key file as described above.

Step 2: Fill the team form.

Step 3: Clone.

1. On your local machine, go to the folder where you want to keep your local repository and working copy. If you already have homework files there move them away temporarily (this is done only once).

2. Execute the following:

   git clone ssh://git@allv22.all.cs.stonybrook.edu:130/REPONAME.git

   where REPONAME is your repository name.

Step 4: Get going with Git

1. Now you can add files to your local copy (use git add to tell git to track the added files), modify the local files, and when ready commit them to the (local) repository by doing git commit.
2. When ready to share the changes, do git push.