Por que o SQLite não usa Git

• O código-fonte do SQLite é gerenciado com Fossil, e não com Git; o Fossil é um sistema de controle de versão projetado e escrito especificamente para dar suporte ao SQLite
• O Fossil oferece um recurso de consciência situacional (situational awareness) que mostra as mudanças recentes de todos os branches em uma única tela, com acesso até mesmo pelo celular
• Enquanto o Git acompanha apenas o histórico anterior de um check-in e torna difícil rastrear seus descendentes, o Fossil exibe com facilidade os check-ins posteriores e a estrutura de branches
• No Git, é preciso manter em mente cinco estados — diretório de trabalho, staging, head local e remoto etc. — enquanto no Fossil basta considerar o diretório de trabalho e o check-in, com 60% menos carga mental
• Mesmo usuários acostumados com Git podem acessar o código-fonte do SQLite da mesma forma por meio do mirror no GitHub, downloads pela web e instalação do Fossil

---

Visão geral e premissas do texto

• O SQLite usa Fossil em vez de Git, e o Fossil é um sistema de controle de versão criado diretamente com o objetivo de dar suporte ao SQLite
• Este texto não é uma comparação entre Fossil e Git, nem recomenda abandonar o uso do Git
  • Se você está satisfeito com Git, pode continuar usando sem problema
  • Se Git não atende tão bem ou se você está pensando em melhorias e alternativas, este texto oferece alguns pontos de vista úteis
• Este documento foi revisado várias vezes para melhorar a clareza e corrigir erros, e o histórico completo de edições pode ser consultado

Por que o SQLite não usa Git

O Git não oferece boa consciência situacional

• A timeline do Fossil fornece, em uma única tela, um resumo das mudanças recentes em todos os branches; com alguns cliques, é possível ver os detalhes, e isso funciona até no celular
• GitHub e GitLab não têm um recurso equivalente
  • A visualização de network é lenta para renderizar (antes do cache), traz poucos detalhes e quase não funciona em dispositivos móveis
  • A visualização de commits é rápida e funciona no celular, mas mostra apenas um branch por vez, o que dificulta saber se você viu todas as mudanças
  • GitHub e GitLab são serviços de terceiros, não componentes centrais do Git, o que cria dependências adicionais
• Usuários de Git costumam instalar visualizadores gráficos de terceiros, mas isso exige instalação e manutenção separadas, além de depender da plataforma
  • Uma das boas ferramentas, o GitUp, funciona apenas no Mac
  • Todas essas ferramentas exigem sincronizar o repositório local e abrir uma GUI de desktop; não dá para verificar o estado do projeto de fora usando o celular

No Git, é difícil encontrar os descendentes de um check-in

• O Git permite olhar para o passado, mas é difícil rastrear o que veio depois
  • Em um determinado check-in antigo, é possível ver o histórico anterior, mas é complicado descobrir o que veio em seguida
• O Fossil oferece uma tela que mostra todos os check-ins derivados do release principal mais recente
• No Git, encontrar descendentes não é impossível, mas é difícil
  • Há uma sequência de comandos para Unix no Stack Overflow, mas ela mostra apenas a lista de descendentes, sem a estrutura de branches
  • Esse comando só funciona com um clone local; não é possível verificar descendentes pela interface web do GitHub ou GitLab
• No Fossil, as informações sobre descendentes aparecem em toda a interface web
  • Todas as páginas de informação de check-in mostram um pequeno gráfico de "Context" com o check-in anterior e o posterior
  • Há recursos que ajudam na consciência situacional, como clicar para ir ao próximo check-in
• Em teoria, isso também pode ser feito no Git com extensões, ferramentas e comandos adequados, mas não é fácil e quase nunca é feito; como resultado, os desenvolvedores têm menos percepção sobre como o código mudou

O modelo mental do Git é desnecessariamente complexo

• Usuários de Git precisam manter em mente estas cinco coisas o tempo todo
  1. diretório de trabalho (working directory)
  2. "index" ou área de staging
  3. head local
  4. cópia local do head remoto
  5. head remoto real
