Define a project commit format

GAnarchy has this thing called a “project commit”. It uses the following format:

[Project] {{Title}}


Title may not contain newlines and Description may contain anything. However, I don’t feel like it’s worthwhile to keep it GAnarchy-specific. As such, I’d like to propose a common project commit format that anything can use. It would still follow the same basic structure, but we can adapt some things. We could add an YAML section or something, or define the description to be markdown-based, or so on. Maybe it should also be allowed to refer to any files available at the moment of the project commit, which would be useful for a project logo. This would benefit any tools doing anything even remotely like GAnarchy. I’d need to adapt GAnarchy to handle the new format, but if we stick to plaintext formats, it shouldn’t be a big deal.

Hey @SoniEx2! Welcome :slight_smile:

Thank you for the ideas and thoughts! The ForgeFed vocabulary is based on ActivityPub, so commits will be JSON objects (in which the project, title and description will be fields). If there specific fields you need that aren’t covered, we should definitely look into adding them! Soon I’ll publish the initial vocabulary and example for a ForgeFed Commit and we can figure out the things you mentioned.

Btw, this is a good chance you can use here to explain what GAnarchy is, and link to your code :slight_smile: (I recall seeing mentions of it somewhere, maybe on the Fediverse)

if you’re trying to federate commits across technologies,

I hope you aren’t.

because that way lies hell.

I’m just trying to define a “project commit format” that can be used with git, independent of ActivityPub.

GAnarchy is very different from simply “allow repos to be interacted with from anywhere”. the main common goal (not the only, but probably the easiest to see) between GAnarchy and ForgeFed is probably federated issue tracking, which is NYI in GAnarchy.

Anyway, this is GAnarchy:

Just grab a repo and go with it. Note that the self-hosted one can’t be browsed on the web. Sorry about that.

Unrelated, probably something for a different thread: it would be a good idea to just have the commit hash in the Commit object, and no more. Since you already have a Commit object, it’s not gonna be compatible with existing fediverse software anyway, so there’s no big deal in forcing new fediverse software that wants to support Commit to have git available. Between the actor (which should be the specific branch IMO) and the commit hash, which btw is immutable but even better can be easily verified by the client, it is trivial to figure out which project to attach it to. The main benefit of doing it this way is that it can be independently verified.

uh hi please give me an update on this I kinda need it thanks

Hey @SoniEx2, what sort of info do you need?

ForgeFed’s vocabulary is ActivityPub JSON with an extension. If there’s some other format you’d like to use or propose, such as the project commit format you mentioned above, can you please explain the purpose of the format and write some use cases where it’s used / can be used?

GAnarchy’s “project commit” idea is to provide independently verifiable project metadata, by using the commit hash for authenticity. It doesn’t prove that the project is equivalent to the one on the commit, but it at least assures that the repo contains some commits from the commit’s project. This is used by GAnarchy to group related repos together under the same project (and perhaps that is the only use-case, but I like to believe it would be useful for other projects as well).

It doesn’t solve the problem of “how can I trust it” (where “it” can be the contents of the commit or the repo) and there can be multiple valid project commits for one repo (this could happen if, for example, the main repo merges a side repo, such as in the Linux kernel merging in a device driver from an unrelated repo. it could also happen if a fork happens and a later re-merge happens, such as in OpenWRT), and GAnarchy specifically, uses the instance admin as the “trust store”. Or, in other words, this is not a problem for my own use-case. Git does provide signed commits which could be used for trusting the commit, but on the other hand I’m not sure you can do anything for trusting a repo.

Keep in mind this is for projects (or large rewrites of a project, if desired. it’s up to each project to figure out how they wanna use it.), not for releases. Tags are better suited for releases. (It is technically possible to use both, as well, but I’d strongly discourage that except maybe for major, backwards-incompatible releases.)

@SoniEx2, can you please describe though howthe format would be used in ForgeFed / in forges in general, and which need it would fill? Imagine you wrote a spec for your project commit format, and now forges out there, such as GitLab and Gitea, and looking at your spec. What would they see and which problem would the format solve for them? I’d like to understand this better.

It’s used in GAnarchy to provide an independent project view that isn’t tied to any particular repo. “Networks” in github are tied to the base repo which all forks are associated with, rather than to a commit, so it doesn’t take into account clone-forks. (and in my specific case they only almost provide what I want, so I had to make GAnarchy anyway. I explicitly don’t want an “upstream”, after all.)

@SoniEx2, sounds like you’re defining an equivalence relation that basically says, if 2 repos share at least the first/last X commits, they can be considered variants of the same project. This is interesting. I’m wondering how one could verify that such variants are really still the same project overall (e.g. I could clone a repo, make big changes, turn it into an entirely different kind of project).

Here’s the thing tho, if you clone firefox, strip all tracking, and publish it anew?

It should be considered a firefox replacement.

I mean, it’s up to instance admins to decide whether or not to consider any repo a replacement of any other repo. It’s also up to instance admins to curate the projects for their users (especially if wider fediverse integration is desired — your local mastodon instance could send you to your local GAnarchy instance, as part of its handling of web+ganarchy URIs), including which repos they believe best represent a given project.

It’s just a way to roughly (because you can have project commits from multiple projects in one repo) carry the “what project is this” metadata across repos.

(Also, no - this isn’t a technical solution to a social problem. There are many ways to use GAnarchy, and I fully acknowledge that. It’s a tool. It’s also particularly suited for working with this specific social problem. But that doesn’t mean it’s the only way to use it. Some ppl will put only one repo on it and give it a very large project commit that’s basically a README in a commit message. And that’s okay.)