## Design Document Guidelines #

Please use the following format for your Gitlet design document. We suggest that your design document be written in Markdown, a language that allows you to nicely format and style a text file. Organize your design document in a way that will make it easy for you or a course-staff member to read.

## Design Overview #

1. How is your .gitlet directory structured? What files / classes are you using to represent your repository state, and what information is contained in these files / classes?
2. What is the process of adding a file then committing? How does your .gitlet directory change after adding; then after committing?
3. How does your design support operations that rely on branches? You should explicitly account for branch, checkout [branch name], and reset. Note: even though branches are not part of the checkpoint, we strongly encourage thinking about them earlier – you have a default branch, so your branch representation does actually affect your checkpoint implementation!

## Serialization and Persistence #

Provide three (3) distinct sequences of commands. You must make sure to provide:

• What are the specific commands?
• What happens in the file system between each command? (i.e. are files created? Updated? Deleted?)
• To execute each command, what persisted information is necessary? Where do you get it from?
• How does your program perform the logic of the command? Describe your algorithm in detail, and the updates you make to your data structures and objects.
• After the command finishes, what persisted information needs to be updated so that future commands work appropriately?

Try to cover a variety of sequences of commands here. Feel free to abbreviate repetitive steps, though you should lay it out explicitly at least once.

## Example #

To illustrate all this, we’ve created a sample design document for the Capers lab. The format is slightly different because Capers is not Gitlet.