• Usuários de Fossil precisam considerar apenas o diretório de trabalho e o check-in em que estão trabalhando, o que representa 60% menos dispersão de atenção
  • Isso ajuda a economizar os limitados ciclos mentais dos desenvolvedores, permitindo foco maior no software em desenvolvimento
• Um usuário que usa Git e Fossil comentou no HN: "O Fossil me dá a tranquilidade de saber, com um único comando, que tudo foi sincronizado com o servidor; no git eu não tenho essa mesma tranquilidade"

O Git não rastreia nomes antigos de branches

• O Git mantém o DAG completo da sequência de check-ins, mas as tags de branch são informações locais que não são sincronizadas; quando um branch é fechado, esse nome não é preservado, o que torna trabalhoso revisar branches antigos
• Exemplo: se alguém perguntar o que aconteceu com o branch 'prefer-coroutine-sort-subquery' de dois anos atrás
  • Fossil: mostra claramente que esse branch acabou sendo mesclado no trunk, onde começou, e que mudanças do trunk foram mescladas de volta para o branch em duas ocasiões
  • GitHub: não consegue mostrar nada disso e, na prática, é quase inútil para entender o que aconteceu
• GUIs de terceiros podem ser melhores, mas continuam limitadas pelo fato de que o Git não preserva nomes antigos de branches durante a sincronização
  • O simples fato de precisar de ferramentas de terceiros para obter essas informações já é um ponto fraco do sistema principal

O Git exige mais suporte administrativo

• O Git é um software complexo: instalar e atualizar em workstations requer instaladores, e montar um servidor Git também não é simples
  • A maioria das pessoas usa serviços de terceiros como GitHub e GitLab, criando dependências extras
• O Fossil é um único binário independente que basta colocar no $PATH para ficar instalado
  • Esse binário único inclui os recursos centrais do Git e também as funções oferecidas por GitHub e GitLab
  • Ele permite administrar um servidor de comunidade com wiki, rastreamento de bugs, fórum, distribuição de pacotes, gerenciamento de login etc., sem software adicional
  • Criar um servidor de comunidade leva apenas alguns minutos
  • Ele roda bem até em um VPS de US$ 5/mês ou em um Raspberry Pi, enquanto o GitLab e afins exigem máquinas mais robustas
• Quanto menor a carga administrativa, mais tempo os desenvolvedores podem dedicar ao software em si, em vez do sistema de controle de versão

O Git oferece uma experiência de uso ruim

• A tirinha xkcd 1597 é exagerada, mas está perto da realidade
• Há pouco desacordo sobre o fato de que o Git oferece uma experiência de uso inferior, com a implementação interna aparecendo diretamente na interface
  • Existe até um site de paródia que gera páginas man falsas de git, tamanho o problema da interface
• Um bom sistema de controle de versão deve oferecer suporte, não frustração; o Git melhorou nos últimos 10 anos, mas ainda tem um longo caminho pela frente

Guia de acesso ao código-fonte do SQLite para usuários de Git

Mirror oficial no GitHub

• Desde 2019-03-20, existe um mirror Git oficial do código-fonte do SQLite no GitHub
• Ele é gerado por exportação incremental do repositório oficial em Fossil, e um job de cron atualiza o repositório do GitHub uma vez por hora
  • É um mirror unidirecional e somente leitura; não aceita pull requests nem alterações
  • Todas as mudanças entram exclusivamente pelo Fossil
• Os hashes de identificação de check-ins e arquivos diferem entre o mirror Git e o Fossil
  • O principal motivo é que o Fossil usa hash SHA3-256, enquanto o Git usa SHA1
  • Na exportação, o hash original do Fossil é adicionado no rodapé do comentário do check-in; ao referenciar check-ins do SQLite, recomenda-se sempre usar o hash original do Fossil para evitar confusão

Acesso via web

• O repositório Fossil do SQLite oferece links para baixar Tarball, ZIP Archive e SQLite Archive de qualquer versão passada
• O formato das URLs é simples e fácil de integrar em ferramentas de automação
  • Formato básico: https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz
  • Em VERSION, é possível usar prefixo de hash, nome de branch ou tag (por exemplo, "version-3.23.1")
  • Para o release mais recente, use "release"; para o trunk mais recente, use "trunk"
  • Para ZIP e SQLite Archive, troque "/tarball/" por "/zip/" ou "/sqlar/"

