Skip to content

sosh-ly/illeGITimate

 
 

Repository files navigation


illeGITimate

TABLE OF CONTENTS
  1. What is going on? What does everything mean?
  2. Tester
  3. Stretch Goals
  4. Tips
  5. How do I run the code?

What is going on? What does everything mean?

Hey, it's Miles. Please read this entire thing (on Github, not VSCode, so you get the nice formatting) so that you have a good idea about how IlleGITimate works. I probably haven't done things in the best way so the purpose of this README is to give you a good idea of how I thought about coding this project thus far. Hopefully this means you will have an easier time making changes!

The codebase of this project is broken up into individual .java files which each represent a core component of our Git recreation. Each class, at it's core, is a file path wrapped with extra functionality. Wrapping means each class contains a private File variable which it encloses:

  • Git.java represents the folder git
  • Objects.java represents the folder git/objects
  • Index.java represents the file git/index
  • Head.java represents the file git/HEAD

This means if you want to change something about the way the git/objects folder works, you should probably go to Objects.java.

For each class, I'll point out some important methods that I've made and also the general methodology I had when writing it.

(back to top)

Git.java

There's nothing really going on in this class since the folder git just stores everything.

(back to top)

Objects.java

There is slightly more stuff to look at in this file, but nothing that the code comments don't explain. Objects.java represents the directory which holds all the BLOBs. BLOBs are generated by:

public void addFile(File file) {}

(back to top)

Index.java

Alright, dial in for this one. On inspection, it makes sense that the index file should have the most code. After all, it has to be able to store, add, and delete lines of text. Not only that, but it must persist after code execution is completed and it must be able to read any lines of text that it begins with.

The most important part of index.java, and honestly the entire codebase, is the data structure storedFiles:

private HashMap<String, String> storedFiles

The gist of storedFiles is that (at runtime) it handles the following:

  1. Stores any (pathname, hash) key-value pairs which might be in the index
  2. Executes operations to add or remove key-value pairs. This represents adding or removing files from the index file.
  3. Whenever (2) happens, those changes are immediately written to the index file.

In this way, any operation done to the index file is first handled by storedFiles. This makes everything easier since modifying a HashMap is significantly easier to code than directly modifying a file with no intermediary data type.

(back to top)

Head.java

There's nothing going on in this class. I'm sure we'll have to add functionality for it at some point so when we have to, please update this README.

(back to top)

IlleGITimate.java

The purpose of this class is to coordinate all these classes and define methods like

public void commitFile(File file) throws IOException {
    // example code
    index.doSomething(file);
    objects.doSomething(file);
} 

which use methods from multiple classes to get things done. On its own, this class doesn't actually have any major functionality. It just calls a ton of methods from the subclasses.

The reason there are two constructors is so that you can specify a unique path for Git if you so choose. If you invoke the default constructor using

IlleGITimate a = new IlleGITimate();

Then the repository will appear in the enclosing folder starting with git. Meanwhile, if you invoke the constructor that requires a String argument:

IlleGITimate b = new IlleGITimate("gohere");

The repository will appear in the folder gohere starting with gohere/git presuming it exists already (the constructor won't create it for you).

(back to top)

Tester

The aptly-named IlleGITimateTester.java is what handles testing. There are a number of comprehensive tests defined within this class. Please feel free to add more tests.

Keep in mind, the tests

public static void testCommittingNewTextFiles(IlleGITimate test) {}

and

public static void testCommittingDuplicateTextFiles(IlleGITimate test) {}

have a ton of sub-tests within them. They also call test.clearRepository() at the end of their method call to clean the repository. If you wish to view the repository after those tests run, feel free to comment out this line. Just keep in mind that for the tests to run properly, everything has to be cleared so that the validation can run.

The edge cases that I tested so far have been if a non-existent file is being committed. Personally, I think throwing a FileNotFound exception is good.

(back to top)

Stretch Goals

In this project, there are a number of stretch goals. Since I don't think we've been following the naming convention in this Honors Topics class, I'll list out the methods where all the stretch goals have been accomplished. If you accomplish more stretch goals, please add to this!

Stretch Goal (GP-2.1.1) - Make a tester that does things

IlleGITimateTester.java

Stretch Goal (GP-2.3.1) - Confirm BLOBs exist and reset them

public static void testCommittingNewTextFiles(IlleGITimate test) {}

public static void testCommittingDuplicateTextFiles(IlleGITimate test) {}
public void clearRepository() {}

Streeeeeetch Goal (GP-2.3.2): (Optional) - Compression

haven't gotten to this one yet

Stretch Goal (GP-2.4.1) - BLOBing various text files

testTextFiles folder contains a few text files including duplicates

public static void testCommittingNewTextFiles(IlleGITimate test) {}

public static void testCommittingDuplicateTextFiles(IlleGITimate test) {}

Stretch Goal (GP-2.4.2) - Delete/clear methods

public boolean deleteRepository() {}

public boolean clearRepository() {}

(back to top)

Tips

Now that you've read everything above and (hopefully) understand the basics of how this project works, I have some tips/reminders.

  1. Use the "Go to Definition" button if you don't exactly know what a method does. To access it, right click on the method signature and it should pop up. It'll send you right to where the method is defined.
  2. If you add text files to testTextFiles, make sure to add them to the tests as well.
  3. Use relative paths when coding this project, it makes everything easier and portable.
  4. Don't worry about messing with lib, those are just .jar files that let generateSha1Hex(){} work. If you want to add more dependencies, drop the .jar files in there.
  5. Consider using the non-default constructor for testing.
  6. Please use File.separator instead of / within paths to ensure cross-compatibility going forward

(back to top)

How Do I Run the Code?

Hi! I put this at the end so that hopefully you've read everything above so that you know how the abominable code I made works. To run the code, edit src.java. You'll probably be mainly working in the tester class though.

(back to top)

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages

  • Java 100.0%