Defina a variável de ambiente GIT_DIR. Consulte git[1].

Forneça mais informações sobre o progresso.

Importar as alterações para <ref> em vez de refs/remotes/p4/master. Se <ref> começar com refs/, ele será usado como está. Caso contrário, se não começar com p4/, esse prefixo será adicionado.

    $ git init
    $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2

Use o algoritmo de detecção de ramificação para encontrar novos caminhos em p4. Ele está documentado abaixo em "DETECÇÃO DO RAMO".

Importe exatamente os números de alteração do p4 listados em file, um por linha. Normalmente, o git p4 inspeciona o estado atual do repositório p4 e detecta as alterações que deve importar.

Não exiba nenhuma informação do progresso.

Consulte a página p4 para os rótulos associados aos caminhos do depósito e adicione-os como tags no Git. Utilidade limitada, pois importa apenas as etiquetas associadas a novas listas de alterações. Descontinuada.

Importe os rótulos do p4 para o Git.

É predefinido que as ramificações p4 sejam armazenadas em refs/remotes/p4/, onde serão tratadas como ramificações de rastreamento remoto pelo git-branch[1] e outros comandos. Em vez disso, essa opção coloca as ramificações p4 em refs/heads/p4/. Observe que as futuras operações de sincronização também devem especificar a opção --import-local para que possam encontrar as ramificações do p4 em refs/heads.

Importe no máximo n alterações, em vez de todo o intervalo de alterações incluído no especificador da revisão informado. Um uso comum seria utilizar @all como especificador da revisão, porém depois utilizar a opção --max-changes 1000 para importar apenas as últimas 1000 revisões, em vez de todo o histórico.

O tamanho do bloco interno que será utilizado ao converter um especificador da revisão como @all numa lista com a quantidade específica de alteração. Em vez de utilizar uma única chamada para p4 changes visando encontrar a lista completa das alterações para a conversão, há uma sequência de chamadas para p4 changes -m, cada uma das quais solicita um bloco de alterações com um tamanho definido. O tamanho padrão do bloco é 500, o que geralmente deve ser o suficiente.

É predefinido que o mapeamento dos nomes dos arquivos do caminho do depósito p4 para o Git, envolve a remoção de todo o caminho do depósito. Com esta opção, o caminho completo do depósito p4 é mantido no Git. Por exemplo, o caminho //depot/main/foo/bar.c, quando for importado de //depot/main/, torna-se foo/bar.c. Com a opção --keep-path, o caminho do Git se torna, depot/main/foo/bar.c.

Use uma especificação de cliente para encontrar a lista de arquivos interessantes no p4. Consulte a seção "ESPECIFICAÇÃO DO CLIENTE" abaixo.

Exclua os caminhos selecionados do depósito durante a clonagem ou sincronização.

Onde criar o repositório Git. Se não for informado, o último componente no caminho do depósito do p4 será usado para criar um novo diretório.

Fazendo uma clonagem simples. Consulte git-clone[1].

O local upstream a partir de onde os commits são identificados para envio ao p4. É predefinido que este é o commit p4 mais recente acessível a partir do HEAD.

Detecte as renomeações. Consulte o comando git-diff[1]. Os renomeamentos serão representados no p4 usando operações explícitas de "mover". Não há opção correspondente para detectar cópias, mas há variáveis para movimentos e para cópias.

Reautorize as alterações do p4 antes de enviá-las ao p4. Essa opção requer privilégios de administrador do p4.

Exporte as tags do Git como etiquetas p4. As tags encontradas no Git são aplicadas ao diretório de trabalho do perforce.

Mostre apenas quais os commits seriam enviados ao p4; não mude de condição no Git ou no p4.

Aplique um commit ao espaço de trabalho do p4, abrindo, adicionando e excluindo arquivos no p4 como numa operação normal de envio. Não emita o "p4 submit" final, mas imprima uma mensagem sobre como enviar manualmente ou de como reverter. Esta opção sempre é interrompida após o primeiro commit (mais antigo). As etiquetas Git não são exportadas para o p4.

Em vez de enviar, crie o armazenamento de uma série de listas de alterações. Após criar cada espaço de armazenamento, os arquivos relevantes são revertidos/excluídos. Se você tiver vários commits pendentes, serão criados vários espaços de armazenamento.

Atualize uma lista de alterações existentes que foram arquivadas com este commit. Implica no uso da opção --shelve. Repita o procedimento para as várias listas de alterações que foram arquivadas.

Podem ocorrer conflitos ao aplicar um commit ao p4. Quando isso acontece, o comportamento predefinido ("ask") é lhe perguntar se você quer pular este commit e continuar ou encerrar. Essa opção pode ser usada para ignorar o aviso, fazendo com que os commits conflitantes sejam automaticamente ignorados, ou para parar de tentar aplicar os commits, sem aviso.

