Git é mal concebido?

Não, o Git não é mal concebido. Os dados reais que ele armazena são quase perfeitos e tem apenas dois pequenos erros: o uso do SHA-1 que agora é conhecido por permitir a criação de uma colisão intencional de hash, e o fato de que a profundidade total da história não é armazenada nos objetos de commit. O armazenamento da profundidade não é na verdade estritamente necessário porque você pode sempre calculá-la a partir dos dados disponíveis, mas isso precisa ser recalculado por todas as partes e é sempre estático, então seria melhor tê-la incluída na estrutura de dados. Teria sido necessário apenas 4 bytes adicionais por objeto de commit e teria reduzido muito o uso da CPU sobre todo o uso do git. Algumas pessoas também argumentariam que o git deveria permitir o armazenamento de timestamps para todos os arquivos no commit separado dos timestamps do commit, o que exigiria alterações nos objetos em árvore no armazenamento do git. E commits podem suportar salvar referências a versões antigas de qualquer commit para permitir a visualização de históricos de rebase, se necessário. Essas alterações permitiriam ao git suportar alguns recursos que ele não pode ter atualmente.

O uso do SHA-1 é problemático não apenas para nomear commits, mas as tags assinadas pelo git usam identificadores SHA-1 como o conteúdo dos dados assinados para a ponta do DAG para assinar digitalmente um commit ou tag. Desde que o SHA-1 não tenha um "ataque de pré-imagem conhecido", isso não é realmente um problema, mas mudar para hash mais forte agora tornaria o uso de tags assinadas mais resiliente para ataques futuros. Note que mesmo MD5 ainda não tem um ataque de pré-imagem conhecido, mesmo que a criação de colisão para MD5 seja hoje em dia considerada fácil.

Todos os outros problemas frequentemente percebidos é na verdade o resultado de o git ter 100% de compatibilidade retroativa. Cada pequena e estranha decisão que eles tomaram na interface visível do usuário foi preservada para sempre. Entretanto, essa foi uma decisão ativa que eles tomaram porque os desenvolvedores de git pensaram que não quebrar nenhum fluxo de trabalho existente é mais importante do que ter, por exemplo, bandeiras consistentes para todos os comandos. Isso não diz que o git foi mal projetado, mas que os desenvolvedores consideraram a compatibilidade retroativa mais importante do que a facilidade de aprender o git para novos usuários. Sua preferência pessoal como um novo usuário pode ser diferente. Entretanto, para usuários experientes, nunca quebrar a interface do usuário quando você atualiza o git é uma benção - você sempre recebe apenas novos recursos e correções de bugs e não há razão para continuar usando a versão antiga do git quando uma versão mais nova está disponível. E você não pode ter as duas coisas (ou seja, consertar a interface do usuário antiga e não quebrar 100% de compatibilidade com versões anteriores), então selecionar o caminho que você quer seguir é obviamente uma decisão de design.

Há algum esforço para criar conceitos mais fáceis de entender, como explicar o índice como "área de encenação" (similar às docas do mundo real) e suportar novos comandos, como "git stage" ao invés de "git add" para adicionar coisas à área de encenação (atualmente chamado de "index" no git). No entanto, isso foi adicionado muito tarde no processo e mesmo os iniciantes ainda são informados sobre "git add" ao invés de "git stage", mesmo que este último possa ser mais fácil de entender. Eu acho que isso é porque as pessoas que estão ensinando os iniciantes conhecem apenas a interface antiga.

Além disso, git tem tantas características que é difícil entender tudo isso. Diga-me que o git rebase -i é difícil de usar e eu lhe perguntarei como você faria a mesma ação com svn ou mercurial ou perforce?

O git design é o melhor que poderia existir? Obviamente que não. Mas corrigir as decisões originais de design seria quebrar a compatibilidade com o anterior. Imagine fazer todo o trabalho para corrigir esses dois pequenos erros na estrutura de dados e reimplementar todos os recursos com uma interface de usuário ligeiramente diferente; boa sorte para fazer o mundo inteiro mudar para o seu novo sistema de controle de versão que é apenas marginalmente melhor e não é retrocompatível com seus projetos existentes.