Hacker News Reader

Comment by e-topy | Hacker News Reader

> Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, technical notes, a web forum, and a chat service [...]

I like the idea of having all of those within the actual VCS, mostly because with Git you need centralized services like GitHub to provide that.

But I have to ask: Is it really a good idea? Seems like feature creep motivated by the wants of a single project (SQLite).

All of those could be (albeit awkwardly) backed with a git repo and a cron job. Wiki? Just make a repo with a bunch of Markdown or this-week's-favorate-markup-language files. Ticketing & bug tracking? Again, just a Markdown file for every ticket. Embedded documentation & technical notes? Those are just special wiki pages with different attributes. Forum and chat service? Do you want your VCS to do that? I get being able to hyperlink between files and conversations, but still.

View on HN

I want it embedded in git simply to break the hold Github has. We have this fantastic distributed fault-tollerant dvcs that gets funneled though at worse 1 service, at best maybe 3 or 4.

I'd love to clone a repo and be able to view all the reasoning behind commits with the context of issues too. I know the commit message should cover this but sometimes it doesn't, or its too much context, or the context is limited to the opinion of the committer. I think all that information is relevant to projects and should have some chance to live alongside it. Stuff like git-bug exists, but then you still need participation from other people.

I really love the idea of radicle.xyz which is git + p2p + issues & patches (called `COB` - collaborative objects) all in your repo but getting the buy-in of the wider population seems extremely difficult, if not impossible. I think part of the attraction here specifically is nostalgia for me, it feels like its invoking the 90s/00s where it was all a big mesh network, information wanted to be free and you couldn't stop the signal.

Fossil also seems cool but the rest of the world is tied to git and I'm tied to jj now. I guess I really wish git themselves [sic] would push something forward, I think that's the only way it would really get broad acceptance. Forges could adopt it and try and special-sauce parts but still let you push/pull "COB"s.

> Stuff like git-bug exists, but then you still need participation from other people.

The plan is to 1) finish the webUI and 2) accept external auth (e.g. github OAuth). Once done, anyone can trivially host publicly their own forge and accept public contribution without any buy-in effort. Then, if user wants to go native they just install git-bug locally.

Whoa, git-bug is still being developed, awesome! I wonder how difficult it would be to add other tables to it (I cannot help but think about bug trackers as being a database with a frontend like Access, and many limitations...) — in particular to have Messages (for messages) and Discussions (for hierarchical list of message references). Now that git has reftable maybe this sort of abuse would actually work...

Assuming that by "table" you mean another "document type" ... pretty easily. There is a reusable CRDT like datastructure that you can use to define your own thing. You do that by defining the operations that can happen on it and what they do. You don't have to handle the interaction with git or the conflict resolution.

"Feature creep" is hard to characterize. If the project needs and uses it, is it really "feature creep"?

Or, from Wikipedia, "The definition of what qualifies as "feature creep" varies among end users, where what is perceived as such by some users may be considered practical functionality by others." - https://en.wikipedia.org/wiki/Feature_creep

Hipp (the original SQLite author) also developed his own parser generator (Lemon) and his own editor (e). The former is also used by other projects.

Where do you store the different attributes? In the file-system? How do you manage consistency? Why put up with awkward cron solutions when you have a fully ACID database system right there to work with, which is portable across OSes, including ones which don't have cron?

If it helps any, don't think of it as a VCS but as an SCM system - one which includes version control.

I prefer not to have strict version control over the entire state of all work tickets. It sort of adds friction.

Reply on news.ycombinator.com