Follow

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"

boosts appreciated

@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

@nasser @eq orphaned branch was going to be my suggestion, yeah! feels like a good fit.

@nasser @eq there's a bit of a chicken/egg problem if you use discussion to talk about merging branches but the discussion itself is a branch. metacircularity is a fun problem to have tho.

@technomancy
@nasser @eq

You can store things outside of branches too! I don't use it (and don't know anyone who does) but there is things like git-notes: git-scm.com/docs/git-notes

@nasser @eq Just curious.. how do you derive the orphaned branch name?

@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.

@thufie @nasser this exactly
there are reasons you want to distribute something, but the "everything lasts forever and is immutable" nature of git commits is not really something you want in a discussion platform. there are already issues here re: name changes that would only become more difficult to solve

@pounce @thufie this is excellent feedback, thank you. yes, a lot of thought would have to go into how access to conversation branches would work.

@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.

@nasser @technomancy I like the idea, but I’d need convincing given how git likes commits to be immutable(-ish). Opens up whole new forms of abuse.

@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 @a @technomancy As a maintainer I do get annoyed when random newbies wander into a pull request with off topic comments. On the other hand, I do want discussions to be open to anyone so anyone is empowered to start reviewing code.

@be @a @technomancy 100% optimistically, with some careful thought and deliberate design this is a balance that can be struck I would hope?

@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

@nasser
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.

@nasser
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

@yaaps @nasser this and deadnaming and stalking are also things that exist.

@varx @yaaps @nasser i don’t know the name for this informal logical fallacy so i will just compare this to global variables: yes they already exist- that’s not an excuse to use them more

@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 <nasser@merveilles.town>" 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.

@zens @nasser
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.

@zens
My idea would be to have a separate local user profile for work, if you insist on using the same machine for private and work data.

@daniel you might have missed the word “accidentally”

@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

@zens
Maybe I misunderstand your problem, as I would expect my proposal to prevent such accidents.
If you login on your computer with your private account, you would not have access to your work identity, which would prevent you from using it by accident, no?

@daniel yep, just need to invent a time machine and do that before i make the mistake.

@zens
Joking: you could rewrite the git history, force push, then break into every system which has a clone and do a force pull. 😁

@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

@nasser might be fun to poke around in github.com/MichaelMure/git-bug and see how michael does things in his git issue tracker

@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.

Sign in to participate in the conversation
Merveilles

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.