Acesso via Fossil

• O Fossil é fácil de instalar e usar, e o texto fornece o procedimento para Unix (no Windows é parecido)
  • Baixe o executável do fossil e coloque-o no $PATH
  • Use fossil clone para clonar o repositório e depois fossil open para abri-lo
  • Em seguida, é possível executar ./configure; make (no Windows com MSVC, nmake /f Makefile.msc)
• Com o comando fossil update VERSION, é possível trocar o checkout para outra versão (em VERSION podem ser usados trunk, prefixo de hash, branch ou tag)
• Dentro do checkout, o comando fossil ui inicia um site local
  • Sem login, não é possível fazer push de mudanças, então você não corre o risco de danificar o projeto e pode explorar e experimentar livremente

Verificação da integridade do código-fonte

• Na raiz da árvore de código-fonte existe um arquivo "manifest"
  • Esse arquivo inclui todos os nomes de arquivos e o hash SHA1 ou SHA3-256 de cada um (arquivos antigos usam SHA1, novos usam SHA3-256)
  • É possível extrair os hashes com um script e compará-los com os arquivos-fonte para verificar a integridade
• O nome hash de um check-in é o hash SHA3-256 do próprio arquivo "manifest"; se a última linha começar com "# Remove this line...", essa linha pode ser ignorada

[GN⁺]

Comentários no Hacker News

• Fiz uma lista das ferramentas de controle de versão que usei ao longo de décadas, com o ano em que foram criadas e o último ano em que as usei: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~presente
  Pelo menos para mim, a vida útil dessas ferramentas foi de mais ou menos 15 anos
  Mas quando digo aos juniores que “quando vocês tiverem a minha idade, git será uma lembrança distante e estranha”, eles me olham de forma esquisita
  git é uma ótima ferramenta e merecia ter sucesso, mas seria uma pena se esse problema terminasse no git

  • Sendo justo, para qualquer tipo de ferramenta, quando o domínio do problema é suficientemente compreendido, a velocidade de mudança diminui
    Havia um texto no Joel on Software dizendo que software em geral fica quase completo por volta da versão 4, e o exemplo era software de escritório, especialmente o Excel
    Se você abrir o Excel 4 hoje, parece verdade no sentido de que ele já faz, em essência, todas as funções principais
    Acho que o git vai durar pelo menos o dobro dos sistemas de controle de versão anteriores
  • O Subversion é basicamente o CVS feito direito
    O problema é que o CVS era um beco sem saída que não conseguia evoluir para um modelo de desenvolvimento distribuído
    O Git voltou ao modelo de RCS local e adicionou commits atômicos, saindo assim do ótimo local que era o Subversion
    Houve escolhas controversas, como não rastrear renomeações ou não ter números de revisão lineares, mas isso não se mostrou um grande problema, e ele permitiu um trabalho muito eficiente sem os problemas de desempenho de algo como o darcs
    Vendo quantas tentativas houve entre 1995 e 2010 de consertar o controle de versão, o modelo de dados fundamental do git parece muito difícil de melhorar, mesmo incluindo extensões como git-lfs
    Pode até surgir uma nova interface de linha de comando, mas ficou cada vez mais difícil desalojar o dominante atual, e não conheço ninguém que use git switch e git restore no lugar do sobrecarregado e confuso git checkout
  • Não sei o que vamos usar daqui a 15 anos, mas o que realmente me deixa triste nessa lista é que em 2015 eu parei de usar mercurial e ainda continuo usando git
  • Na minha primeira empresa, migrei um projeto do clearcase para o git, e mesmo eu, que odiava o clearcase, acho que até então não havia muito motivo para trocar por outra coisa
    Havia um pouco de svn em outros departamentos da empresa, mas era só isso
    Sistemas de controle de versão não mudam tão rápido assim
    As ferramentas da lista antes da chegada do controle de versão distribuído na verdade tinham bastante coisa em comum, e acho que o git vai ficar por muito tempo
  • A internet tende a fixar as coisas
    Historicamente várias línguas foram dominantes, mas o inglês será a língua final; houve várias linguagens de script, mas javascript será a linguagem final; houve vários protocolos de rede, mas TCP/IP será o protocolo final
    Acho que com o git acontece a mesma coisa
    O tipo de coisa que poderia substituir o git seria algo como o glitch[1], em que um ambiente para novos programadores vem com seu próprio sistema de controle de versão embutido
    [1]: https://medium.com/glitch/reinventing-version-control-with-g...

