Looks like a CLI version of Workflowy ( https://workflowy.com ) to me.
Workflowy is good but it's really expensive for what it does, I'm glad we have grit as an alternative.
Show HN: Grit – a multitree-based personal task manager
41–47 of 47 posts
Re: Show HN: Grit – a multitree-based personal task manager
#42Looks like a CLI version of Workflowy ( https://workflowy.com ) to me.
I would kill for a GUI app like Workflowy with multitrees. I really do need a graphical representation in order to best visualize what's going on.
Re: Show HN: Grit – a multitree-based personal task manager
#43Earlier quoted context omitted.
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.…
If you want to keep your data safe, it matters how it's done. See MongoDB for the story of a system with a friendly UI and a train wreck back-end.
git didn't win mindshare of developers because people blindly followed Linus, anymore than relational SQL databases weren't inched out by OODBs, document databases, or all sorts of other technologies because of dumb developer entrenched mindset. git (like SQL) won because it has very, very solid theoretical underpinnings which make it work incredibly well across a surprisingly broad set of use cases and handle data robustly.
Subversion is good for virtually no one. It's like using Excel for a database. It's complex, but doesn't get the job done.
Fossil, on a cursory look, looks like nineties mysql, when it was easy to use, but didn't really work, and was kind of a cargo-cult implementation of a proper database. I will admit I could be wrong (perhaps, just lousy docs).
hg, I agree, is better than git. git is a beautiful backend with a horrible front-end. hg has an equally beautiful backend, with a clean front-end and decent libraries. I wish hg had won. It didn't.
Oh well. At the end of the day, though, for this use-case, back-end matters far more than front-end. Competent developers can and do learn to use git, and are equally productive as in hg once they get over the learning cliff.
An upside is you learn a lot by learning git (or hg) internals. If OP knew git, they would have made a better grit. It's something every developer should do. Once you're past that, the front-end, while far from clean, gets the job done.
svn doesn't get the job done.
Re: Show HN: Grit – a multitree-based personal task manager
#44Earlier quoted context omitted.
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.…
If you want to keep your data safe, it matters how it's done. See MongoDB for the story of a system with a friendly UI and a train wreck back-end. git didn't win mindshare of developers because people blindly followed Linus, anymore than relational SQL databases weren't inched out by OODBs, document databases, or all sorts of other technologies because of dumb developer entrenched mindset. git (like SQL) won because…
You seem awfully confident of yourself, but I'd disagree with many of those perspectives. Just because you sound confident doesn't mean you are correct.
There is a reason there are 500,000 git tutorials that start with the basics of how git works, and still practically nobody understands git. Despite knowing the underpinnings of how it works practically required to be useful in git.
I agree the implementation matters from a data safety perspective, I mean Jepsen made a name for himself proving how terrible all the "distributed" databases suck(because it's a very hard problem to solve). But as a user, you don't usually have to care... unless it's git.
FreeBSD successfully used SVN for a long time without any major issues, as one example.
Re: Show HN: Grit – a multitree-based personal task manager
#45[deleted]
Re: Show HN: Grit – a multitree-based personal task manager
#46Earlier quoted context omitted.
If you want to keep your data safe, it matters how it's done. See MongoDB for the story of a system with a friendly UI and a train wreck back-end. git didn't win mindshare of developers because people blindly followed Linus, anymore than relational SQL databases weren't inched out by OODBs, document databases, or all sorts of other technologies because of dumb developer entrenched mindset. git (like SQL) won because…
You seem awfully confident of yourself, but I'd disagree with many of those perspectives. Just because you sound confident doesn't mean you are correct. There is a reason there are 500,000 git tutorials that start with the basics of how git works, and still practically nobody understands git. Despite knowing the underpinnings of how it works practically required to be useful in git. I agree the implementation matters…
Very few git tutorials explain how git works. That's the underlying problem. Using git correctly requires knowing how it works. You solve that problem by having a reasonable userspace, like hg, or by having a proper course in college. Much like you learn databases, compilers, and operating systems, you should learn about hash trees and similar data structures.
I feel like the statement "FreeBSD successfully used SVN for a long time without any major issues" is a lot like saying "I wrote books on a typewriter without any major issues." Or "Why do I need pointers/references/data structures? I wrote my code in QuickBASIC without any major issues." Or "DOS doesn't have memory protection or multitasking, and I never had any major issues" or "I wrote my system without documentation or test infrastructure, and it's never been a problem."
At the time you switch to correctly using a DVCS, your productivity skyrockets.
If you're using SVN, you DO have a problem. You might not know you have a problem, but you do. If you're using git like svn, you also have a problem.
I agree with you that many programmers have a problem, though. Just not about the root cause or the solution.
Maybe the right solution is to write a Python implementation of git with a sane user-space. The original git was written in a couple weeks, and I don't think it'd be more than a few months of work to have feature parity.
Re: Show HN: Grit – a multitree-based personal task manager
#47cool. Is there a way to convert a sub-task to a sub-sub-task? Where does it keep the local sqlite database file?
It's likely to be in
.config/grit/graph.db
root@Flipper:/# find . -name graph.db
./home/mike/.config/grit/graph.db