/git .DS_Store
2.1: A classmate is supposed to run this method to create a Git repository. Inside the git directory, there is an objects directory and two filed (HEAD and index). The method initializeGit() initializes the repository and is the only method used. A challenge encountered was creating nested directories. If all of the files/directories exists, it will print "Git Repository Already Exists" in the console. If not, it will print "Git Repository Created" in the console.
2.1.1: Added a tester class called GitTester. The methods in it include verifyRepo, cleanUp, and a main. The verifyRepo method is a void static method that checks if all directories and files are made. If they are, it prints "All files and directories exist" in the console. If not, it goes through each directory and file that should be made and verifies whether or not they exist. The edge cases considered were whether the intended directory/file is actually a directory/file, and not a file/directory. The cleanUp method is a void static method that recursively deletes every file and directory in the git directory. Then to ensuring robust functionality, the initializeRepo method in the Git class, verifyRepo method, and cleanUp method are ran 300 times.
2.2: Added a new method called hashSHA1 that generates a SHA-1 hash string for any given file content. The SHA-1 hash acts as a unique identifier for the content, which is similar to how Git tracks files internally. It takes a string that is supposed to represent the file's content as its input, uses Java's MessageDigest class with the SHA-1 algorithm to compute a cryptographic hash, converts the raw byte output of SHA-1 into a hexadecimal string using BigInteger, and then pads the result so its always 40 char long (the standard length of a SHA-1 hash).
2.3: I implemented the createBlob(File input) method to store file contents as Binary Large Objects (BLOBs). The method reads the content of a file, generates a SHA-1 hash using the existing hashSHA1() function, and creates a new file inside the git/objects directory named after that hash. The original file’s contents are then written into the new blob file, ensuring that identical files always map to the same hash. I updated the tester to create a sample file, run createBlob(), and confirm that a blob with the expected hash was created in the objects directory. A challenge I faced was handling the case where the objects directory did not exist, which I fixed by adding a safeguard that creates the directory before writing blobs.
2.3.1: In this stretch goal, I extended the functionality of my Git-like system to verify that blob files exist in the objects directory and to support repeated testing. I implemented the method verifyBlob(String content), which calculates the SHA-1 hash of a given content string and checks if a file with that hash exists inside git/objects. This provides a programmatic way to confirm blob creation rather than just checking manually. I also added resetRepo() to the tester, which cleans up the entire git directory and reinitializes it, making it possible to run blob creation and verification tests multiple times in a row. These additions ensure that the blob system is more robust and can be tested reliably across different scenarios.
2.4: I added a new method called addToIndex(File input) that updates the repository’s index file. The method first calls createBlob() to ensure the file’s contents are stored in the objects directory. Then it computes the SHA-1 hash of the file and builds an entry in the form . The method checks the existing index file line by line: if the file is already tracked with the same hash, it prints a message and does nothing; if the file name is present but the content has changed, it replaces the old hash with the new one; if the file is brand-new, it appends a new entry. I tested this by adding files, re-adding them without changes, and updating them with new content to confirm the index is updated correctly. This simulates how Git keeps track of file versions between commits.
2.4.1: I extended my tester to act as a comprehensive test suite for the index file. I created a helper method testIndexWithFile(String filename, String content) that writes sample content into a file, adds it to the index using addToIndex(), and then verifies both the blob creation and the index entry. The method checks that the SHA-1 hash of the file’s content matches the entry in the index file and that the corresponding blob exists in the objects directory. I then ran this helper with multiple sample text files containing different content, demonstrating that the system correctly tracks new files, avoids duplication, and updates entries when contents change.
2.4.2: I implemented a method resetRepoState() that restores the repository to a clean state for repeated testing. This method deletes all blob files from the git/objects directory, clears the contents of the git/index file, and removes all non-Java test files created during testing from the working directory. This ensures that only the Java source files remain intact, while all generated files are reset, allowing for consistent reruns of the test suite. I tested this by creating multiple text files, adding them to the index, and then calling resetRepoState() to confirm that the objects and index were cleared while my .java files remained.
3.1: In this milestone, I updated the addToIndex() method to improve how files are tracked in the index. The index now records each entry using a relative path instead of an absolute one and removes the “blob” prefix for cleaner formatting. The method also handles several edge cases: it ignores files that haven’t changed, adds identical files from different folders as separate entries, and updates the hash when a file’s content is modified. These updates make the program’s index system work more like Git’s real staging area, ensuring that all changes and file versions are tracked accurately.
3.2: I implemented the createTree(String directoryPath) method to generate tree objects that represent directory structures. Each tree file lists both files and subdirectories within a given directory. For every file, the method first ensures a corresponding blob object exists in git/objects and then adds an entry in the format blob . For every subdirectory, the method calls itself recursively to build that subdirectory’s tree and then adds a line referencing it as tree . After processing all files and folders, the method combines these entries into a single string, hashes it using SHA-1 to generate a unique identifier, and saves that string as a new tree file inside git/objects/. This process mirrors how Git internally represents directories as hierarchical structures made up of trees and blobs.
3.3: In this milestone, I implemented code that generates tree objects directly from the index file. The program creates a working list by copying the index and prefixing each entry with "blob". It then finds the deepest folder, groups the files inside it, and creates a tree file listing each entry. The directory is collapsed into a single tree line in the working list, and this process repeats until only a single root tree remains. Each tree file is stored in git/objects using its SHA-1 hash. The final root tree represents the full staged directory structure. I tested the process with multiple folders and verified that the working list collapses step by step and that all tree and blob objects appear correctly in the git/objects folder.