• Acho que o git tem má fama porque ninguém consegue chegar a um acordo sobre como usá-lo
  Basta olhar para GitHub PR e push em branch, rebase e merge: são ferramentas que fazem essencialmente a mesma coisa de maneiras completamente diferentes
  O problema é que nenhum dos lados está errado
  Fazer rebase de commits pequenos reduz a complexidade desnecessária do histórico, e merge preserva o que realmente aconteceu, ajudando a entender por que as mudanças foram feitas
  Claro, merge reverso é o pior, mas isso é outro problema
  Ao fazer push para uma branch, é possível nunca usar force push, mas em branches de PR você acaba sempre usando force push
  Até as coisas fáceis criam divisões impossíveis de resolver
  Eu aprendi a usar o repositório principal como origin e o meu fork como fork, mas algumas pessoas aprendem o repositório principal como upstream e o próprio fork como origin
  Nenhum dos dois está necessariamente errado, mas se origin pode apontar para dois lugares completamente diferentes, fica muito difícil se comunicar com clareza

  • Parafraseando Bjarne Stroustrup, só existem dois tipos de sistema de controle de versão: os de que as pessoas reclamam e os que ninguém usa
  • Uma filosofia que me ajudou foi: “faça o que atende ao objetivo direto do momento e depois reavalie para se adaptar”
    Na prática, faço rebase agressivamente nos commits dentro do PR focando apenas em “o que torna a revisão mais fácil?”
    Quando a revisão termina, pergunto “qual forma será mais fácil de operar e entender daqui para frente?”, e posso dar squash em tudo ou reorganizar em partes independentes e implantáveis para facilitar rollback
    O ponto principal é que essas tarefas podem ter necessidades diferentes, e está tudo bem usar abordagens diferentes em momentos diferentes
    Só que isso exige mais julgamento individual e é mais difícil de ensinar e impor para uma equipe grande inteira
  • É importante distinguir entre desalinhamento local e desalinhamento social
    O primeiro são coisas que não afetam outras pessoas
    Por exemplo, se você nomeia repositórios remotos como origin e upstream, ou como fork e origin, seus colegas não se importam
    O segundo são coisas que precisam de coordenação com outras pessoas
    Por exemplo, questões como qual formato o histórico final do git deve ter
  • O git tem má fama porque a interface de linha de comando é horrivelmente bagunçada
    Se a Apple tivesse projetado a interface de linha de comando do git, ela seria um bilhão de vezes melhor em experiência de uso, com só uns 10% menos poder

