Skip to content

git_lite_test.md

Latest commit

 

History

History
55 lines (39 loc) · 3.56 KB

git_lite_test.md

File metadata and controls

55 lines (39 loc) · 3.56 KB
Raw

🎓 THE SIA EXAM: GIT-LITE INTERNALS (git_lite_test.md)

Welcome Golu to the Git-Lite conceptual check! This is to verify your systems-level database and VCU knowledge. Write your answers directly below each question, save the file, and ping me for evaluation.

📝 QUESTION 1: Content-Addressable Storage (CAS)

If you have two different files in your workspace—src/index.ts and dist/index.js—and both happen to contain the exact same string content (console.log("Hello");):

  1. How many blob files will be created inside .git-lite/objects/?
  2. How will the root tree object map these two files? Explain the relation between filenames, content, and hashes in CAS.

Ans. In the git lite we ignore the dist folder and some others too and the root tree onbject will only map the src/index.ts file.

🌳 QUESTION 2: Merkle Tree Propagation

Imagine a deeply nested file path: src/components/ui/button/styles.css. If you modify a single character in styles.css:

  1. Which objects (blobs, sub-trees, root tree) will get new SHA-1 hashes?
  2. Describe the bottom-up propagation of these hash changes up to the root tree returned by write-tree.

Ans. In my curr project status up till now it will create the new blob of all the src files snapshot instead of ignoring the not changed file.

  • Ok so as far as i understood the changes woul be if i changed in the bottom and then the bottom chnaged the weight and size of middle changed and bcz of that the top chnaged so please correct me in this

💾 QUESTION 3: Commit State vs History

A Git commit object contains two main pointers: tree <hash> and parent <hash>:

  1. What is the fundamental difference in what these two hashes represent?
  2. What would happen if we used the previous commit's tree hash instead of its commit hash as the parent pointer?

Ans. Tree hash is the hash of current blob that is deflated and parent hash and before this commit hash if their is commit that hash is parent hash

  • We will only get the code snapshot bcz tree hash only contains that but a commit hash the meta data realted to who, when and why of those changes.

🔖 QUESTION 4: References (Refs) Separation of Concerns

In your previous implementation, you mistakenly wrote the entire formatted commit metadata text into the branch ref file .git-lite/refs/heads/main:

  1. Why is this a major architectural separation violation in Git?
  2. What is the sole responsibility of a branch reference file, and how does it connect to the object database?

Ans. - Previously i thought that ref file is for the commit metadata to be saved but later i found it is for the last commit hash to be stored.

  • It sole res. is to store the commit hash and with that commit we can get the meta data and then with metadata the code snapshot.

🗜️ QUESTION 5: Object Headers & Null Bytes

In our Git-Lite CAS objects, we format the content by prepending a header (e.g., commit <size>\0 or blob <size>\0) before hashing and deflating:

  1. What is the purpose of the null byte (\0) separator?
  2. Why does Git include the object type and size inside the object content itself, instead of storing it as metadata in the filesystem?
  • \0 this is known as escape sequence that is used to create separation and it is exact 1 byte in buffer size
  • I think the reason is we can know what was the length of the snapshot before and now storing it in the commit metadata seems irrelevnat bcz meta data contains why how and when not how much the blob contains that.

Write your answers below each question, save this file, and let's see if you score a 10/10!