Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

I love seeing these projects make use of the wide-open namespace/references that git provides (outside of the basic `refs/heads` for git branches and `refs/tags` for tags). It looks like they store the data in the `bugs` namespace [1] (so refs/bugs/foo).

Other projects also make use of alternate namespaces. The oft-forgotten built-in "git notes" puts stuff in the `refs/notes/` namespace (specifically in `refs/notes/commits`). Gerrit uses the virtual `refs/for/` namespace for receiving commits for review, stores project config in `refs/meta/config`, and stores User data in `refs/users/` in a special repo [2]. I'm sure others do interesting things.

Alternate uses of git's DAG model are fascinating.

[1] https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...

[2] https://gerrit-review.googlesource.com/Documentation/config-...

View on HN

Yes, this really meant to be some sort of framework for storing entities in git, handle the conflicts, and let you buld easily your own tool (or add more features to git-bug).

I'd love to see this used in the wild for other use cases.

Is there a registry of namespaces to avoid collisions?

Technically you could solve collisions through single indirection convention ie 'refs/manifest' which describes refs used with their "schema", "version" etc. If you want to decorate your repo with something, you'd register it there. This way you wouldn't have to keep global convention registry for different projects not to step on each other.

Wow!So this can be used for full blown project management too.

Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work.

If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.

So for example, git-bug already has a PR to add support for a project board: https://github.com/git-bug/git-bug/pull/843

The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.

This would allow for really native linking between a tracked issue and corresponding commits/branches/tags, for modeling dependencies between issues as part of the git DAG,...

Reply on news.ycombinator.com