{"id":104517,"date":"2022-06-28T09:36:45","date_gmt":"2022-06-28T07:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-37"},"modified":"2022-06-28T09:36:45","modified_gmt":"2022-06-28T07:36:45","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-37","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-37","title":{"rendered":"Lan\u00e7amento do sistema de controle de vers\u00e3o Git 2.37","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Foi lan\u00e7ado o vers\u00e3o 2.37 do sistema distribu\u00eddo de controle de vers\u00f5es Git. O Git \u00e9 um dos sistemas de controle de vers\u00f5es mais populares, confi\u00e1veis e de alto desempenho, oferecendo ferramentas flex\u00edveis para desenvolvimento n\u00e3o-linear, com base em branching e merging. Para garantir a integridade do hist\u00f3rico e resist\u00eancia a altera\u00e7\u00f5es 'retroativas', \u00e9 utilizado um hash impl\u00edcito de todo o hist\u00f3rico anterior em cada commit, al\u00e9m da possibilidade de valida\u00e7\u00e3o digital das assinaturas dos desenvolvedores em tags e commits espec\u00edficos. <\/p>\n
Em compara\u00e7\u00e3o com a vers\u00e3o anterior, esta nova vers\u00e3o incorpora 395 altera\u00e7\u00f5es, preparadas com a participa\u00e7\u00e3o de 75 desenvolvedores, dos quais 20 participaram do desenvolvimento pela primeira vez. As principais novidades incluem: <\/p>\n
\n
O mecanismo de \u00edndices parciais (sparse index) foi preparado para uso geral, abrangendo apenas uma parte do reposit\u00f3rio. Os \u00edndices parciais permitem aumentar a performance e economizar espa\u00e7o em reposit\u00f3rios onde s\u00e3o realizadas opera\u00e7\u00f5es de clonagem parcial (sparse-checkout) ou onde se trabalha com uma c\u00f3pia incompleta do reposit\u00f3rio. Na nova vers\u00e3o, foi conclu\u00eddo o trabalho de integra\u00e7\u00e3o dos \u00edndices parciais nos comandos 'git show', 'git sparse-checkout' e 'git stash'. O ganho de desempenho mais not\u00e1vel ao usar \u00edndices parciais \u00e9 observado no comando 'git stash', cuja velocidade de execu\u00e7\u00e3o aumentou em at\u00e9 80% em certas situa\u00e7\u00f5es.\n
Foi implementado um novo mecanismo 'cruft packs' para empacotar objetos inating\u00edveis (unreachable), que n\u00e3o possuem refer\u00eancias no reposit\u00f3rio (sem refer\u00eancias de branches ou tags). Objetos inating\u00edveis s\u00e3o removidos pelo coletor de lixo, mas permanecem no reposit\u00f3rio por um certo tempo antes da remo\u00e7\u00e3o para evitar condi\u00e7\u00f5es de corrida. Para rastrear o per\u00edodo de perman\u00eancia dos objetos inating\u00edveis, \u00e9 necess\u00e1ria a vincula\u00e7\u00e3o de etiquetas com a hora de modifica\u00e7\u00e3o desses objetos, o que impede que eles sejam armazenados em um \u00fanico arquivo pack, onde todos os objetos t\u00eam o mesmo hor\u00e1rio de modifica\u00e7\u00e3o. A abordagem anterior de armazenar cada objeto em um arquivo separado causava problemas na presen\u00e7a de um grande n\u00famero de novos objetos inating\u00edveis que ainda n\u00e3o estavam prontos para remo\u00e7\u00e3o. O mecanismo proposto 'cruft packs' permite armazenar todos os objetos inating\u00edveis em um \u00fanico arquivo pack, enquanto os dados sobre o hor\u00e1rio de modifica\u00e7\u00e3o de cada objeto s\u00e3o refletidos em uma tabela separada, armazenada em um arquivo com a extens\u00e3o '.mtimes'.\n
Para Windows e macOS, h\u00e1 um mecanismo embutido para monitorar altera\u00e7\u00f5es no sistema de arquivos, permitindo evitar a varredura de todo o diret\u00f3rio de trabalho ao executar opera\u00e7\u00f5es como «git status». Anteriormente, para monitorar altera\u00e7\u00f5es atrav\u00e9s de hooks, era poss\u00edvel usar utilit\u00e1rios externos de monitoramento de mudan\u00e7as no sistema de arquivos, como o Watchman, mas isso exigia a instala\u00e7\u00e3o de programas adicionais e configura\u00e7\u00e3o. Agora, essa funcionalidade est\u00e1 embutida e pode ser ativada com o comando «git config core.fsmonitor true».\n
No comando «git sparse-checkout», o suporte ao modo alternativo «—cone» para a defini\u00e7\u00e3o de padr\u00f5es para clonagem parcial foi declarado obsoleto, permitindo que, ao definir a parte do reposit\u00f3rio que se encaixa na opera\u00e7\u00e3o de clonagem, arquivos individuais sejam listados usando a sintaxe «.gitignore», o que impede a utiliza\u00e7\u00e3o de \u00edndices parciais para otimiza\u00e7\u00e3o.\n
A flexibilidade na configura\u00e7\u00e3o da chamada do fsync() para descarregar altera\u00e7\u00f5es no disco foi aumentada. No par\u00e2metro «core.fsyncMethod», foi adicionada a estrat\u00e9gia de sincroniza\u00e7\u00e3o «batch», que permite acelerar opera\u00e7\u00f5es ao escrever um grande n\u00famero de arquivos individuais, acumulando altera\u00e7\u00f5es em um cache de grava\u00e7\u00e3o revertido e descarregando-as em uma \u00fanica chamada do fsync(). Um teste foi realizado, onde foram adicionados 500 arquivos com o comando «git add», e com o novo modo, isso foi conclu\u00eddo em 0,15 segundos, enquanto chamar fsync() para cada arquivo levou 1,88 segundos, e sem usar fsync \u2014 0,06 segundos.\n
Nos comandos de itera\u00e7\u00e3o de branches, como «git log» e «git rev-list», foi adicionada a op\u00e7\u00e3o » —since-as-filter=X», que permite filtrar a informa\u00e7\u00e3o sobre commits cuja data de cria\u00e7\u00e3o \u00e9 anterior a «X». Diferente da op\u00e7\u00e3o «—since», o novo comando \u00e9 implementado como um filtro, que n\u00e3o interrompe a itera\u00e7\u00e3o ap\u00f3s o primeiro commit que \u00e9 mais antigo que o tempo especificado.\n
No comando «git remote», ao especificar a flag «-v», \u00e9 garantido que informa\u00e7\u00f5es sobre clones parciais do reposit\u00f3rio sejam exibidas.\n
Adicionada a configura\u00e7\u00e3o «transfer.credentialsInUrl», que pode aceitar os valores «warn», «die» e «allow». Caso sejam fornecidas credenciais em texto claro no par\u00e2metro «remote.<name>.url», a tentativa de executar opera\u00e7\u00f5es «fetch» ou «push» falhar\u00e1 com um erro se a configura\u00e7\u00e3o «transfer.credentialsInUrl» estiver definida como «die», ou resultar\u00e1 em um aviso se estiver definida como «warn».\n
Por padr\u00e3o, est\u00e1 em uso uma nova implementa\u00e7\u00e3o do modo interativo do comando «git add -i», reescrita de Perl para C. <\/ul>\n