git-fast-import - Online na nuvem

PROGRAMA:

NOME

git-fast-import - Backend para importadores de dados Git rápidos

SINOPSE

front-end | git importação rápida [opções]

DESCRIÇÃO

Geralmente, esse programa não é o que o usuário final deseja executar diretamente. A maioria dos usuários finais deseja
para usar um dos programas de front-end existentes, que analisa um tipo específico de
fonte e alimenta o conteúdo armazenado lá para git importação rápida.

a importação rápida lê um comando misto / fluxo de dados da entrada padrão e grava um ou mais
packfiles diretamente no repositório atual. Quando EOF é recebido na entrada padrão,
importação rápida grava branch atualizado e refs de tag, atualizando totalmente o repositório atual
com os dados recém-importados.

O próprio backend de importação rápida pode importar para um repositório vazio (um que já tenha
foi inicializado por git o init) ou atualizar incrementalmente um repositório populado existente.
Se as importações incrementais são ou não suportadas por uma fonte estrangeira em particular depende
no programa de front-end em uso.

OPÇÕES

--força
Força a atualização de branches existentes modificados, mesmo que isso causasse
perdido (já que o novo commit não contém o antigo).

--quieto
Desative todas as saídas não fatais, tornando a importação rápida silenciosa quando for bem-sucedida. Esse
opção desativa a saída mostrada por --stats.

--Estatísticas
Mostra algumas estatísticas básicas sobre os objetos que a importação rápida criou, os packfiles
eles foram armazenados e a memória usada pela importação rápida durante esta execução. Mostrando
esta saída é atualmente o padrão, mas pode ser desabilitada com --quiet.

Opções for Termina em frente
--cat-blob-fd =
Escreva respostas para consultas get-mark, cat-blob e ls para o descritor de arquivo
em vez de stdout. Permite que a saída de progresso destinada ao usuário final seja separada
de outra saída.

--date-format =
Especifique o tipo de datas que o frontend fornecerá para importação rápida dentro do autor,
comandos committer e tagger. Consulte “Formatos de data” abaixo para obter detalhes sobre quais
formatos são suportados e sua sintaxe.

--feito
Termine com erro se não houver comando concluído no final do fluxo. Esta opção
pode ser útil para detectar erros que fazem com que o front-end seja encerrado antes de
começou a escrever um fluxo.

Localizações of marcas Arquivos
- marcas de exportação =
Despeja a tabela de marcas internas para quando concluído. As marcas são escritas uma por linha
como: markid SHA-1. Os front-ends podem usar este arquivo para validar as importações depois de terem sido
concluída ou para salvar a tabela de marcas em execuções incrementais. Como é apenas
aberto e truncado no ponto de verificação (ou conclusão), o mesmo caminho também pode ser com segurança
dado a --import-marks.

--import-marks =
Antes de processar qualquer entrada, carregue as marcas especificadas em . O arquivo de entrada deve
existir, deve ser legível e deve usar o mesmo formato produzido por --export-marks.
Múltiplas opções podem ser fornecidas para importar mais de um conjunto de marcas. Se uma marca é
definido com valores diferentes, o último arquivo vence.

--import-marks-if-existing =
Como --import-marks, mas em vez de errar, pula silenciosamente o arquivo se isso acontecer
não existe.

- [sem-] marcas relativas
Depois de especificar --relative-marca os caminhos especificados com --import-marks = e
--export-marks = são relativos a um diretório interno no repositório atual. No
git-fast-import isso significa que os caminhos são relativos ao .git / info / fast-import
diretório. No entanto, outros importadores podem usar um local diferente.

Marcas relativas e não relativas podem ser combinadas entrelaçando - (sem -) - marcas relativas
com as opções - (import | export) -marks =.

Desempenho e Compressão sintonização
--active-branches =
Número máximo de ramos para manter ativos de uma vez. Consulte “Utilização de memória” abaixo
para detalhes. O padrão é 5.

--big-file-threshold =
Tamanho máximo de um blob para o qual a importação rápida tentará criar um delta, expresso
em bytes. O padrão é 512m (512 MiB). Alguns importadores podem desejar reduzir isso em
sistemas com memória restrita.

--depth =
Profundidade delta máxima, para deltificação de blob e árvore. O padrão é 10.

--export-pack-edge =
Depois de criar um packfile, imprima uma linha de dados para listando o nome do arquivo do
packfile e o último commit em cada branch que foi gravado naquele packfile. Esse
informações podem ser úteis após a importação de projetos cujo conjunto total de objetos excede o
Limite de packfile de 4 GiB, pois esses commits podem ser usados ​​como pontos de extremidade durante chamadas para git
objetos de pacote.

--max-pack-size =
Tamanho máximo de cada packfile de saída. O padrão é ilimitado.

PERFORMANCE

O design de importação rápida permite importar grandes projetos em uma quantidade mínima de memória
uso e tempo de processamento. Supondo que o front-end seja capaz de acompanhar a importação rápida e
alimentá-lo com um fluxo constante de dados, tempos de importação para projetos com mais de 10 anos de história
e contendo mais de 100,000 commits individuais são geralmente concluídos em apenas 1-2 horas em
hardware bastante modesto (~ $ 2,000 USD).

A maioria dos gargalos parece estar no acesso a dados de fonte estrangeira (a fonte simplesmente não pode
extrair revisões rápido o suficiente) ou IO de disco (importação rápida de gravações tão rápido quanto o disco
pegue os dados). As importações serão mais rápidas se os dados de origem forem armazenados em uma unidade diferente
do que o repositório Git de destino (devido a menos contenção de E / S).

DESENVOLVIMENTO CUSTO

Um front-end típico para importação rápida tende a pesar em cerca de 200 linhas de
Código Perl / Python / Ruby. A maioria dos desenvolvedores foi capaz de criar importadores funcionais em apenas
algumas horas, embora seja sua primeira exposição à importação rápida e, às vezes,
até mesmo para Git. Esta é uma situação ideal, visto que a maioria das ferramentas de conversão são descartadas
(use uma vez e nunca olhe para trás).

PARALELO OPERAÇÃO

Como git empurrar or git buscar, as importações tratadas por importação rápida são seguras para serem executadas ao lado
git repack -a -d ou invocações git gc paralelas ou qualquer outra operação Git (incluindo git
ameixa seca, já que objetos soltos nunca são usados ​​pela importação rápida).

fast-import não bloqueia o branch ou tag refs que está importando ativamente. Depois de
importar, durante sua fase de atualização de ref, a importação rápida testa cada ref de filial existente para verificar
a atualização será uma atualização de avanço rápido (o commit armazenado no ref está contido no
nova história do commit a ser escrito). Se a atualização não for uma atualização de avanço rápido,
a importação rápida irá ignorar a atualização dessa referência e, em vez disso, imprimirá uma mensagem de aviso. importação rápida
sempre tentará atualizar todas as referências do branch e não para na primeira falha.

As atualizações de ramificação podem ser forçadas com --force, mas é recomendado que isso seja usado apenas em
um repositório silencioso. Usar --force não é necessário para uma importação inicial para o
um repositório vazio.