Após o envio, sincronize este ramo nomeado em vez do p4/master predefinido. Para mais informações consulte a seção "Opções de sincronização" acima.

Envie apenas o commit ou o intervalo dos commits informados, em vez da lista completa de alterações que estão no ramo Git atual.

Desative a nova reconstrução automática depois que todos os commits forem enviados com êxito. Também pode ser definido com git-p4.disableRebase.

Desative a sincronização automática do p4/master do "Perforce" depois que os commits tenham sido enviados. Implica no uso da opção --disable-rebase. Também pode ser definido com git-p4.disableP4Sync. A sincronização com origin/master se for possível ainda continua.

Importe as etiquetas p4.

Define o git refspec onde a lista de alterações P4 arquivada é comparada. A predefinição é p4/master.

Usuário especificado como uma opção para todos os comandos p4, com -u <usuário>. Em vez disso, pode ser usada a variável de ambiente P4USER.

A senha especificada como uma opção para todos os comandos p4, com -P <senha>. Em vez disso, pode ser usada a variável de ambiente P4PASS.

Porta especificada como uma opção para todos os comandos p4, com -p <porta>. Em vez disso, pode ser usada a variável de ambiente P4PORT.

O host é especificado como uma opção para todos os comandos p4, com -h <host>. Em vez disso, pode ser usada a variável de ambiente P4HOST.

Específico do cliente como uma opção para todos os comandos p4, com -c <cliente>, incluindo a definição do cliente.

Especifica o número de vezes para tentar novamente um comando p4 (notadamente, p4 sync) se a rede atingir o tempo limite. O valor predefinido é 3. Defina o valor como 0 para desativar as tentativas ou se a sua versão do p4 não for compatível com tentativas (anterior a 2012.2).

Como a importação dos commits de outros repositórios Git é muito mais rápido do que a importação do p4, existe um mecanismo para encontrar as alterações do p4 primeiro nos repositórios remotos do Git. Se houver ramificações em refs/remote/origin/p4, elas serão obtidas e usadas ao sincronizar a partir do p4. Essa variável pode ser definida como false para desativar este comportamento.

Uma fase da detecção de ramificação envolve a análise das ramificações do p4 para encontrar as novas ramificações que serão importadas. É predefinido que todas as ramificações sejam inspecionadas. Esta opção limita a pesquisa apenas àqueles pertencentes ao único usuário nomeado na variável.

Lista das ramificações a serem importadas quando a detecção das ramificações estiver ativada. Cada entrada deve ser um par de nomes das ramificações separados por dois-pontos (:). Este exemplo declara que tanto o branchA quanto o branchB foram criados a partir de main:

git config       git-p4.branchList main:branchA
git config --add git-p4.branchList main:branchB

Lista das etiquetas p4 que serão ignoradas. Isso é criado automaticamente à medida que etiquetas não importantes forem descobertas.

Importe os rótulos p4 para o git, conforme --import-labels.

Apenas os rótulos p4 coincidentes com esta expressão regular serão importados. O valor predefinido é [a-zA-Z0-9_\-.]+$.

Especifique que a especificação do cliente p4 deve ser usada para identificar os caminhos do depósito p4 de interesse. Isso é equivalente a usar a opção --use-client-spec. Consulte a seção "ESPECIFICAÇÃO DO CLIENTE" acima. Esta variável é um booleano, não o nome de um cliente p4.

O "Perforce" mantém a codificação de um caminho conforme fornecido pelo sistema operacional de origem. O Git espera que os caminhos estejam codificados como UTF-8. Use esta configuração para informar ao git-p4 qual codificação o "Perforce" usou nos caminhos. Esta codificação é usada para transcodificar os caminhos para UTF-8. Por exemplo, o "Perforce" no Windows geralmente usa "cp1252" para codificar os nomes dos caminhos. Se esta opção for passada numa solicitação de clone p4, ela será mantida no novo repositório git resultante.

O "Perforce" mantém a codificação das descrições de uma lista de alterações e dos nomes completos dos usuários, conforme vão sendo armazenados pelo cliente num determinado sistema operacional. O cliente p4v usa a codificação local do sistema operacional e, portanto, diferentes usuários podem acabar armazenando diferentes descrições de listas de alterações ou nomes completos de usuários em diferentes codificações, no mesmo depósito. O Git tolera codificações inconsistentes/incorretas nas mensagens de commit e nos nomes dos autores, mas espera que elas sejam especificadas como utf-8. O git-p4 pode usar três estratégias de decodificação diferentes para lidar com a incerteza de codificação no "Perforce": "passthrough" simplesmente passa os bytes originais do "Perforce" para o git, criando dados utilizáveis, mas incorretamente codificados, quando os dados do "Perforce" são codificados como algo diferente de utf-8. O strict espera que os dados do "Perforce" sejam codificados como utf-8 e falha na importação quando isso não é verdade. O fallback tenta interpretar os dados como utf-8 e, caso contrário, volta a usar uma codificação secundária - é predefinido que a codificação comum do Windows cp-1252 - com escape de bytes de faixa superior se a decodificação com a codificação de contingência também falhar. No python2, a estratégia padrão é passthrough por motivos históricos, e no python3 a predefinição é fallback. Quando strict for selecionado e a decodificação falhar, a mensagem de erro indicará a alteração desse parâmetro de configuração como uma solução alternativa. Se esta opção for usada numa solicitação de clone p4, ela será mantida no novo repositório git resultante.