• Que o Fossil funcione bem para eles, ótimo, mas esta frase incomoda: “O Fossil é um único binário executável independente que se instala só de colocá-lo no $PATH, e nele já estão tanto os recursos centrais do Git quanto os recursos do GitHub/GitLab…”
  o git pode ter vários problemas, mas não segue essa linha de enfiar até a pia da cozinha no pacote
  eu prefiro mais a abordagem de “fazer uma coisa bem feita”

  • Na verdade, o Git também junta várias coisas que muita gente não conhece bem.
    Por exemplo, se você rodar git instaweb, ele sobe um servidor CGI local e um script CGI em Perl para oferecer uma UI web bem simples: https://git-scm.com/docs/git-instaweb
    Nesse ponto, não é tão diferente dos recursos centrais do Fossil.
    O Git também tem muitos recursos de integração com cliente de e-mail que quem só usa GitHub provavelmente nem sabe que existem, nem por que existem.
    Coisas como git send-email, para mandar patches por e-mail direto do git: https://git-scm.com/docs/git-send-email
  • A ideia de que dá para isolar “uma coisa” e tratá-la como se não fosse ela própria “um conjunto de outras coisas” é um mito bem nocivo no mundo da programação.
    Tudo é composto, tudo é um pipeline de comandos, tudo é feito de várias partes.
    O “trabalho a ser feito” nunca é absoluto, depende da perspectiva de quem olha.
    O princípio da responsabilidade única não se aplica à realidade de forma literal; é só um compromisso para equilibrar coesão e modularidade.
    Onde cortar e chamar de “uma coisa” depende de nós e das nossas necessidades.
    Para muita gente, as ferramentas do GitHub estão tão integradas ao fluxo de trabalho que o Git sozinho é completamente inutilizável.
    Para essas pessoas, o GitHub é “uma coisa”; para o SQLite, existe a “uma coisa” do próprio SQLite.
  • O SQLite é excelente e o Richard claramente é um gênio, mas essa obsessão com um monólito de binário único sempre me pareceu estranha.
    Como foi dito, isso vai contra a filosofia Unix de fazer uma coisa bem.
    Para mim, é claramente mais limpo dividir o sistema em componentes que depois possam ser substituídos ou modificados de forma independente.
  • o git, no ambiente *nix original, não junta tudo até a pia da cozinha, mas o Git para Windows faz isso.
    O instalador tem mais de 50 MB e, se bem me lembro, inclui até terminal.
    Já o Fossil permite baixar um binário executável independente de 3,3 MB para cada plataforma suportada.
  • Como o git não junta essas coisas, você acaba ficando dependente do GitHub ou do GitLab, que fornecem as peças que faltam e que de fato são necessárias em um sistema moderno de controle de código-fonte.

• https://git-man-page-generator.lokaltog.net é a coisa mais engraçada que vi em muito tempo

  • A descrição de git-erase-working-tree como “deve ser usado quando você quiser apagar cuidadosamente a árvore de trabalho atual de um upstream root e configuração, e fazer quiltimport usando a GUI ativa” parece útil
  • git-molest-head como “atormenta incorretamente o head upstream usando o índice remoto e executa os hooks adequados para transformar o head dado em tabela” é meio exageradamente provocativo
  • Demorei tempo demais para perceber que isso não era real.
    O Git tem comandos tão esquisitos que isso já nem surpreende mais.
  • Meus comandos favoritos são git-tease-chain, git-scrub-dangling-object, git-seize-mailmap, git-dress-graft, git-strangle-tree, git-satisfy-daemon e git-pat-tree-object
  • Não soa muito convincente.
    Para falar besteira melhor, faltou mais tempero de LLM.

• Discussões anteriores:
  2021, 356 comentários: https://news.ycombinator.com/item?id=29125934
  2018, 608 comentários: https://news.ycombinator.com/item?id=16806114
  Deve haver mais, mas o mesmo documento pode ser encontrado por vários caminhos — com ou sem o domínio www, com ou sem o caminho /drafts/, com ou sem o caminho /matrix/ — o que torna mais difícil encontrar postagens anteriores

