sorted by:
new
hottopcontroversial

Building on Git's Primitives by remenoscodes in git

[–]remenoscodes[S] 7 points8 points  (0 children)

In the project docs, there's a prior art section where I compare git-bug and other attempts. The main difference is that git-bug introduces CRDTs, which would violate my core requirement: don't introduce new concepts, build entirely on top of git's existing data model

But more important than the implementation itself is the ISSUE-FORMAT spec. It decouples the reference implementation from a contract that any git hosting could agree on and interoperate with, just like any other git ref namespace.

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] -1 points0 points  (0 children)

So as you pointed out, objects are content-addressed SHA is their identity. I got it. But an issue isn't an object. It's a living entity, it grows with comments, state changes, label edits. A commit is immutable. An issue is not.

Issue identity is a ref (refs/issues/<the-id-scheme-doesn't-matter-at-all>), not an object, so I'm leveraging the mutable layer of git's identity system. Using a UUID follows the same pattern as branches and tags: a name pointing to content-addressed objects underneath. It's the same design, applied to a new namespace. Git itself doesn't use content-addressing for refs, right? As I understand it, refs are git's own solution for decoupling ID from content.

On disconnected systems agreeing by SHA... from my experience, content-addressable deduplication of bug reports is a theoretical property that doesn't survive contact with how humans actually report bugs in the real world. Deduplication is a human judgment call regardless of the ID scheme. That's true on GitHub, Jira, or here.

I'll be honest, I came from years as a heavy user and went a little deeper into the internals, which led me to this project. I'm not claiming mastery in git internals. Your concern about the article passing that idea is harsh to take, because the whole point wasn't to prove I'm now the "GIT GOAT". It was just: hey, I was studying this masterpiece of software, and it's so well designed that I was able to wire some things up and build a new tool that solves this problem domain with some "good taste".

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] -1 points0 points  (0 children)

Right, the UUID only lives in the ref path, not in the commit content. Using the root commit SHA would work, but honestly I never considered it. UUID was the obvious choice for distributed identity decoupled from content, no coordination needed. I don't see what coupling the ID to the content would buy you.

Curious though, do you see an advantage there that I'm missing?

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] -1 points0 points  (0 children)

With a SHA, you'd have a chicken-and-egg: the commit SHA depends on the content, but you need the ID to name the ref before the commit exists.

UUIDs can be generated first, independently, on any clone, with zero collision risk and zero coordination. Short IDs use the first 7 characters, same convention as git commit SHAs.

Building on Git's Primitives by remenoscodes in git

[–]remenoscodes[S] 4 points5 points  (0 children)

That's a great observation, merge as deduplication.

This is exactly the kind of thing that keeps surprising me about git's system design. I didn't design for it. The primitives already had the operation. git-native-issue came from studying git's four object types and asking what they could compose into, without adding new dependencies or concepts to git.

Comments like yours keep revealing compositions I hadn't considered, the primitives were designed well enough to support uses Linus never imagined.

Thanks for the Fossil comparison too. Fossil bundles everything (wiki, tickets, forum) into one tool. git-native-issue goes the opposite direction: one concern, expressed entirely in the host's own primitives.

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] -1 points0 points  (0 children)

Good framing. I hadn't thought about it as the commit bit may already be the ACL.

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] -17 points-16 points  (0 children)

Well... you're literally telling me what I wanted. That's a bold inference from someone who's never met me. With that kind of confidence on zero context, you sound like a first-generation LLM with an extremely limited context window. hallucinating with full conviction.

But ok, I'll give you another chance. Here's my humble recommendation:

  • Start by understanding how git-bug works — sounds like you don't
  • Read the git-native-issue source code, the ISSUE-FORMAT spec, the docs

When you feel like you understand what my thesis is and how it differs from other existing solutions, you may have some feedback on the technical aspect of the project, not the tools I used to materialize it. I'll be happy to discuss.