ANÁLISE DISCUSSÃO

a importação rápida rastreia um conjunto de ramificações na memória. Qualquer filial pode ser criada ou modificada em
qualquer ponto durante o processo de importação, enviando um comando commit no fluxo de entrada. Esse
design permite que um programa de front-end processe um número ilimitado de ramos
simultaneamente, gerando confirmações na ordem em que estão disponíveis nos dados de origem.
Também simplifica consideravelmente os programas de front-end.

A importação rápida não usa ou altera o diretório de trabalho atual ou qualquer arquivo dentro dele.
(No entanto, ele atualiza o repositório Git atual, conforme referido por GIT_DIR.) Portanto
um frontend de importação pode usar o diretório de trabalho para seus próprios fins, como extrair
revisões de arquivo da fonte estrangeira. Esta ignorância do diretório de trabalho também
permite que a importação rápida seja executada muito rapidamente, pois não precisa executar nenhum arquivo caro
operações de atualização ao alternar entre ramos.

INPUT FORMATO

Com exceção dos dados do arquivo bruto (que o Git não interpreta), a entrada de importação rápida
o formato é baseado em texto (ASCII). Este formato baseado em texto simplifica o desenvolvimento e depuração
de programas front-end, especialmente quando uma linguagem de nível superior, como Perl, Python ou Ruby
está sendo usado.

a importação rápida é muito rígida quanto à sua entrada. Onde dizemos SP abaixo, queremos dizer exatamente um
espaço. Da mesma forma, LF significa um (e apenas um) avanço de linha e HT um (e apenas um) horizontal
aba. O fornecimento de caracteres de espaço em branco adicionais causará resultados inesperados, como
nomes de ramos ou nomes de arquivos com espaços à esquerda ou à direita em seus nomes, ou
encerramento da importação rápida ao encontrar uma entrada inesperada.

Corrente Comentários
Para ajudar na depuração de interfaces, a importação rápida ignora qualquer linha que comece com # (ASCII
libra / hash) até e incluindo a linha que termina em LF. Uma linha de comentário pode conter qualquer
sequência de bytes que não contém um LF e, portanto, pode ser usada para incluir qualquer
informações detalhadas de depuração que podem ser específicas para o front-end e úteis quando
inspecionar um fluxo de dados de importação rápida.

Data Formatos
Os seguintes formatos de data são suportados. Um frontend deve selecionar o formato que irá usar
para esta importação passando o nome do formato no --date-format = opção de linha de comando.

cru
Este é o formato nativo do Git e é SP . Também é de importação rápida
formato padrão, se --date-format não foi especificado.

A hora do evento é especificada por como o número de segundos desde o UNIX
época (meia-noite, 1 ° de janeiro de 1970, UTC) e é escrito como um inteiro decimal ASCII.

O deslocamento local é especificado por como um deslocamento positivo ou negativo do UTC.
Por exemplo, EST (que está 5 horas atrás do UTC) seria expresso em por “-0500”
enquanto UTC é “+0000”. O deslocamento local não afeta ; é usado apenas como um
conselho para ajudar as rotinas de formatação a exibir o carimbo de data / hora.

Se o deslocamento local não estiver disponível no material de origem, use “+0000” ou o máximo
deslocamento local comum. Por exemplo, muitas organizações têm um repositório CVS que tem
sempre foi acessado por usuários que estão localizados no mesmo local e fuso horário.
Nesse caso, um deslocamento razoável do UTC pode ser assumido.

Ao contrário do formato rfc2822, este formato é muito restrito. Qualquer variação na formatação
fará com que a importação rápida rejeite o valor.

rfc2822
Este é o formato de e-mail padrão, conforme descrito pela RFC 2822.

Um exemplo de valor é “Tue Feb 6 11:22:18 2007 -0500”. O analisador Git é preciso, mas um
pouco no lado tolerante. É o mesmo analisador usado por git am ao aplicar patches
recebido por e-mail.

Algumas strings malformadas podem ser aceitas como datas válidas. Em alguns desses casos, o Git irá
ainda será capaz de obter a data correta da string malformada. Há também
alguns tipos de strings malformadas que o Git analisará incorretamente e, ainda assim, considerará válidas.
Strings seriamente malformadas serão rejeitadas.

Ao contrário do formato bruto acima, as informações de fuso horário / deslocamento UTC contidas em um RFC
2822 string de data é usada para ajustar o valor de data para UTC antes do armazenamento. Portanto
é importante que essas informações sejam o mais precisas possível.

Se o material de origem usa datas no estilo RFC 2822, o frontend deve permitir a importação rápida
lidar com a análise e conversão (ao invés de tentar fazer isso sozinho) como o Git
analisador foi bem testado em estado selvagem.

Os front-ends devem preferir o formato bruto se o material de origem já usa UNIX-epoch
formato, pode ser persuadido a fornecer datas nesse formato, ou seu formato é facilmente
conversível para ele, pois não há ambigüidade na análise.

agora
Sempre use a hora e o fuso horário atuais. O literal agora deve sempre ser fornecido para
.

Este é um formato de brinquedo. A hora e o fuso horário atuais deste sistema são sempre copiados
na sequência de identidade no momento em que está sendo criada por importação rápida. Não há
maneira de especificar um horário ou fuso horário diferente.

Este formato específico é fornecido porque é curto para implementar e pode ser útil para um
processo que deseja criar um novo commit agora, sem a necessidade de usar um
diretório ou git índice de atualização.

Se comandos separados do autor e do committer são usados ​​em um commit, os timestamps não podem
coincidir, pois o relógio do sistema será checado duas vezes (uma para cada comando). O único jeito
para garantir que as informações de identidade do autor e do committer tenham o mesmo carimbo de data / hora
é omitir o autor (copiando assim do committer) ou usar um formato de data diferente
!

comandos
a importação rápida aceita vários comandos para atualizar o repositório atual e controlar o
processo de importação atual. Uma discussão mais detalhada (com exemplos) de cada comando segue
mais tarde.

commit
Cria um novo branch ou atualiza um branch existente criando um novo commit e
atualizando o branch para apontar para o commit recém-criado.

etiqueta
Cria um objeto de tag anotado a partir de um commit ou branch existente. Tags leves
não são suportados por este comando, pois não são recomendados para gravação
pontos significativos no tempo.

redefinir
Redefina uma ramificação existente (ou uma nova ramificação) para uma revisão específica. Este comando deve
ser usado para mudar um branch para uma revisão específica sem fazer um commit nele.

gota
Converta os dados do arquivo bruto em um blob, para uso futuro em um comando de confirmação. Este comando é
opcional e não é necessário para realizar uma importação.

ponto de verificação
Força a importação rápida a fechar o packfile atual, gera sua soma de verificação SHA-1 exclusiva
e indexar e iniciar um novo packfile. Este comando é opcional e não é necessário para
realizar uma importação.

progresso
Faz com que a importação rápida ecoe toda a linha em sua própria saída padrão. Este comando é
opcional e não é necessário para realizar uma importação.

feito
Marca o fim do fluxo. Este comando é opcional, a menos que o recurso feito fosse
solicitado usando a opção de linha de comando --done ou o comando feature done.

