not sure if my instincts are off so lmk how you all feel about this: "in a hypothetical federated git platform, i would like it if conversations in a repository (eg issues and pull requests) were stored directly in the repository as opposed to in a database on the server"
@nasser whenever i use github i always wish the discussion were in *a* repository but i feel like having it in the same one could get messy? (i.e. switching between discussion and in progress code might be more of a pain). that's kind of just a UI sort of thing so i guess it could be in the same repository either way
@eq that's really good feedback. yeah my current prototype stores them in the same repo but on their own orphaned branch, one branch per conversation. UI is undetermined, but i was imagining you wouldnt really interact with the conversation branches directly (though you certainly could) but is instead would use (cli/editor/web) tools to do it for you? like i said, totally undetermined.
@nasser just doing it via git logs was one silly idea i had running through my head when writing the first post. i think i tried something similar for some project a while back
@eq yeah it *basically* just works because git is a remarkable piece of software. this was me messing around a few days ago. the messages are stored in the commit messages, and attachments work by storing files in the object store.
@nasser oh i didn't think about that being useful for attachments but it makes a ton of sense! that's clever
@abrahms @eq I was thinking new conversation branches could get temporary names and then after the first commit be renamed to the hash of that commit, because you really want to refer to a conversations by some kind of unique hash and at the first commit works as well as anything. current prototype doesn't do anything like that yet.
@nasser Not necessarily in the repo ("if I comment on something, I create a commit") but in something associated with a repo. Maybe a separate repo.
@J12t the current prototype implements conversations in orphaned branches in the same repository to try and get the best of both worlds. branches where you actually have code would not be touched. does that sound like a reasonable compromise?
@nasser only if the tools for the discussion in the repository has firat class moderation features tbh.
@nasser I would rather not have discussion be versioned; they should probably be tied to versioning (e.g. reverting the commit 'fix issue #123' should reopen #123), but if you revert to before when an issue is filed, you really really don't want the issue to disappear in the revert.
@alexbuzzbee that makes sense. reopening issues based on reverts is actually really interesting, I hadn't thought about that!
@drwho I wasn't familiar with Fossil so I just looked it up, looks very interesting! yeah this is kind of what I'm talking about.
@a @technomancy that's totally fair. every conversation becomes a "forever conversation" by default. I certainly don't expect the current GitHub workflow, where any random person with an account can wander into a repository and leave comments, could work in this scheme. I think the author of the repository would be empowered to merge or not merge comment branches from other people? the same way random people can't just push code into your repository? it's not totally clear.
@nasser I think using a repo to store the conversation makes the most sense. It's the simplest way to approach it. I think though that it would be ideal to have the communications in a separate repo just to streamline CI/CD. I know it is possible to work around it and set triggers appropriately etc but it feels like you're booby trapping it if it's all in one repo.
@z the current prototype stores conversations in orphaned branches in the same repository, so that everything moves together. what kind of booby trap are you concerned about?
@nasser I think that works pretty well actually. I was just thinking about how things like Netlify will trigger builds when you update readme.md files if you don't set it up to exclude that stuff. Generally not an actual problem, but it bugs me everytime i see it happen.
@nasser I would like to have a sourcehut-style platform where the issues and discission is separate from the repos, and I could have multiple trackers and discussions tied to one repo, or have multiple separate repos (source code, documentation, etc.) all tied to one tracker.
Also only vaguely related, I'd like a separate platform for discussion and issues. IMO “issue trackers” should be used to, you know, actually track issues; and there should be a separate section for discussing features, providing support, and triaging bug reports to find the root cause of an issue that can then be filed on the issue tracker.
@nytpu that's super interesting. under the scheme proposed one repository could have multiple trackers and discussions, but not the other way around, so that's certainly a trade-off I had not considered I had not considered
I think it makes more sense to have a one-to-many relationship between them.
I have lots of small projects that don't get many bug reports or anything, and it's silly for all of them to have their own issue tracker—but also not good for them to not have an issue tracker at all. On the forge I currently use, Sourcehut, I can just have a catch-all mailing list and issue tracker that I connect to all my small projects.
However, bigger projects tend to also have more repos (one each for documentation, website, source code, miscellany, etc.), and yet it's usually superfluous for each of those repos to have their own issue tracker too.
It is a trade-off though, because although it's a lot nicer for the user, the in-repo strategy you were discussing is really nice for federation. You can reuse your existing code that works with git and just put an issue tracker frontend on it, and you get federation of the issues essentially “for free” because it federates along with the git repo itself. If I was designing this I would probably do some experiments and then just make a tough decision if one-to-many trackers are worth the additional effort or not.
@nytpu youre describing a workflow that is super interesting and new to me. ive always had a one-to-one repo-to-issues mapping because i never considered any alternative, but yeah looking back there's been some v awkward arrangements when working on projects w multiple repos as you say. thanks for sharing your thoughts, a lot to think about!
@nasser storing non-privileged input (e.g. issues and pull requests) in the repository would make it way harder to moderate and delete harassment, especially for things like deadnaming and doxing.
I was going to recommend discussions in a submodule, for the sake of the moderation issue. You can be more liberal accepting pull requests than you might be for the main repo, you're giving participants a choice whether to access the discussion raw or moderated, you promote a canonical view of the discussion that makes it easy to ignore branches that include activity from bad actors, and you're not in any danger of losing code history if you do delete a branch
@zens I suppose there's a valid distinction because there are people who would use discussions who wouldn't be making commits. (If they were the same people, I maintain that it really wouldn't matter.)
@zens (Global variables aren't a good analogy because they have exponential suck as opposed to linear, but I hear you on the fallacy.)
@varx the specific issue at hand that i am attempting to call up is that any retroactive edit changes the head checksum, invalidating everyones checkouts and dumping any changes they were working on the floor.
if comments only have the one checkout for the webview + federations, i am thinking this is easier to manage if it’s seperated from actively edited code.
@zens @yaaps deadnaming is a very good point. I wonder if recording user IDs as opposed to display names mitigates that at all? eg instead of "Ramsey Nasser <firstname.lastname@example.org>" I'm just "nasser@merveilles" in the log and when mentioned. admittedly this doesn't fix everything, but it does feel like it narrows the problem down to the kind of thing you would have to deal with in a more traditional database?
@nasser @yaaps yes- i don't think i have a real solution, this is a problem with git that I personally keep running into by accidentally doing commits under my work email instead of under my pseudonym, and then finding it impossible to fix once everything is up on github. It's not impossible to connect my identity here with my real identity but I don't like making it easy.
There isn't a good solution, which is why I'm willing to reach for a bad one. You've got to crawl every branch, note every affected commit, unwind and redo every commit with the corrected metadata, delete the originals, and convince remotes to follow suit. And don't talk to me about timestamps; I haven't worked with other people since... before git
Anyways, that's why a submodule. I'd want to do that in the conversation repo before the code repo, and I'd want a higher standard for conversion linked to the code repo than for live discussion. As mentioned above, I don't use git collaboratively - so I don't know whether you actually need an entirely new repo, as opposed to a branch or some other structure within a repo, to scope permissions.
@yaaps @zens all very very good feedback. git itself does not care about "permissions" really, that happens at a higher level (basically by deciding to merge someone else's changes or not). despite the cleverness of an orphan branch in the code repository I'm seeing the arguments in favor of separate repositories. nothing preventing username/project_conversations.git from living alongside username/project.git. hmm hmm a lot to think about! thank you for taking the time to engage with this.
@daniel i mean yeah, after i’ve made the mistake, what I should have done is obvious. i know the thing about profiles. the problem is git makes it a condescending puzzle box from hell to correct a mistake once made. it assumes the user is perfect and never fucks up or changes
@daniel i could do that for every sort of change except commit author. the omly thing i could get to work for that is nuking the whole repo and recreating it from scratch
@nasser for safety reasons conversation needs to be capable of redaction. i’d be concerned having it in the same repo would cause issues with this
@nasser Yes/sortof; I'd like to see them in a parallel repository, so people who are bandwidth bound or otherwise don't care could clone (and even shallow clone) the main repository without getting the comments stream. But using the repository mechanism prevents a lot of headaches, and it's Right There, so it makes sense to do.
@nasser reading through these responses has me thinking: okay so if using two repositories (one for code, one for the issues discussion), then how would that work?
one inkling of a solution: perhaps you could have an orphaned branch in the code repo that points to the latest discussion repo. this opens up for e.g. completely resetting the issues, if needed, and avoids immutably storing problematic data in the core repo. you could even have a moderation layer using cherrypick and new repos
@cblgh skimming the internals page on the wiki it looks like they are storing things in orphaned branches, like my prototype, but they are using files and file trees more explicitly than I am. my prototype stores all information in the commit message directly, and I use trees just for attachments and media. this is definitely a project to pick apart more closely though! thanks for the link.
Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.