• Há críticas legítimas ao Git aqui, mas algumas são meio estranhas
  Já usei Git em vários contextos, de repositórios locais pessoais a repositórios enormes de empresas, e sinceramente nunca passei por metade desses problemas
  Vale também para a parte de que a “network renderiza devagar, mostra muito menos detalhes e quase não funciona no mobile”, e espero que nunca chegue o dia em que nossa equipe precise considerar dispositivos móveis como meio para verificar o estado das branches
  Nunca nem pensei nesse caso de uso
  Isso acontece com frequência para outras pessoas?

  • O tempo todo
    Acho que pelo menos 50% da exploração de código eu faço no celular
    Uso bastante a interface web móvel do GitHub para isso, e o suporte para encontrar referências ajudou demais
    A busca ainda não é boa, e odeio como a lentidão típica de SPA continua quebrando a simples busca na página
    Quando preciso fuçar no código do Firefox, uso o Searchfox [0], que é rápido, excelente e quase não tenho do que reclamar
    Só acho que o blame no mobile poderia ser melhor
    Para dar contexto, sou pós-graduando, pesquiso linguagens de programação e sistemas, e no tempo livre também mexo bastante com hacking de IoT
    Dependendo de onde você traça a linha geracional, sou um Gen Z mais velho ou o Millennial mais novo possível
    [0] https://searchfox.org
  • Já tentei acompanhar projetos no trem no trajeto de ida e volta para estender minhas horas de trabalho
    Tirando a cobertura de dados instável, o GitHub funcionou bem e dava para fazer code review leve com facilidade
    O GitHub pulse[1] tem uma boa interface para ver atividade recente
    O mirror do SQLite não é trabalhado no GitHub, então só há histórico de commits e essa página fica vazia, mas o projeto Caddy linkado é um exemplo melhor
    Pessoalmente, isso parece mais útil do que uma timeline
    Fico curioso se alguém já fez uma visualização equivalente para git/GitHub
    Não parece que seria tão difícil
    [1] https://github.com/caddyserver/caddy/pulse
  • Uso git para gerenciar meu blog
    Criei um editor para Android para editar no GitHub e depois o adaptei para funcionar também no GitLab
    Há muitos motivos, mas principalmente porque git, seja no GitHub ou no GitLab, é quase impossível de usar no mobile
    Dá para verificar o estado, mas ir além disso é bem difícil
    Esse texto também me tocou bastante em outros aspectos
    Mesmo tendo escrito um livro da O’Reilly sobre GitHub, depois de mais de 10 anos usando git ainda sinto que não entendo tudo completamente
    As observações feitas aqui fazem sentido para mim
  • Não há motivo para esse recurso não funcionar no mobile
    Se tivesse sido melhor projetado e implementado, naturalmente também funcionaria no mobile
    As pessoas acessam o GitHub no mobile pelos mesmos motivos que acessam o GitHub em outras plataformas
    Eu certamente já fiz isso
    Observações como essas sobre git não são necessariamente “problemas”, e sim julgamentos de valor sobre recursos
    Você pode concordar ou discordar, mas não é o tipo de coisa que precisa necessariamente enfrentar
  • Não é o ideal, mas há muitas formas valiosas de manter algo como opção, e é melhor que essas opções funcionem o melhor possível do que não existirem
    Parece a diferença entre degradação gradual e falha imediata
    Por melhor que seja uma opção premium toda enfeitada, se ela for a única opção, ela é frágil e por isso vira lixo

• Há alguns dias vi um vídeo explicando alternativas ao Git, e claro que o Fossil era uma delas
  Já usei Fossil em alguns projetos e achei ok
  O Pijul https://pijul.org/ apresentado nessa palestra pareceu muito interessante, e já foi discutido no HN antes
  Fonte: https://www.youtube.com/watch?v=M4KktA_jbOE

  • Ainda estou tentando entender, mas o jj também é interessante: https://github.com/martinvonz/jj
  • O Pijul sempre foi fascinante
    Parece o Santo Graal do controle de versão
    Mas nos projetos pessoais eu acabo desenvolvendo de forma linear mesmo, e no trabalho não controlo o que usamos, então nunca cheguei a usar de verdade
  • O Pijul poderá ser considerado pronto quando oferecer suporte ao envio de patches por e-mail como alternativa genérica, para que até quem não queira criar uma conta de serviço específica possa enviar patches para upstream