Especifique a codificação substituta que será utilizada ao decodificar os nomes dos autores e das descrições de listas das alterações do Perforce usando a estratégia fallback (consulte git-p4.metadataDecodingStrategy). A codificação substituta só será usada quando a decodificação como utf-8 falhar. Essa opção é padronizada para cp1252, uma codificação comum do Windows. Se esta opção for passada para uma solicitação de clonagem p4, ela será mantida no novo repositório git resultante.

Especifique o sistema que é usado para arquivos grandes (binários). Observe que os sistemas de arquivos grandes não são compatíveis com o comando git p4 submit. Apenas o Git LFS está implementado no momento (para mais informações consulte https://git-lfs.github.com/). Baixe e instale a extensão de linha de comando do Git LFS para usar essa opção e configure-a da seguinte maneira:

git config       git-p4.largeFileSystem GitLFS

Todos os arquivos que coincidam com uma extensão do arquivo na lista serão processados pelo grande sistema de arquivos. Não prefixe as extensões com ..

Todos os arquivos onde seu tamanho descompactado exceda o limite, os maiores arquivos serão processados pelo sistema. A predefinição retorna para que o limite seja definido em bytes. Adicione o sufixo k, m ou g para alterar a unidade.

All files with a compressed size exceeding the threshold will be processed by the large file system. This option might slow down your clone/sync process. É predefinido que o limite seja definido em bytes. Adicione o sufixo k, m ou g para alterar a unidade.

A variável booleana que define se arquivos grandes são automaticamente enviados para um servidor.

Uma lista de alterações que contenha apenas com os arquivos que foram excluídos será importada como um commit vazia, caso esta opção estiver configurada como true.

Mapeie um usuário P4 para um nome e endereço de e-mail no Git. Para criar um mapeamento, utilize uma sequência com o seguinte formato:

git config --add git-p4.mapUser "p4user = Primeiro Último <mail@address.com>"

Detecte as renomeações. Consulte o comando git-diff[1]. Isso pode ser true (verdadeiro), false (falso) ou uma pontuação conforme esperado pelo comando git diff -M.

Detecte as cópias. Consulte o comando git-diff[1]. Isso pode ser true (verdadeiro), false (falso) ou uma pontuação conforme esperado pelo comando git diff -C.

Detecta cópias com mais intensidade. Consulte o comando git-diff[1]. Um booleano.

Ao enviar, recrie as alterações do usuário para refletir o autor do Git, independentemente de quem chame o comando git p4 submit.

Quando preserveUser for verdadeiro, o comando git p4 normalmente é encerrado se não conseguir encontrar um autor no mapa de usuários do p4. Esta configuração envia a alteração de qualquer maneira.

O processo de envio invoca o editor antes de cada alteração do p4 ser enviado. No entanto, se esta configuração for verdadeira, a etapa de edição será ignorada.

Após editar a mensagem de alteração do p4, o git p4 se certifica de que a descrição foi realmente alterada, observando o tempo de modificação do arquivo. Essa opção desativa este teste.

É predefinido que qualquer ramificação pode ser usado como uma fonte para uma operação git p4 submit. Essa variável de configuração, se definida, permite que apenas as ramificações mencionadas sejam usadas como origens de envio. Os nomes das ramificações devem ser os nomes curtos (sem refs/heads/) e devem ser separados por vírgulas (","), sem espaços.

Se o usuário que estiver executando o comando git p4 submit não existir no mapa de usuários do p4, o git p4 será encerrado. Esta opção pode ser usada para forçar o envio independentemente disso.

Caso seja ativado, o git p4 submit tentará limpar as palavras-chave do RCS ($Header$, etc). Caso contrário, eles causariam conflitos na mesclagem e impediriam que o envio prossiga. no momento, esta opção deve ser considerada experimental.

Exporte as tags Git para os rótulos p4, conforme a opção --export-labels.

Somente rótulos p4 correspondentes a essa expressão regular serão exportados. O valor predefinido é [a-zA-Z0-9_\-.]+$.

Especifica o comportamento de envio quando um conflito com o p4 é encontrado, conforme --conflict. O comportamento predefinido é ask.

Não faça a reconstrução da árvore contra p4/master após um envio.

Não sincronize o p4/master com o "Perforce" após o envio. Implies git-p4.disableRebase.