obter-marca
Faz com que a importação rápida imprima o SHA-1 correspondente a uma marca para o descritor de arquivo
definido com --cat-blob-fd ou stdout se não for especificado.

gota de gato
Faz com que a importação rápida imprima um blob em arquivo-gato --lote formato para o descritor de arquivo
definido com --cat-blob-fd ou stdout se não for especificado.

ls
Faz com que a importação rápida imprima uma linha que descreve uma entrada de diretório em ls-árvore formato para
o descritor de arquivo definido com --cat-blob-fd ou stdout se não for especificado.

integrado
Habilite o recurso especificado. Isso requer que a importação rápida seja compatível com o especificado
recurso e aborta se não o fizer.

opção
Especifique qualquer uma das opções listadas em OPÇÕES que não mudam a semântica do fluxo para
atender às necessidades do frontend. Este comando é opcional e não é necessário para realizar um
importar.

commit
Crie ou atualize um branch com um novo commit, registrando uma mudança lógica no projeto.

'commit' SP LF
marca?
('autor' (SP )? SP LT GT SP LF)?
'committer' (SP )? SP LT GT SP LF
dados,
('de' SP LF)?
('mesclar' SP LF)?
(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify) *
SE?

Onde é o nome do branch no qual fazer o commit. Normalmente, os nomes dos ramos são
prefixado com refs / heads / no Git, portanto, importar o símbolo de ramificação do CVS RELENG-1_0 usaria
refs / heads / RELENG-1_0 para o valor de . O valor de deve ser um refname válido
no Git. Como LF não é válido em um refname Git, nenhuma sintaxe de aspas ou escape é suportada
Aqui.

Um comando de marca pode aparecer opcionalmente, solicitando importação rápida para salvar uma referência ao
commit recém-criado para uso futuro pelo frontend (veja o formato abaixo). É muito
comum para frontends marcar cada commit que eles criam, permitindo assim futuras ramificações
criação de qualquer confirmação importada.

O comando de dados a seguir ao committer deve fornecer a mensagem de commit (veja abaixo os dados
sintaxe de comando). Para importar uma mensagem de confirmação vazia, use dados de comprimento 0. Enviar mensagens
são de forma livre e não são interpretados pelo Git. Atualmente eles devem ser codificados em UTF-8, como
A importação rápida não permite que outras codificações sejam especificadas.

Zero ou mais filemodify, filedelete, filecopy, filerename, filedeleteall e notemodify
comandos podem ser incluídos para atualizar o conteúdo do ramo antes de criar o
comprometer-se. Esses comandos podem ser fornecidos em qualquer ordem. No entanto, é recomendado que um
O comando filedeleteall precede todos os comandos filemodify, filecopy, filerename e notemodify
no mesmo commit, pois filedeleteall limpa o branch (veja abaixo).

O LF após o comando é opcional (costumava ser obrigatório).

autor
Um comando de autor pode opcionalmente aparecer, se as informações do autor forem diferentes de
as informações do committer. Se o autor for omitido, a importação rápida irá automaticamente
use as informações do committer para a parte do autor do commit. Veja abaixo um
descrição dos campos no autor, pois são idênticos ao committer.

committer
O comando committer indica quem fez esse commit e quando foi feito.

Aqui é o nome de exibição da pessoa (por exemplo, “Com M Itter”) e é
o endereço de e-mail da pessoa (“[email protected]”). LT e GT são literalmente menos que
(\ x3c) e símbolos de maior que (\ x3e). Eles são necessários para delimitar o e-mail
endereço dos outros campos da linha. Observe que e são de forma livre
e pode conter qualquer sequência de bytes, exceto LT, GT e LF. é normalmente UTF-8
codificado.

A hora da mudança é especificada por usando o formato de data que foi selecionado
pelo --date-format = opção de linha de comando. Consulte “Formatos de data” acima para o conjunto
de formatos suportados e sua sintaxe.

da
O comando from é usado para especificar a confirmação a partir da qual inicializar esta ramificação. Esse
revisão será o primeiro ancestral do novo commit. O estado da árvore construída em
este commit começará com o estado no momento do commit e será alterado pelo
modificações de conteúdo neste commit.

Omitir o comando from no primeiro commit de um novo branch causará importação rápida
para criar esse commit sem ancestral. Isso tende a ser desejado apenas para o
commit de um projeto. Se o frontend cria todos os arquivos do zero ao fazer um novo
branch, um comando merge pode ser usado em vez de para iniciar o commit com um vazio
árvore. Omitir o comando from em branches existentes é geralmente desejado, pois o
o commit atual nesse branch é automaticamente considerado o primeiro ancestral do
novo commit.

Como LF não é válido em um refname Git ou expressão SHA-1, nenhuma sintaxe de aspas ou escape
é suportado dentro .

Aqui é qualquer um dos seguintes:

· O nome de uma ramificação existente já na tabela interna de ramificações de importação rápida. Se
o fast-import não sabe o nome, é tratado como uma expressão SHA-1.

· Uma referência de marca: , Onde é o número da marca.

O motivo pelo qual a importação rápida usa: para denotar uma referência de marca é que este caractere não é
legal em um nome de branch Git. O principal: torna mais fácil distinguir entre os
marca 42 (: 42) e o ramal 42 (42 ou refs / heads / 42), ou um SHA-1 abreviado
que passou a consistir apenas em dígitos de base 10.

As marcas devem ser declaradas (por meio da marca) antes de poderem ser usadas.

· Um commit SHA-40 completo de 1 bytes ou abreviado em hexadecimal.

· Qualquer expressão Git SHA-1 válida que resolva para um commit. Veja “ESPECIFICANDO
REVISÕES ”em revisões do gitre(7) para obter detalhes.

· O SHA-1 nulo especial (40 zeros) especifica que o ramo deve ser removido.

O caso especial de reiniciar uma importação incremental do valor do ramo atual
deve ser escrito como:

de refs / chefes / filial ^ 0

O sufixo ^ 0 é necessário porque a importação rápida não permite que um branch comece a partir
em si, e a ramificação é criada na memória antes mesmo que o comando from seja lido de
a entrada. Adicionar ^ 0 forçará a importação rápida para resolver o commit por meio do Git
biblioteca de análise de revisão, em vez de sua tabela de ramificação interna, carregando assim
o valor existente do ramo.

fundir
Inclui um commit de ancestral adicional. O vínculo de ancestralidade adicional não muda
a forma como o estado da árvore é construído neste commit. Se o comando from for omitido quando
criando um novo branch, o primeiro commit de mesclagem será o primeiro ancestral do
commit atual, e o branch começará sem arquivos. Um número ilimitado de
comandos de mesclagem por confirmação são permitidos por importação rápida, estabelecendo assim um n-way
fundir.

Aqui é qualquer uma das expressões de especificação de commit também aceita por de
(Veja acima).

filemodificar
Incluído em um comando de confirmação para adicionar um novo arquivo ou alterar o conteúdo de um existente
Arquivo. Este comando possui dois meios diferentes de especificar o conteúdo do arquivo.