• Usei o Fossil em projetos locais pessoais
  É um sistema de controle de versão bastante competente, e a interface web também é bem boa
  Só vale o aviso de fazer backup frequente do banco de dados do repositório SQLite subjacente
  Depois de atualizar o Fossil, fazer alguns commits e por engano commitar com uma versão mais antiga do Fossil, o banco de dados do repositório Fossil corrompeu de forma irrecuperável, e perdi alguns dias de trabalho
  Em 10 anos de uso diário, o Git nunca corrompeu um repositório por causa de versão, nem uma única vez

  • Como contraponto, eu uso o Fossil de forma totalmente irresponsável
    Tenho versões em sistemas diferentes com anos de diferença entre si, espalhadas de forma aleatória, e continuo usando o binário que estava lá quando configurei o sistema
    Tenho macOS, várias variantes de Linux e algumas máquinas FreeBSD, e se voltar mais no tempo acho que até Windows
    Vou sincronizando tudo isso de forma improvisada
    Alguns repositórios têm mais de 10 anos, um deles tem mais de 10 mil commits e outro tem vários GB porque subi o ambiente de desenvolvimento inteiro
    Às vezes ele diz que precisa de rebuild, e sempre funcionou
    Se encontro um typo no meio de um commit, até interrompo com ctrl-c por hábito
    E mesmo assim ele nunca me decepcionou
    O Fossil é, de longe, o programa mais confiável que já usei
  • Acho difícil concordar com essa afirmação
    O formato de artefatos subjacente do Fossil é compatível desde o início até hoje
    Houve melhorias, mas nenhuma mudança incompatível, e também não houve relatos desse tipo de corrupção entre os muitos usuários do Fossil Forum
    Meu palpite é que você fez check-in de algo usando um recurso aprimorado de uma versão mais nova do Fossil e depois tentou extrair com um Fossil antigo que não entendia esse recurso novo, recebendo um erro
    Por exemplo, no início o Fossil usava apenas hashes SHA1, mas depois do ataque SHAttered ele foi aprimorado para suportar SHA1 e SHA3
    Claro, é só um palpite, mas parece a explicação mais plausível
    Eu nunca fiz um backup puro sequer dos meus repositórios SQLite, do repositório que hospeda o próprio Fossil, nem dos mais de 100 repositórios Fossil que tenho
    Mantenho clones em outras máquinas para recuperação de desastre
    Na verdade, em várias máquinas pelo mundo há jobs de cron rodando sync a cada hora para repositórios Fossil importantes, como o do SQLite
    Mas backup puro, nunca fiz
    Há alguns anos, o repositório principal do SQLite realmente corrompeu uma vez
    De alguma forma, o descritor de arquivo 2 foi fechado, e o banco de dados SQLite do repositório acabou sendo aberto nesse descritor
    Depois, algum bug no Fossil disparou um assert() e escreveu no descritor de arquivo 2, sobrescrevendo parte do banco de dados
    Recuperamos o repositório a partir de um clone, corrigimos a falha de assertion no Fossil e reforçamos o SQLite para não usar descritores de arquivo menores que 3
    Material relacionado: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
  • Isso é um comportamento conhecido?
    Considerando a abordagem de confiabilidade dos desenvolvedores do SQLite, parece algo que deveria ser tratado como um bug crítico a ser corrigido
  • Já tive repositórios git corrompidos
    Mas normalmente não de forma irrecuperável

• Uau, isso me fez mergulhar fundo no assunto
  Provavelmente foi uma das melhores coisas que li em muito tempo
  Parece que dá para usar o Fossil e ainda espelhar para Git/GitHub: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
  A interface embutida parece boa, realmente utilizável e fácil de navegar
  Mas eu queria que ela também suportasse commits pela UI, e não encontrei isso
  Assim não seria preciso misturar linha de comando e interface web para concluir o trabalho
  Se fosse possível criar uma UI wrapper sobre o Fossil com suporte a open, init, commit, sync, sync-with-git, start-web-interface, ou incorporar isso ao próprio Fossil, acho que seria bem útil para pessoas menos técnicas ou não desenvolvedoras que trabalham com código, como gente de biologia, matemática ou ciência de dados gerenciando notebooks Jupyter e afins
  Claro, um cliente simples de UI para git também poderia servir para isso, mas aí se perde a wiki e os tickets embutidos
  A capacidade de trabalhar localmente também é útil, mas o git também permite isso
  De todo modo, já vi pessoas menos técnicas terem aversão a git, ou a controle de versão em geral
  Vejo potencial em ter wiki e tickets embutidos no mesmo repositório
  Também é interessante haver apenas um arquivo para fazer backup

• Para um desenvolvedor de software, um sistema de controle de versão é uma ferramenta como a IDE ou o sistema operacional base
  Quanto menos se mexe nesse tipo de ferramenta, mais produtivo se é
  Tendo usado vários sistemas de controle de versão, o Fossil atinge para mim o sweet spot perfeito
  É literalmente configurar e esquecer