Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I use a similar system, but I duplicate and rename the file at the start of each day. Then I remove stuff that got done the previous day. Or stuff that is old and not relevant anymore.

The system has evolved over the years. The greatest thing about it is how flexible it is. When faced with new requirements (new projects, job change, etc) I can just start taking notes in a different way and see if it sticks.

I also commit it to git every 30 minutes using a cron script. Its awesome.



Doing the exact same thing using Obsidian and the obsidian-git plugin, which allows for automatic git push at a given interval. Works very well and it's very convenient to use.


Same setup here and pretty happy about it, only minor issue is the `Update time on edit` plugin creating some conflicts if I have my vault opened on two machines.


I don't usually take the time to write out a daily to-do list, but I do keep one for long-term projects that I tend to lose track of. Each line is a task and at the beginning of the line is the date it was initiated/requested. It's semi-structured but doesn't take any longer than typing out a note.

At the beginning of the month I duplicate the file and rename it for the new month, then I clean out just like you do.

I've tried apps, I've tried tracking systems, and this seems to work best for me for now. I can keep it open all the time in a tab of my text editor which I would have open anyway and it backs up with the rest of my files.


What are the benefits of keeping it in git? Are the commit messages useful?

Not trying to knock the idea, I just can't imagine branching or reverting or being curious about the history of a to-do list. Maybe it could be cool for statistics over time.

But I'm really curious to hear how you're using it!


I find that files under revision control have one awesome property:

they can be ruthlessly minimal.

The intermediate note-to-self stuff, the reference material, the stuff that was cancelled, all can be deleted.

But you have the peace of mind that you can get it back.

This might be especially important if it is a text file you run your life with.

My neighbor needs the name of the plumber we used. What was the amount of the bill? When did I order xyz last? What was the size of the wiper blades of my car?


> My neighbor needs the name of the plumber we used. What was the amount of the bill? When did I order xyz last? What was the size of the wiper blades of my car?

But how do you look that information up in git?


The git "pickaxe" [0] is the canonical way of searching through changes. Probably `git log -Splumber` with narrowing down by date.

[0]: https://git-scm.com/book/en/v2/Git-Tools-Searching


You can just search over all the diffs, that’s how I sometimes do it in Fork.app


I have a similar setup as far as git is concerned - I use it to push a backup of my Joplin notes (note that I don't sync multiple Joplins, just backup the current one).

Pros: pushes only the differences, keeps history, can be rolled back, works offline (push fails but commit works), offers a time log of changes.

Commit messages are not needed really - the timestamp is enough and rolling back is only for exceptional events (e.g. accidentally deleting important stuff, etc.).


It can also save you when you try a different sync solution, and you see in git status that it messed up the sync.


Synchronize between computers is easy and I can also use git client on my phone.

Hosting private repo on gitlab solves hosting.


This is exactly what I do, in Notational Velocity. One file per day, duplicate at the start of each day, with regular backups.

I mark completed items with a "+" and items I won't do with a "-".

Simple and works great!


I've landed on a similar process, but one file per sprint instead of one file per day.

I take the last sprint's file, save a copy for the new sprint, summarize what got done to report in sprint meeting, then add the tasks for the new sprint to present at the meeting as well.

Still have JIRA tickets to track tasks in a more formal way. But the text file is far more flexible and easier to quickly edit and view everything at a glance, as well as including things that don't fit cleanly in a ticket.


I used to do this but that made it harder to search on the occasion I'm looking for a prior note.

I do everything in vim and it's more keystrokes to search across separate files.

I've been using one file for 2-3 years now and it's only 1mb.


I do the same in vi/vim/neovim, in a custom filetype with syntax highlighting for TODO items, status markers, tags, code blocks, etc:

  "my/work/xxx/201810.notes" 34502L, 1946600B written
5.5 years on this particular file, but I've been using the same system for at least twice as long as that.

The datestamp is the most recent time I thought it might be useful to rotate into a new file. It was not! I find it much more convenient to have everything in a single topic-based file, although I do separate personal from work, and employers from each other.


Care to share your file format with some dummy entries?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: