Repo Local Todos
09 Apr 2024 - Ben
Not all software I write is very collaborative. Many hobby projects I start are just me writing a project, or part of one, to learn a new concept or scratch some itch I can’t at work. There’s not as much structure around these projects, but as they start to grow, I have ideas about things I want to do in them that I don’t have time for right now. Every project has a README, so I use some github-flavored markdown to include some checkboxes in a list of things I wanted to get done, eventually. That saves it right in the repo and I have it as a reference for later, without going out to another tool.
I can never remember where I leave those tools, and don’t always open them when I’m working on hobby projects anyway.
The Problem
As a professional programmer, I’m competent with git, so I branch my repo to explore and complete my different todos. Then I can merge (or often rebase) back into my stable branch for deployment. Git is a wonderful tool for this, of course, but I start running into issues with my README!
I write down the todos in my README whenever the inspiraiton strikes me. I usually put my new todos in a separate commit, but I check off todos in the same commit I complete the work in; both put me in an awkward situation with git. In two branches I’ll have added two todos on the same line and git doesn’t know what to do! It gives me a merge conflict and leaves my otherwise painless merge/rebase in a seeming state of disarray. See, my code doesn’t conflict, just the README file!
The Solution
While working through some other, code related, merge conflicts at work the other day, I realized that git is much better about these merges at the file level. If I add two files in the same directory, git will just add them both in the final merge too. If I model each todo as a file, then adding todos is as easy and merge free as adding files as long as I plan on storing them in my repo with git anyway.
If I delete and edit todos in different branches then I’ll have merge conflicts. But deletion will only happen when I’m done with the task, which will only happen in one branch since my branches focus on my todos. This also means that any deletions can theoretically supersede any changes; maybe those changes became a new todo, but if a todo file is deleted then it’s done.
An Extension, collaborating with others
Theoretically, I could collaborate with others using this same system. All the above applies with more than one person; I’m hardly even using a thin layer over git itself. But I think coordinating work would be hard. In my branch I’m “assigned” Todo A, but I made that change after you branched off. If you start doing that work also before merging in our shared branch when I’ve assigned it to myself, we may end up both doing the same work! With a little bit of git discipline, I still think it’s possible; maybe there’s a todos branch that you could cheaply merge in any time because the todos are so conflict-free. Maybe you’re only really considered assigned that work if the patch is in that branch. It wouldn’t necessarily require a central repository (like github or gitlab) to take advantage of either, just sending the todos branch patch to everyone could work as well.