Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Grit – a multitree-based personal task manager

github.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Show HN: Grit – a multitree-based personal task manager

#31

Post by zie »

woofie11 wrote: post #27
climech wrote: post #5

Earlier quoted context omitted.

Just SQLite - two tables, one for the nodes, one for edges + some fancy constraints and queries. I was tempted to make a custom binary format, but that's a big task, and it seems to work fine as it is. As for the syncing, that would be really nice, but I haven't come up with an elegant way to do it yet. Suggestions welcome, if anyone has ideas!

git. The right storage backend is either git, or a git-like Merkle tree. This is small data. Individual files for objects are fine. Compacting is better, but not critical. You can write git in a weekend or two: https://wyag.thb.lt/ sqlite is the wrong tool for the job, beyond an initial prototype. git and hg figured this stuff out decades ago. Good job, by the way. This seems like the sort of thing which, if: * it di…

You aren't technically wrong, I guess, but Fossil would disagree that SQLite is somehow wrong for this use-case.

Fossil does seems to have issues when the VCS grows into many many gigabytes of data, like the entire OpenBSD source tree didn't work out very well in Fossil, but the chances of a personal task manager ever growing that size is slim to none I would imagine.

Re: Show HN: Grit – a multitree-based personal task manager

#32

Post by cadbox1 »

nojvek wrote: post #20

Omg! This is an exciting idea. I want to build a small react version of this. Tree based tasks list are a thing I've always wanted to build.

I think I’ve built something similar in React. It looks like a nested list but each item can have multiple parents. It syncs to GitHub and is public, I use it to share my recipes.

https://verynested.cadell.dev/ https://cooking.cadell.dev/

Re: Show HN: Grit – a multitree-based personal task manager

#33

Post by riedel »

I just started migrating to taskwarrior which great due to the many clients. Actually its integration with vimwiki via the taskwiki plugin [1] is quite powerfull allowing editable views. Wonder if this dag aproach could be integrated via metadata without loosing compatibility.

[1] https://github.com/tools-life/taskwiki

Re: Show HN: Grit – a multitree-based personal task manager

#34

Post by rtpg »

I've been working in this space for my own task manager (multi-parent + infinite depth), and here's a couple things I've landed on:

- My objective is being able to show a "todo" list that is _actually actionable_. So I think early on its important to build in notions of "availability" (i.e. "this is not waiting on something else, you can work on this now")

- The dual is you kind of need nodes that represent "blockers". Here you have the parenting mechnaism that could get you there, but also stuff like setting dates on nodes (in Omnifocus this looks like the "defer until" date)

- I tried making a UI that handled N-node depth, but ended up figuring out that just displaying at most 2 levels of depth and then having fast loading when zooming in/out saved me a lot of API design headache and gets me 95% of the way there

- Even if your data is a tree structure, a lot of times just showing a flat list (perhaps with "parent node is X" annotation) is going to work out nicer. Notably with search

Re: Show HN: Grit – a multitree-based personal task manager

#35

Post by houzi »

loloquwowndueo wrote: post #28

I really like trying out tools that allow me to organize and track tasks, as they help me keep focused and more motivated if I know where I am, what I have done and what I need to do. Grit is really cool, the name feels a bit unfortunate as it might have muscle memory overlap with “git” - nothing that can’t be solved with an alias but perhaps something to ponder. I also sadly see limited use for a task tracking syste…

Agree with your point on muscle memory, although I find a shell alias to be a sustainable workaround.

Re: Show HN: Grit – a multitree-based personal task manager

#36

Post by woofie11 »

zie wrote: post #31
woofie11 wrote: post #27

Earlier quoted context omitted.

git. The right storage backend is either git, or a git-like Merkle tree. This is small data. Individual files for objects are fine. Compacting is better, but not critical. You can write git in a weekend or two: https://wyag.thb.lt/ sqlite is the wrong tool for the job, beyond an initial prototype. git and hg figured this stuff out decades ago. Good job, by the way. This seems like the sort of thing which, if: * it di…

You aren't technically wrong, I guess, but Fossil would disagree that SQLite is somehow wrong for this use-case. Fossil does seems to have issues when the VCS grows into many many gigabytes of data, like the entire OpenBSD source tree didn't work out very well in Fossil, but the chances of a personal task manager ever growing that size is slim to none I would imagine.