Formato de dados externos
O conteúdo de dados do arquivo já foi fornecido por um comando blob anterior. o
frontend só precisa conectá-lo.

'M' SP SP SP LF

Aqui normalmente deve ser uma referência de marca (: ) definido por um prior
comando blob ou um SHA-40 completo de 1 bytes de um objeto de blob Git existente. Se é
040000` então deve ser o SHA-40 completo de 1 bytes de uma árvore Git existente
objeto ou uma marca de referência definida com --import-marks.

Formato de dados inline
O conteúdo dos dados do arquivo ainda não foi fornecido. O frontend quer
forneça-o como parte deste comando de modificação.

'M' SP SP 'inline' SP LF
dados,

Veja abaixo uma descrição detalhada do comando de dados.

Em ambos os formatos é o tipo de entrada do arquivo, especificado em octal. Git apenas
suporta os seguintes modos:

· 100644 ou 644: Um arquivo normal (não executável). A maioria dos arquivos na maioria
projetos usam este modo. Em caso de dúvida, é isso que você deseja.

· 100755 ou 755: Um arquivo normal, mas executável.

· 120000: Um link simbólico, o conteúdo do arquivo será o destino do link.

· 160000: Um gitlink, SHA-1 do objeto se refere a um commit em outro repositório.
Os links do Git só podem ser especificados por SHA ou por meio de uma marca de confirmação. Eles estão acostumados a
implementar submódulos.

· 040000: Um subdiretório. Os subdiretórios só podem ser especificados por SHA ou por meio de um
marca de árvore definida com --import-marks.

Em ambos os formatos é o caminho completo do arquivo a ser adicionado (se ainda não
existente) ou modificado (se já existente).

UMA string deve usar separadores de diretório no estilo UNIX (barra /), pode
conter qualquer byte diferente de LF e não deve começar com aspas duplas (").

Um caminho pode usar citação de string no estilo C; isso é aceito em todos os casos e obrigatório se
o nome do arquivo começa com aspas duplas ou contém LF. Nas citações de estilo C, o completo
o nome deve estar entre aspas duplas e qualquer LF, barra invertida ou aspas duplas
os caracteres devem ser escapados precedendo-os com uma barra invertida (por exemplo, "caminho / com \ n, \\
e \ "nele").

O valor de deve estar na forma canônica. É isso, não deve:

· Contém um componente de diretório vazio (por exemplo, foo // bar é inválido),

· Terminar com um separador de diretório (por exemplo, foo / é inválido),

· Começar com um separador de diretório (por exemplo, / foo é inválido),

· Contém o componente especial. ou .. (por exemplo, foo /./ bar e foo /../ bar são
inválido).

A raiz da árvore pode ser representada por uma string vazia como .

É recomendado que sempre ser codificado usando UTF-8.

excluir arquivo
Incluído em um comando de confirmação para remover um arquivo ou excluir recursivamente um arquivo inteiro
diretório da filial. Se a remoção do arquivo ou diretório torna seu diretório pai
vazio, o diretório pai também será removido automaticamente. Isso desce em cascata
árvore até que o primeiro diretório não vazio ou a raiz seja alcançada.

'D' SP LF

aqui é o caminho completo do arquivo ou subdiretório a ser removido do
filial. Veja filemodify acima para uma descrição detalhada de .

filecopia
Copia recursivamente um arquivo ou subdiretório existente para um local diferente dentro do
filial. O arquivo ou diretório existente deve existir. Se o destino existir, ele irá
ser completamente substituído pelo conteúdo copiado da fonte.

'C' SP SP LF

aqui o primeiro é o local de origem e o segundo é o destino.
Veja filemodify acima para uma descrição detalhada do que pode parecer. Para usar um
caminho de origem que contém SP o caminho deve ser citado.

Um comando filecopy entra em vigor imediatamente. Uma vez que o local da fonte foi copiado
para o destino, quaisquer comandos futuros aplicados ao local de origem não terão impacto
o destino da cópia.

nome do arquivo
Renomeia um arquivo ou subdiretório existente para um local diferente na ramificação.
O arquivo ou diretório existente deve existir. Se o destino existir, será
substituído pelo diretório de origem.

'R' SP SP LF

aqui o primeiro é o local de origem e o segundo é o destino.
Veja filemodify acima para uma descrição detalhada do que pode parecer. Para usar um
caminho de origem que contém SP o caminho deve ser citado.

Um comando filerename entra em vigor imediatamente. Uma vez que o local de origem foi
renomeado para o destino, quaisquer comandos futuros aplicados ao local de origem irão
criar novos arquivos lá e não impactar o destino da renomeação.

Observe que um nome de arquivo é o mesmo que uma cópia de arquivo seguida por uma exclusão de arquivo do
localização da fonte. Há uma pequena vantagem de desempenho em usar o nome do arquivo, mas o
vantagem é tão pequena que nunca vale a pena tentar converter um par excluir / adicionar em
material de origem em um renomear para importação rápida. Este comando filerename é fornecido
apenas para simplificar os front-ends que já possuem informações de renomeação e não querem se preocupar
com a decomposição em uma filecopia seguida por um filedelete.

arquivodeleteall
Incluído em um comando commit para remover todos os arquivos (e também todos os diretórios) do
filial. Este comando redefine a estrutura de ramificação interna para não ter arquivos nela,
permitindo que o frontend adicione posteriormente todos os arquivos interessantes do zero.

'deleteall' LF

Este comando é extremamente útil se o frontend não souber (ou não se importar em
saber) quais arquivos estão atualmente no branch e, portanto, não pode gerar o
Comandos filedelete para atualizar o conteúdo.

Emitir um filedeleteall seguido pelos comandos filemodify necessários para definir o correto
o conteúdo irá produzir os mesmos resultados que enviar apenas o arquivo necessário e
comandos filedelete. A abordagem filedeleteall pode, no entanto, exigir importação rápida para usar
um pouco mais de memória por branch ativo (menos de 1 MiB, mesmo para a maioria dos projetos grandes);
então front-ends que podem facilmente obter apenas os caminhos afetados para um commit são
encorajados a fazê-lo.

não modificar
Incluído em um commit comando para adicionar uma nova nota anotando um
ou altere o conteúdo desta anotação. Internamente, é semelhante ao filemodify 100644 em
caminho (pode ser dividido em subdiretórios). Não é aconselhável usar qualquer outro
comandos para escrever para o árvore exceto filedeleteall para excluir todos os existentes
notas nesta árvore. Este comando tem dois meios diferentes de especificar o conteúdo de
a anotação.

Formato de dados externos
O conteúdo de dados da nota já foi fornecido por um comando blob anterior. o
frontend só precisa conectá-lo ao commit que deve ser anotado.

'N' SP SP LF

Aqui pode ser uma referência de marca (: ) definido por um blob anterior
ou um SHA-40 completo de 1 bytes de um objeto Git blob existente.

Formato de dados inline
O conteúdo dos dados para a nota ainda não foi fornecido. O frontend quer
forneça-o como parte deste comando de modificação.

'N' SP 'em linha' SP LF
dados,

Veja abaixo uma descrição detalhada do comando de dados.

Em ambos os formatos qualquer uma das expressões de especificação de commit também
aceito por de (veja acima).

marca
Organiza para a importação rápida salvar uma referência ao objeto atual, permitindo que o frontend
para relembrar este objeto em um ponto futuro no tempo, sem saber seu SHA-1. Aqui o
o objeto atual é o comando de criação de objeto no qual o comando marcar aparece. Isso pode ser
commit, tag e blob, mas commit é o uso mais comum.

'marca' SP ':' LF

Onde é o número atribuído pelo frontend a esta marca. O valor de é
expresso como um inteiro decimal ASCII. O valor 0 é reservado e não pode ser usado como um
marca. Somente valores maiores ou iguais a 1 podem ser usados ​​como marcas.

Novas marcas são criadas automaticamente. As marcas existentes podem ser movidas para outro objeto simplesmente
reutilizando o mesmo em outro comando de marca.

etiqueta
Cria uma tag anotada referindo-se a um commit específico. Para criar leve
tags (não anotadas), consulte o comando reset abaixo.

'tag' SP LF
'de' SP LF
'tagger' (SP )? SP LT GT SP LF
dados,

Onde é o nome da tag a ser criada.

Os nomes das tags são automaticamente prefixados com refs / tags / quando armazenados no Git, portanto, importar o
O símbolo de ramificação CVS RELENG-1_0-FINAL usaria apenas RELENG-1_0-FINAL para , e
A importação rápida gravará a referência correspondente como refs / tags / RELENG-1_0-FINAL.

O valor de deve ser um refname válido no Git e, portanto, pode conter forward
barras. Como LF não é válido em um refname Git, nenhuma sintaxe de aspas ou escape é suportada
Aqui.

O comando from é o mesmo que no comando commit; veja acima para detalhes.

O comando tagger usa o mesmo formato do committer dentro do commit; novamente veja acima para
Detalhes.

O comando de dados seguinte ao tagger deve fornecer a mensagem da tag anotada (veja abaixo para
sintaxe de comando de dados). Para importar uma mensagem de tag vazia, use dados de comprimento 0. Mensagens de tag são
de forma livre e não são interpretados pelo Git. Atualmente eles devem ser codificados em UTF-8, como
A importação rápida não permite que outras codificações sejam especificadas.

A assinatura de tags anotadas durante a importação de importação rápida não é suportada. Tentando
incluir sua própria assinatura PGP / GPG não é recomendado, pois o frontend não (facilmente)
tem acesso ao conjunto completo de bytes que normalmente vai para tal assinatura. Se
a assinatura é necessária, crie tags leves de importação rápida com redefinição e
crie as versões anotadas dessas tags off-line com o padrão git etiqueta processo.

redefinir
Cria (ou recria) a ramificação nomeada, opcionalmente a partir de uma revisão específica. o
O comando reset permite que um frontend emita um novo comando from para um branch existente, ou para
crie um novo branch a partir de um commit existente sem criar um novo commit.

'reset' SP LF
('de' SP LF)?
SE?

Para uma descrição detalhada de e veja acima em commit e from.

O LF após o comando é opcional (costumava ser obrigatório).

O comando reset também pode ser usado para criar tags leves (não anotadas). Para
exemplo:

redefinir refs / tags / 938
de: 938

criaria a tag leve refs / tags / 938 referindo-se a qualquer marca de confirmação: 938
referências.

gota
Solicita a gravação de uma revisão de arquivo no packfile. A revisão não está conectada a nenhum
comprometer-se; esta conexão deve ser formada em um comando de confirmação subsequente, referenciando o
blob através de uma marca atribuída.

'blob' LF
marca?
dados,

O comando mark é opcional aqui, pois alguns frontends escolheram gerar o Git SHA-1
para o blob por conta própria, e alimente-o diretamente para cometer. Isso normalmente dá mais trabalho
do que vale a pena, pois as marcas são baratas de armazenar e fáceis de usar.

dados,
Fornece dados brutos (para uso como conteúdo de blob / arquivo, mensagens de confirmação ou tag anotada
mensagens) para importação rápida. Os dados podem ser fornecidos usando uma contagem exata de bytes ou delimitados com
uma linha de terminação. Front-ends reais destinados a conversões de qualidade de produção devem
sempre use o formato de contagem de bytes exata, pois é mais robusto e tem melhor desempenho. o
formato delimitado destina-se principalmente a testar a importação rápida.

Linhas de comentário que aparecem dentro do parte dos comandos de dados são sempre considerados parte
do corpo dos dados e, portanto, nunca são ignorados pela importação rápida. Isso o torna seguro
para importar qualquer arquivo / conteúdo de mensagem cujas linhas possam começar com #.

Formato de contagem exata de bytes
O frontend deve especificar o número de bytes de dados.

'dados' SP LF
LF?

Onde é o número exato de bytes que aparecem dentro . O valor de
é expresso como um número inteiro decimal ASCII. O LF em cada lado do é
não incluído em e não será incluído nos dados importados.

O LF depois é opcional (costumava ser obrigatório), mas recomendado. Sempre
incluindo torna a depuração de um fluxo de importação rápida mais fácil, pois o próximo comando sempre
começa na coluna 0 da próxima linha, mesmo se não terminou com um LF.

Formato delimitado
Uma string delimitadora é usada para marcar o final dos dados. a importação rápida irá computar o
comprimento pesquisando o delimitador. Este formato é útil principalmente para teste e
não é recomendado para dados reais.

'dados' SP '<<' LF
LF
LF
SE?

Onde é a string delimitadora escolhida. A corda não deve aparecer em um
linha por si mesma dentro , caso contrário, a importação rápida pensará que os dados terminam mais cedo
do que realmente faz. O LF imediatamente atrás é parte de . Isso é um
das limitações do formato delimitado, é impossível fornecer um bloco de dados
que não tem um LF como seu último byte.

O LF depois LF é opcional (costumava ser obrigatório).

ponto de verificação
Força a importação rápida a fechar o packfile atual, iniciar um novo e salvar todos
referências, tags e marcas atuais do ramo.

'ponto de verificação' LF
SE?

Observe que a importação rápida muda automaticamente os arquivos de pacote quando o arquivo de pacote atual atinge
--max-pack-size ou 4 GiB, o limite que for menor. Durante uma troca automática de packfile
A importação rápida não atualiza as referências, tags ou marcas do ramo.

Como um ponto de verificação pode exigir uma quantidade significativa de tempo de CPU e IO de disco (para calcular o
soma de verificação geral do pacote SHA-1, gere o arquivo de índice correspondente e atualize as referências)
pode facilmente levar vários minutos para que um único comando de ponto de verificação seja concluído.

Os front-ends podem optar por emitir pontos de verificação durante importações extremamente grandes e de longa duração,
ou quando precisam permitir que outro processo Git acesse um branch. No entanto, dado que um 30
O repositório GiB Subversion pode ser carregado no Git por meio de importação rápida em cerca de 3 horas,
um ponto de verificação explícito pode não ser necessário.

O LF após o comando é opcional (costumava ser obrigatório).

progresso
Faz com que a importação rápida imprima toda a linha de progresso sem modificações em sua saída padrão
canal (descritor de arquivo 1) quando o comando é processado a partir do fluxo de entrada. o
de outra forma, não tem impacto na importação atual, ou em qualquer um dos
Estado.

'progresso' SP LF
SE?

o parte do comando pode conter qualquer sequência de bytes que não contenha LF.
O LF após o comando é opcional. Os chamadores podem desejar processar a saída por meio de um
ferramenta como o sed para remover a parte inicial da linha, por exemplo:

frontend | git fast-import | sed 's / ^ progress //'

Colocar um comando de progresso imediatamente após um ponto de verificação informará o leitor quando o
o ponto de verificação foi concluído e pode acessar com segurança as referências que foram atualizadas com importação rápida.

obter-marca
Faz com que a importação rápida imprima o SHA-1 correspondente a uma marca para stdout ou para o arquivo
descritor previamente organizado com o argumento --cat-blob-fd. O comando de outra forma tem
nenhum impacto na importação atual; seu objetivo é recuperar SHA-1s que posteriormente confirmam
podem querer consultar em suas mensagens de confirmação.

'get-mark' SP ':' LF

Este comando pode ser usado em qualquer lugar no fluxo onde os comentários são aceitos. Em particular,
o comando get-mark pode ser usado no meio de um commit, mas não no meio de um data
comando.

Consulte “Respostas aos comandos” abaixo para obter detalhes sobre como ler esta saída com segurança.

gota de gato
Faz com que a importação rápida imprima um blob em um descritor de arquivo previamente organizado com o
argumento --cat-blob-fd. Caso contrário, o comando não tem impacto na importação atual; Está
objetivo principal é recuperar blobs que podem estar na memória de importação rápida, mas não acessíveis
do repositório de destino.

'cat-blob' SP LF

o pode ser uma referência de marca (: ) definido anteriormente ou um total de 40 bytes
SHA-1 de um blob Git, preexistente ou pronto para ser escrito.

A saída usa o mesmo formato que git cat-file --batch:

SP 'blob' SP LF
LF

Este comando pode ser usado em qualquer lugar no fluxo onde os comentários são aceitos. Em particular,
o comando cat-blob pode ser usado no meio de um commit, mas não no meio de um data
comando.

Consulte “Respostas aos comandos” abaixo para obter detalhes sobre como ler esta saída com segurança.

ls
Imprime informações sobre o objeto em um caminho para um descritor de arquivo previamente organizado
com o argumento --cat-blob-fd. Isso permite imprimir um blob do commit ativo (com
cat-blob) ou copiando um blob ou árvore de um commit anterior para uso no atual
(com filemodify).

O comando ls pode ser usado em qualquer lugar no fluxo em que os comentários sejam aceitos, incluindo
no meio de um commit.

Lendo do commit ativo
Este formulário só pode ser usado no meio de um commit. O caminho nomeia uma entrada de diretório
dentro do commit ativo do fast-import. O caminho deve ser citado neste caso.

'ls' SP LF

Lendo de uma árvore nomeada
o pode ser uma marca de referência (: ) ou o SHA-40 completo de 1 bytes de um Git
tag, commit ou objeto de árvore, preexistente ou esperando para ser escrito. O caminho é
em relação ao nível superior da árvore nomeada por .

'ls' SP SP LF

Veja filemodify acima para uma descrição detalhada de .

A saída usa o mesmo formato que git ls-tree - :

SP ('blob' | 'árvore' | 'confirmar') SP HT LF

o representa o objeto blob, árvore ou commit em e pode ser usado em
mais tarde obter-marca, gota de gato, filemodificar, ou ls comandos.

Se não houver nenhum arquivo ou subárvore nesse caminho, git importação rápida em vez disso, relatará

falta SP LF

Consulte “Respostas aos comandos” abaixo para obter detalhes sobre como ler esta saída com segurança.

integrado
Exija que a importação rápida suporte o recurso especificado ou cancele se não suportar.

'recurso' SP ('=' )? LF

o parte do comando pode ser qualquer um dos seguintes:

formato de data, marcas de exportação, marcas relativas, não marcas relativas, força
Aja como se a opção de linha de comando correspondente com um guia -- foi repassado
a linha de comando (veja OPÇÕES, acima).

marcas de importação, marcas de importação se existir
Como - marcas de importação, exceto em dois aspectos: primeiro, apenas uma "marca de importação de recurso" ou
O comando "feature import-marks-if-existing" é permitido por stream; segundo, um
A opção de linha de comando --import-marks = ou --import-marks-if-existing substitui qualquer um destes
comandos de "recurso" no fluxo; terceiro, "marca de importação de recurso, se existir", como um
a opção de linha de comando correspondente ignora silenciosamente um arquivo inexistente.

get-mark, gato-blob, ls
Exigir que o back-end suporte o obter-marca, gota de gato, ou ls comando respectivamente.
As versões de importação rápida que não suportam o comando especificado sairão com uma mensagem
indicando assim. Isso permite que o erro de importação saia antecipadamente com uma mensagem clara, em vez de
perder tempo na parte inicial de uma importação antes que o comando não suportado seja
detectado.

notas
Exigir que o back-end suporte o não modificar (N) subcomando para o commit comando.
As versões de importação rápida que não suportam notas serão encerradas com uma mensagem indicando isso.

feito
Erro se o stream terminar sem um feito comando. Sem esse recurso, os erros
fazer com que o frontend termine abruptamente em um ponto conveniente no stream pode ir
não detectado. Isso pode ocorrer, por exemplo, se um front-end de importação morre no meio da operação
sem emitir SIGTERM ou SIGKILL em sua instância subordinada git fast-import.

opção
Processa a opção especificada para que git fast-import se comporte de uma forma que se adapte ao
necessidades do frontend. Observe que as opções especificadas pelo frontend são substituídas por qualquer
opções que o usuário pode especificar para fazer a importação rápida de si mesmo.

'opção' SP LF

o parte do comando pode conter qualquer uma das opções listadas nas OPÇÕES
seção que não muda a semântica de importação, sem o -- e é tratado no
da mesma maneira.

Os comandos de opções devem ser os primeiros comandos na entrada (sem contar os comandos de recursos),
fornecer um comando de opção após qualquer comando que não seja de opção é um erro.

As seguintes opções de linha de comando mudam a semântica de importação e, portanto, não podem ser passadas
como opção:

· Formato de data

· Marcas de importação

· Marcas de exportação

· Cat-blob-fd

· força

feito
Se o recurso concluído não estiver em uso, é tratado como se EOF tivesse sido lido. Isso pode ser usado para dizer
importação rápida para terminar mais cedo.

Se a opção de linha de comando --done ou o comando feature done estiver em uso, o comando done é
obrigatório e marca o fim do fluxo.

RESPOSTAS TO COMANDOS

Novos objetos escritos por importação rápida não estão disponíveis imediatamente. Importação mais rápida
os comandos não têm efeito visível até o próximo ponto de verificação (ou conclusão). O frontend
pode enviar comandos para preencher o canal de entrada de importação rápida sem se preocupar com a rapidez com que
terá efeito, o que melhora o desempenho ao simplificar o agendamento.

Para alguns front-ends, porém, é útil ser capaz de ler os dados do atual
repositório à medida que está sendo atualizado (por exemplo, quando o material de origem descreve objetos
em termos de patches a serem aplicados a objetos importados anteriormente). Isso pode ser
realizado conectando o front-end e importação rápida por meio de tubos bidirecionais:

saída rápida de importação mkfifo
a parte dianteira
git fast-import> fast-import-output

Um front-end configurado desta forma pode usar os comandos progress, get-mark, ls e cat-blob para ler
informações da importação em andamento.

Para evitar deadlock, tais front-ends devem consumir completamente qualquer saída pendente de
progress, ls, get-mark e cat-blob antes de realizar gravações para importação rápida que podem
bloquear.

CRASH RELATÓRIOS

Se a importação rápida for fornecida uma entrada inválida, ela será encerrada com um status de saída diferente de zero e
crie um relatório de travamento no nível superior do repositório Git para o qual estava importando. Batida
relatórios contêm um instantâneo do estado de importação rápida interna, bem como o mais recente
comandos que levam ao acidente.

Todos os comandos recentes (incluindo comentários de fluxo, alterações de arquivo e comandos de progresso) são
mostrado no histórico de comando dentro do relatório de travamento, mas dados de arquivo brutos e confirmação
as mensagens são excluídas do relatório de falha. Esta exclusão economiza espaço no relatório
e reduz a quantidade de buffer que a importação rápida deve realizar durante a execução.

Depois de escrever um relatório de falha, a importação rápida fecha o packfile atual e exporta o
mesa de marcas. Isso permite que o desenvolvedor de front-end inspecione o estado do repositório e retome
a importação do ponto em que travou. Os ramos e tags modificados não são atualizados
durante uma falha, pois a importação não foi concluída com êxito. Informações de filial e tag
pode ser encontrado no relatório de travamento e deve ser aplicado manualmente se a atualização for necessária.

Um exemplo de acidente:

$ cat> em <
# meu primeiro commit de teste
commit refs / heads / master
committer Shawn O. Pearce 19283 -0400
# quem é esse cara, afinal?
dados <
este é o meu commit
EOF
M 644 embutido .gitignore
dados <
.gitignore
EOF
Bob inline M 777
END_OF_INPUT

$ git fast-import
fatal: modo corrompido: M 777 bob inline
importação rápida: despejando relatório de falha para .git / fast_import_crash_8434

$ cat .git / fast_import_crash_8434
relatório de falha de importação rápida:
processo de importação rápida: 8434
processo pai: 1391
no sábado, 1 de setembro, 00:58:12 2007

fatal: modo corrompido: M 777 bob inline

Comandos mais recentes antes da falha
---------------------------------
# meu primeiro commit de teste
commit refs / heads / master
committer Shawn O. Pearce 19283 -0400
# quem é esse cara, afinal?
dados <
M 644 embutido .gitignore
dados <
* M 777 bob inline

Filial Ativa LRU
-----------------
ramos_ativos = 1 cur, 5 máx.

nome do relógio pos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 refs / cabeças / mestre

Ramos Inativos
-----------------
refs / heads / master:
status: ativo carregado sujo
dica commit: 0000000000000000000000000000000000000000
árvore velha: 0000000000000000000000000000000000000000
árvore atual: 0000000000000000000000000000000000000000
relógio de confirmação: 0
última embalagem:

-------------------
RELATÓRIO DE FIM DE CRASH

DICAS E TRUQUES

As dicas e truques a seguir foram coletados de vários usuários de importação rápida e
são oferecidos aqui como sugestões.

Uso completa Mark para COMPROMETA-SE
Ao fazer uma conversão de repositório, use uma marca exclusiva por confirmação (marca: ) e abastecimento
a opção --export-marks na linha de comando. a importação rápida irá despejar um arquivo que lista
cada marca e o objeto Git SHA-1 que corresponde a ela. Se o frontend pode amarrar o
marca de volta ao repositório de origem, é fácil verificar a precisão e integridade do
a importação comparando cada commit do Git com a revisão de origem correspondente.

Vindo de um sistema como o Perforce ou Subversion, isso deve ser bastante simples, pois o
A marca de importação rápida também pode ser o número do changeset do Perforce ou a revisão do Subversion
número.

Livremente pular AROUND ramos
Não se preocupe em tentar otimizar o front-end para ficar em um branch por vez durante um
importar. Embora isso possa ser um pouco mais rápido para importação rápida, tende a aumentar
a complexidade do código do frontend consideravelmente.

O branch LRU embutido para importação rápida tende a se comportar muito bem, e o custo de
ativar um ramo inativo é tão baixo que pular entre os ramos
praticamente nenhum impacto no desempenho de importação.

Manipulação Renomeia
Ao importar um arquivo ou diretório renomeado, simplesmente exclua o (s) nome (s) antigo (s) e modifique o
novo (s) nome (s) durante o commit correspondente. Git realiza detecção de renomeação após o fato,
em vez de explicitamente durante um commit.

Uso etiqueta Conserto ramos
Alguns outros sistemas SCM permitem que o usuário crie uma tag a partir de vários arquivos que não são de
o mesmo commit / changeset. Ou para criar tags que são um subconjunto dos arquivos disponíveis em
o repositório.

Importar essas tags como estão no Git é impossível sem fazer pelo menos um commit que
“Corrige” os arquivos para corresponder ao conteúdo da tag. Use o comando de redefinição da importação rápida para
redefina um branch fictício fora de seu espaço de branch normal para o commit de base para a tag,
em seguida, envie um ou mais commits de correção de arquivo e, finalmente, marque o branch fictício.

Por exemplo, uma vez que todos os branches normais são armazenados em refs / heads / name, o ajuste da tag
ramo TAG_FIXUP. Desta forma, é impossível para o ramo de correção usado pelo importador
têm conflitos de namespace com branches reais importados da fonte (o nome TAG_FIXUP
não é refs / heads / TAG_FIXUP).

Ao fazer ajustes, considere usar mesclar para conectar os commits que estão fornecendo
revisões de arquivo para o branch de correção. Isso permitirá que ferramentas como git culpa rastrear
através do histórico real de commits e anote adequadamente os arquivos de origem.

Depois que a importação rápida terminar, o frontend precisará fazer rm .git / TAG_FIXUP para remover o
ramo manequim.

Importar Agora, Repack Later
Assim que a importação rápida for concluída, o repositório Git estará totalmente válido e pronto para uso.
Normalmente, isso leva apenas um tempo muito curto, mesmo para projetos consideravelmente grandes
(Mais de 100,000 confirmações).

No entanto, reembalar o repositório é necessário para melhorar a localização e o acesso dos dados
atuação. Também pode levar horas em projetos extremamente grandes (especialmente se -f e a
o parâmetro --window grande é usado). Uma vez que a reembalagem é segura para ser executada ao lado de leitores e
escritores, execute o repack em segundo plano e deixe-o terminar quando terminar. Não há
razão para esperar para explorar seu novo projeto Git!

Se você optar por esperar pelo reempacotamento, não tente executar benchmarks ou testes de desempenho
até que a reembalagem seja concluída. a importação rápida produz arquivos de pacote subótimos que são simplesmente
nunca visto em situações reais de uso.

Reembalagem Histórico Dados
Se você estiver reembalando dados importados muito antigos (por exemplo, mais antigos do que no ano passado), considere
gastando algum tempo extra de CPU e fornecendo --window = 50 (ou superior) quando você executa git
Reembalar. Isso levará mais tempo, mas também produzirá um packfile menor. Você só precisa
gaste o esforço uma vez, e todos os que usarem seu projeto se beneficiarão com os menores
repositório.

Incluir Alguns Progresso Mensagens
De vez em quando, seu front-end emite uma mensagem de progresso para importação rápida. o
o conteúdo das mensagens é totalmente de formato livre, então uma sugestão seria a saída do
mês e ano atuais cada vez que a data de confirmação atual muda para o mês seguinte. Sua
os usuários se sentirão melhor sabendo quanto do fluxo de dados foi processado.

ARQUIVO DE PACOTE OTIMIZAÇÃO

Ao compactar um blob, a importação rápida sempre tenta deltificar em relação ao último blob gravado.
A menos que seja especificamente organizado pelo front-end, provavelmente não será um anterior
versão do mesmo arquivo, então o delta gerado não será o menor possível. o
O packfile resultante será compactado, mas não será ideal.

Frontends que têm acesso eficiente a todas as revisões de um único arquivo (por exemplo
lendo um arquivo RCS / CVS, v) pode escolher fornecer todas as revisões desse arquivo como uma sequência
de comandos blob consecutivos. Isso permite a importação rápida para deltificar os diferentes arquivos
revisões umas contra as outras, economizando espaço no packfile final. As marcas podem ser usadas para
posteriormente, identificará revisões de arquivos individuais durante uma sequência de comandos de confirmação.

Os packfile (s) criados pela importação rápida não encorajam bons padrões de acesso ao disco. Isto é
causado pela importação rápida gravando os dados na ordem em que são recebidos na entrada padrão,
enquanto Git normalmente organiza dados dentro de packfiles para tornar o mais recente (dica atual)
os dados aparecem antes dos dados históricos. Git também agrupa commits em conjunto, acelerando
passagem de revisão por meio de melhor localidade de cache.

Por este motivo, é altamente recomendável que os usuários recompactem o repositório com git
repack -a -d após a conclusão da importação rápida, permitindo que o Git reorganize os packfiles para
acesso mais rápido aos dados. Se os deltas do blob forem abaixo do ideal (veja acima), então também adicionar o -f
opção de forçar a recomputação de todos os deltas pode reduzir significativamente o packfile final
tamanho (30-50% menor pode ser bastante típico).

MEMÓRIA UTILIZAÇÃO

Há uma série de fatores que afetam quanta memória a importação rápida requer para realizar
uma importação. Como seções críticas do núcleo do Git, a importação rápida usa seus próprios alocadores de memória
para amortizar quaisquer despesas gerais associadas ao malloc. Na prática, a importação rápida tende a
amortize quaisquer despesas indiretas de malloc para 0, devido ao seu uso de grandes alocações de bloco.

para objeto
A importação rápida mantém uma estrutura na memória para cada objeto escrito nesta execução.
Em um sistema de 32 bits, a estrutura é de 32 bytes, em um sistema de 64 bits, a estrutura é de 40 bytes
(devido aos tamanhos maiores do ponteiro). Objetos na tabela não são desalocados até
a importação rápida termina. Importar 2 milhões de objetos em um sistema de 32 bits exigirá
aproximadamente 64 MiB de memória.

A tabela de objetos é, na verdade, uma hashtable codificada no nome do objeto (o SHA-1 exclusivo). Esse
a configuração de armazenamento permite a importação rápida para reutilizar um objeto existente ou já escrito
e evite gravar duplicatas no arquivo de pacote de saída. Blobs duplicados são surpreendentemente
comum em uma importação, normalmente devido a mesclagens de ramificações na origem.

para marca
As marcas são armazenadas em uma matriz esparsa, usando 1 ponteiro (4 bytes ou 8 bytes, dependendo de
tamanho do ponteiro) por marca. Embora a matriz seja esparsa, os front-ends ainda são fortemente
encorajado a usar notas entre 1 e n, onde n é o número total de notas necessárias para
esta importação.

para ramo
Ramificações são classificadas como ativas e inativas. O uso de memória das duas classes é
significativamente diferente.

Os ramos inativos são armazenados em uma estrutura que usa 96 ou 120 bytes (32 ou 64 bits
sistemas, respectivamente), mais o comprimento do nome do ramo (normalmente menos de 200 bytes),
por ramo. a importação rápida irá lidar facilmente com até 10,000 ramos inativos em menos de 2
MiB de memória.

Ramificações ativas têm a mesma sobrecarga que ramificações inativas, mas também contêm cópias de
cada árvore que foi modificada recentemente naquele galho. Se a subárvore incluir não foi
modificado desde que o ramo se tornou ativo, seu conteúdo não será carregado na memória, mas
se subárvore src foi modificado por um commit desde que o branch se tornou ativo, então é
o conteúdo será carregado na memória.

Como branches ativos armazenam metadados sobre os arquivos contidos naquele branch, seus
o tamanho do armazenamento na memória pode aumentar para um tamanho considerável (veja abaixo).

a importação rápida move automaticamente os ramos ativos para o status inativo com base em um simples
algoritmo menos usado recentemente. A cadeia LRU é atualizada em cada comando de confirmação. o
o número máximo de ramos ativos pode ser aumentado ou diminuído na linha de comando com
--active-branches =.

para ativo árvore
Árvores (também conhecidas como diretórios) usam apenas 12 bytes de memória em cima da memória necessária para
suas entradas (consulte “por arquivo ativo” abaixo). O custo de uma árvore é virtualmente 0, pois seu
a sobrecarga amortiza sobre as entradas de arquivo individuais.

para ativo lima entrada
Arquivos (e ponteiros para subárvores) dentro de árvores ativas requerem 52 ou 64 bytes (32/64 bits
plataformas) por entrada. Para economizar espaço, os nomes dos arquivos e árvores são agrupados em uma string comum
tabela, permitindo que o nome do arquivo “Makefile” use apenas 16 bytes (após incluir a string
cabeçalho de cabeçalho), não importa quantas vezes ele ocorra dentro do projeto.

O ramo ativo LRU, quando combinado com o pool de string de nome de arquivo e carregamento lento de
subárvores, permite a importação rápida para importar com eficiência projetos com mais de 2,000 ramos e
Mais de 45,114 arquivos em uma pegada de memória muito limitada (menos de 2.7 MiB por ramificação ativa).

SINAIS

transmissão SIGUSR1 ao git importação rápida processo termina o arquivo de pacote atual mais cedo, simulando
um comando de ponto de verificação. O operador impaciente pode usar esta facilidade para espiar os objetos
e refs de uma importação em andamento, ao custo de algum tempo de execução adicional e pior
compressão.

Use git-fast-import online usando serviços onworks.net