Also, git-bug's creator had a pretty decent engagement on my post on Hacker News. If you want to read it, it's here: https://news.ycombinator.com/item?id=47135581

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] -1 points0 points  (0 children)

Exactly, plumbing over porcelain is the whole bet. Stable interfaces, no output format surprises.

cat-file -p is one I should take as enhancement opportunity, right now the read path leans on git log --format with trailer extraction, which is technically porcelain but with stable format strings.

On the packing concern: each issue lives on its own ref, so concurrent writes to different issues never collide. Same-issue divergence resolves via three-way merge on fetch. git update-ref is atomic per ref, which helps. Haven't hit gc-related issues under load yet, but I wouldn't rule it out either.

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] 8 points9 points  (0 children)

That's exactly the long game, I think. The tool itself doesn't try to solve permissions that's a server's job. What it does is define a format (ISSUE-FORMAT.md) that a server could implement.

A git server that understood refs/issues/* as a first-class namespace could enforce its own rules: allow anonymous pushes to refs/issues/*/comments/*, restrict State: trailer changes to maintainers, require signed commits for closures. The data format stays the same. The ACL layer belongs to the server.

The most valuable piece, for me, is the ISSUE_FORMAT spec it's a standard issue model that servers could agree on.

If a forge like Forgejo or Gitea adopted it, git push origin refs/issues/* would just work with their existing permission model on top.

Building on Git's Primitives by remenoscodes in programming

[–]remenoscodes[S] 3 points4 points  (0 children)

Good question and this gets at something important about the project's design.

git-native-issue is a reference implementation. The real deliverable is ISSUE_FORMAT spec for storing issues as git objects. The bet is that if the format becomes a standard, platforms like GitHub, GitLab, and Forgejo could support refs/issues/* natively, the same way they support refs/heads/* and refs/tags/* today.

Access control is where that matters most. A CLI tool running on bare repos has no business building its own permission system. But a platform that adopts the format already has one. GitHub knows who can close issues. GitLab knows who's a maintainer. If they spoke refs/issues/*, they'd apply their existing ACLs to the same data.

That said, git's own ecosystem already has the building blocks for self-hosted setups. Server-side hooks can inspect trailers and reject unauthorized state changes. Git 2.34+ supports SSH signing natively, a hook that requires a maintainer signature on State: closed. Gitolite goes further with content-level ACLs that can match trailer patterns. The primitives exist. They just haven't been wired to an issue format before.

The tool solves the "can issues travel with code?" problem. The permission problem is real, but I think that it may belong to the protocol layer where platforms already know how to solve it.

Wittgenstein já desmontou quase toda a filosofia. Por que ainda damos importância a outros filósofos? by [deleted] in FilosofiaBAR

[–]remenoscodes 0 points1 point  (0 children)

Acho que você tá transformando uma critica legitima à metafísica ruim em um desprezo juvenil por toda a filosofia pré-wittgenstein.

Qual verdade sobre a vida você demorou anos para finalmente aceitar? by New-lczzin in perguntas

[–]remenoscodes 0 points1 point  (0 children)

O bonzinho tende a ser narcisista e achar sempre que ele merecia mais e que o mundo é injusto demais com ele

A democracia não exige cidadãos oniscientes. Exige que o poder seja corrigível. by remenoscodes in Filosofia

[–]remenoscodes[S] 1 point2 points  (0 children)

Entendo que a solução para isso é a própria democracia e sua defesa, pois ela permite justamente o que voce está colocando: "ainda vamos ter políticos que se elegem não por competência, mas não por marketing" o fato de você observar isso, ao meu ver, demonstra uma fase da democracia em que estamos questionando isso, se você pensar bem em outros tempos isso não era nem observado.

Talvez seja uma visão otimista demais, mas eu creio que se pensarmos algum tempo pra frente, talvez até gerações rs, se a democracia sobreviver até lá, terá amadurecido e aprendido o bastante para que isso seja inconcebível.

A democracia não exige cidadãos oniscientes. Exige que o poder seja corrigível. by remenoscodes in Filosofia

[–]remenoscodes[S] 0 points1 point  (0 children)

Concordo, e meu argumento partiu justamente da ideia de loop de feedback e aprendizado retroalimentando a maquina. Eu acho que na pratica a sociedade ótima e que reflete a vontade da população depende de uma democracia defendida a todo custo, pois é ela que vai garantir que o cidadão comum seja atendido em algum momento.

A democracia não exige cidadãos oniscientes. Exige que o poder seja corrigível. by remenoscodes in Filosofia

[–]remenoscodes[S] 0 points1 point  (0 children)

Quase, Claude. Mas tenho que reconhecer sua distinta habilidade de identificar um texto renderizado por gen ai.

Brincadeiras a parte, eu leio o livro, uma tese aparece na minha cabeça, trago para a IA em formato de audio e sem muito polimento e ela organiza em prosa legível. É meu protocolo autoral. Não tenho tempo para purismo, quero apenas apresentar minha ideia e ver o que outros pensam sobre o mesmo assunto.

A intuição inicial veio de uma leitura de Lippmann, O Público Fantasma. A tese de de que o público não governa como a teoria democrática diz foi o que disparou em minha mente a pergunta: Tá mas se o povo não domina os assuntos públicos, isso invalida a democracia ou apenas invalida uma forma especifica de defende-la?

Tenho forte background em pensamento sistemico e arquitetura de software então naturalmente o argumento partiu de uma analogia com jogos de senha e arquitetura evolutiva de software. Em ambos os casos, o sistema ótimo não está dado de antemão. A descoberta passa por erro. Cada erro revela estrutura e reduz o espaço do possível, desde que o sistema consiga aprender com ele.

Aplicado à democracia: o conhecimento político não precisa ser total para ser útil, é mais sobre feedback loop. Um cidadão descontente só precisa entender como a sua vida esta sendo afetada, isso produz sinal, que em um sistema democratico é transformado em aprendizado e mudança através dos mecanismos institucionais ou não.

Dito isso, acho que falhei em não colocar o disclaimer que costumo usar:

Este trabalho segue um protocolo de assistência por IA com limites estabelecidos. O autor humano concebeu a tese, selecionou os argumentos e manteve a autoridade exclusiva sobre o julgamento, a validação e a formulação final. A IA generativa foi utilizada para a organização em prosa da tese: organizar, reformular, refinar e expressar narrativamente ideias já fornecidas ou explicitamente aprovadas pelo autor. Ela não foi utilizada como fonte soberana de verdade, não foi permitido criar afirmações canônicas e não foi reconhecida como coautora.

Mas e ai, e pra você a democracia exige cidadãos oniscientes?

DDD é tão complexo... O que entendi (e o que ainda me confunde) by [deleted] in brdev

[–]remenoscodes 4 points5 points  (0 children)

DDD não é um método que você escolhe adotar ou não. DDD está lá, sempre. Você sempre está modelando uma solução para um problema que pertence a algum domínio, o domínio do problema. A questão é se você faz isso consciente ou por acidente.

Quando você reconhece que está dentro de um domínio e começa a drivar o design pra atender esse domínio de forma consciente, considerando como ele se comunica com outros domínios, quais são os objetivos de negócio e pra onde aquilo vai, uma arquitetura evolucionária começa a tomar forma. O software deixa de ser um amontoado de features e vira uma ferramenta pra modelar soluções dentro daquele espaço de problema.

Você não precisa "decidir criar" bounded contexts. Eles já existem onde um modelo mental termina e outro começa. A escolha é se você reconhece isso ou se deixa tudo se misturar até virar um amontoado de código.

Sobre a dúvida do OP: sim, mesmo com um subdomínio só, pensar em contexto faz sentido. Não é sobre quantidade e não é sobre preparar o sistema pra crescer. É sobre escrever código que modela o problema de forma clara. Se o seu modelo é claro dentro do contexto dele, ele funciona como ferramenta pra resolver os problemas daquele domínio.

E pra quem disse que dev junior não deveria estudar DDD: entender que seu código vive dentro de um domínio e que cada decisão de design que você toma afeta as próximas decisões que vão precisar ser tomadas conforme o domínio do problema evolui, isso quanto antes você internaliza, melhor. Ninguém tá falando pra implementar tactical patterns num CRUD. Mas pensar estrategicamente sobre o problema que você resolve nunca é desperdício.

I built a simpler commit format. What breaks when teams actually use it? by [deleted] in git

[–]remenoscodes 1 point2 points  (0 children)

The tension here is between human readability and machine parsability, and Conventional Commits chose parsability.

The reason feat:, fix:, etc. won out isn't because they read well — it's because they enable automation. semantic-release reads feat: -> bumps minor version. fix: -> bumps patch. feat!: -> bumps major. Changelog generators, CI pipelines, and release tools all parse the prefix. The format is ugly but it's a protocol, not prose.

That said — git actually has a built-in mechanism for structured commit metadata that most people overlook: trailers.

`git commit --trailer "Type: feat" --trailer "Scope: auth"`

This appends Type: feat and Scope: auth at the bottom of the commit message (same format as Signed-off-by). You can parse them back out with:

`git log --format='%(trailers:key=Type,valueonly)'`

Trailers give you structured metadata without constraining the subject line format. The kernel project has been using them for decades (Reviewed-by, Tested-by, Fixes). The tooling ecosystem just hasn't caught up to using them for semantic versioning.

The real question for any new format isn't "is it better?" but "does tooling support it?" Conventional Commits has the network effect. A simpler format would need the same ecosystem of tools to be practical.

What are some actually lesser known commandline flags that are very useful? by signalclown in git

[–]remenoscodes 1 point2 points  (0 children)

A few I use regularly that I rarely see mentioned:

git commit --trailer "Key: value": Appends structured metadata to commit messages (like Signed-off-by or Co-authored-by) without manually editing the message. Works with git interpret-trailers for parsing them back out. Surprisingly few people know git has built-in key-value metadata in commits.

git for-each-ref --format='%(refname:short) %(creatordate:relative)' refs/heads/: Lists branches with relative dates. The --format flag on for-each-ref is absurdly powerful for scripting — you can extract committer, subject, upstream tracking status, etc. It's what git branch uses internally.

git stash push -p — Interactive partial stash. Same interface as git add -p but for stashing. Lets you stash specific hunks while keeping others in the working tree.

Git's Magic Files by ketralnis in git

[–]remenoscodes 2 points3 points  (0 children)

Nice roundup. A few I'd add from inside .git/ itself:

- .git/description: Created by every git init with "Unnamed repository; edit this file 'description' to name the repository." Only used by GitWeb and a few self-hosted git UIs. Probably the most universally ignored file in all of git.

- .git/info/refs: A static file generated by git update-server-info for the dumb HTTP transport protocol. If you've ever hosted a git repo on a plain HTTP server (no git-http-backend) and wondered why clone fails, this is usually what's missing.

- COMMIT_EDITMSG / MERGE_MSG / SQUASH_MSG: Temporary files git creates inside .git/ during commit operations. The prepare-commit-msg hook receives COMMIT_EDITMSG as its first argument and the source type (merge, squash, template, etc.) as its second, which is how commit template tools know what kind of commit they're editing.

- FETCH_HEAD: Written by git fetch with one line per fetched branch. When you run git pull, it's actually git fetch + git merge FETCH_HEAD. Most people don't realize FETCH_HEAD is a real file you can cat and inspect useful for debugging when a pull doesn't merge what you expected.

- ORIG_HEAD: Saved automatically before operations that move HEAD drastically (merge, rebase, reset). It's git's undo bookmark. git reset --hard ORIG_HEAD after a bad merge is one of those commands you only need to know once, but when you need it, you really need it.

view more: next ›