I guess I'd be okay with a Merkle tree stored in SQLite, although looking over the Fossil documentation, it seems like the developers didn't get git, and what made the git data structure so clever.

I see pieces like this in the Fossil docs:

"Fossil stores its objects in a SQLite database file which provides ACID transactions" -- https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

The whole point of git is that your only operations on the underlying data structure are:

1. writing an object under its hash

2. incrementing a pointer to the head of a branch, a git tag, or similar, to show which version is current

You can do (1) on an eventually consistent (or even never-really-consistent) backing store, without any sorts of strong guarantees of integrity, and the git data structure continue to guarantee integrity. If (2) goes out-of-sync, you're left in a state very similar to what happens if I'm working on my laptop, and you're working on yours. We need a merge.

With DVCS, the whole point is to make ACID irrelevant.

I hadn't heard of Fossil before, but reading over the docs, I see a lot of red flags like that.

If grit were backed bit literal git, I'll mention, you get a ton of stuff for free, mostly with regards to syncing and finishing tasks on distributed devices (e.g. my cell, my laptop, etc.)

Re: Show HN: Grit – a multitree-based personal task manager

#37

Post by houzi »

hirundo wrote: post #22
climech wrote: post #14

Earlier quoted context omitted.

Yes, it's sorted by name in natural order. I haven't decided yet which would work best as default (this vs insertion order) -- feedback is welcome. This works well for numbered book chapters, something I personally find useful. In any case, the defaults will be configurable -- when I implement config :) (Another thing on the TODO list is adding an optional priority score for each task, and sorting those on top of the…

I hope you consider global prioritization of leaf nodes, either entered individually or calculated from weights of ancestor nodes. One big deficiency of most todo apps is lack of support for making routes through the leaf nodes. I see that you can already do this with Grit via pointers and numeric task prefixes for sorting. But that brings us back to the bad old BASIC style line numbering problems.

With weights, you can have the user enter individual weight edges between root and task node, which would simplify the design, no?

Re: Show HN: Grit – a multitree-based personal task manager

#40

Post by zie »

woofie11 wrote: post #36
zie wrote: post #31

Earlier quoted context omitted.

You aren't technically wrong, I guess, but Fossil would disagree that SQLite is somehow wrong for this use-case. Fossil does seems to have issues when the VCS grows into many many gigabytes of data, like the entire OpenBSD source tree didn't work out very well in Fossil, but the chances of a personal task manager ever growing that size is slim to none I would imagine.

I guess I'd be okay with a Merkle tree stored in SQLite, although looking over the Fossil documentation, it seems like the developers didn't get git, and what made the git data structure so clever. I see pieces like this in the Fossil docs: "Fossil stores its objects in a SQLite database file which provides ACID transactions" -- https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki The whole point of git is tha…

Git and Fossil started about the same time, and initially released within a year of each other.

For the record, the people that created SQLite also created Fossil. The SQLite software(and website) was Fossil's initial use-case.

Fossil offers WAY more than what Git does, Fossil includes ticketing, forum, chat, wiki, etc. It's more on par with Gitlab/Github/etc, than it is 'git' alone.

Fossil syncs, etc, just like Git.

I think they serve different use-cases. git is nothing but the data structure(s), it's very very hard to use git, if you don't understand how the data is stored, as the UI is a very thin wrapper around it, which causes all sorts of issues for people that just want to get work done. That said, it makes Git very flexible, which is great.

Git was built for the Linux kernel way of doing things, and got co-opted into the PR model that Github pushed. I'm not saying these are wrong ways to think about the problem, but they are not the only way. Fossil is a different way.

Around ACID vs Git's data structure, the whole point is your data needs to kept safe, who cares how it's done.

I'm not trying to convert you to Fossil, but I think it's important to recognize git isn't perfect, or even perfect for it's use-case. But it clearly won the mindshare of developers because we just blindly followed Linus.

I'm of the opinion that for most projects, Mercurial, Subversion or Fossil would have been the better/easier solution for most people and while arguably not as flexible, the UI is at least 50% better and easier to understand.

Post reply on HN