This content originally appeared on DEV Community and was authored by Steven Hur
For our second lab, we moved from reviewing code to actively contributing to a classmate’s repository. This wasn’t just about writing a new feature; it was a hands-on lesson in the structured, collaborative dance of open source development. My task: to add a –recent flag to a classmate’s “Repo-Context-Packager,” a Python tool that bundles project files for LLMs. This is the story of my first real Pull Request.
The Plan: Adding a “What’s New” Filter
My goal was to implement a –recent (and its shorthand -r) flag. When used, the tool would only package files modified within the last seven days. This seemed like a small feature, but it would require navigating the entire open-source workflow, from proposal to integration.
The Process: From Issue to Pull Request
Filing the Issue: Before writing a single line of code, I went to my classmate’s repository and filed an issue. I outlined the feature, explained its benefits, and proposed a potential usage (pack-repo.py . –recent). This step felt like knocking on the door before entering—it’s a crucial sign of respect for the project owner.
Fork, Clone, Branch: Once I got the green light, I forked the repository, creating my own copy to work in. After cloning it to my machine, I immediately created a new branch: git checkout -b feature/add-recent-flag. This kept my work isolated from the main branch, ensuring I wouldn’t break anything in the primary codebase.
The Pull Request: After coding and testing, it was time for the main event: my first Pull Request. This felt like submitting a formal proposal. I summarized my changes, explained how the new feature worked, and detailed how to test it. Most importantly, I linked the PR back to the original issue by including Fixes #[issue-number] in the description. Seeing that link connect the proposal to the solution was incredibly satisfying.
The Technical “Stuff”
Integrating this feature was a great learning experience with Python’s file system and date/time modules.
Handling Timestamps: The core of the feature was checking a file’s modification date. In Python, I used pathlib for this. The expression file_path.stat().st_mtime returns the modification time as a Unix timestamp (seconds since the epoch). To compare this, I used the datetime and timedelta modules. The logic was datetime.now().timestamp() – file_mod_time <= timedelta(days=7).total_seconds(). This reliably checked if a file was modified within the last week.
Integration Challenges: The biggest challenge was integrating this logic without making the existing code messy. The script had a function, write_struct_tree, that recursively walked the directory. I had to pass a new boolean parameter, recent_only, down through the function calls to tell the recursive part whether to apply the timestamp filter.
Handling Edge Cases: During testing, I discovered a classic bug: the script was including its own output file in the results! Because the script created output.txt before scanning the directory, output.txt was always the most “recent” file. I fixed this by passing the output filename to the file discovery function and explicitly skipping any file with that name.
Overall, moving from a solo coder to a contributor has been a huge step. This structured process of communication and review is what allows open-source projects to thrive.
This content originally appeared on DEV Community and was authored by Steven Hur