Git
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-p4 last updated in 2.34.1

NOME

git-p4 - Importe e envie para os repositórios Perforce

RESUMO

git p4 clone [<opções-de-sincronismo>] [<opções-da-clonagem>] <caminho-do-depósito-p4>…​
git p4 sync [<opções-de-sincronismo>] [<caminho-do-depósito-p4>…​]
git p4 rebase
git p4 submit [<opções-de-envio>] [<nome-do-ramo-master>]

DESCRIÇÃO

Este comando fornece uma maneira de interagir com os repositórios p4 utilizando o Git.

Crie um novo repositório Git a partir de um repositório p4 já existente utilizando o comando git p4 clone, informando a ele um ou mais caminhos para o depósito p4. Incorpore os novos commits das alterações do p4 com o comando git p4 sync. O comando sync também é utilizado para incluir as novas ramificações vindas dos outros caminhos do depósito p4. Envie as alterações do Git de volta para o p4 utilizando o comando git p4 submit. O comando git p4 rebase faz uma sincronização a mais e reconstrói o ramo atual no ramo remoto p4 já atualizado.

EXEMPLOS

  • Clone um repositório:

    $ git p4 clone //depot/path/project

  • Faça algum trabalho no repositório Git recém-criado:

    $ cd project
$ vi foo.h
$ git commit -a -m "foo.h editado"

  • Atualize o repositório Git com as alterações recentes vindos do p4, reorganizando o seu trabalho no topo:

    $ git p4 rebase

  • Envie os seus commits de volta para p4:

    $ git p4 submit

COMANDOS

Clone

Geralmente, o comando git p4 clone é utilizado para criar um novo diretório Git a partir de um repositório p4 já existente:

$ git p4 clone //depot/path/project

Este:

  1. Cria um repositório Git vazio em um subdiretório chamado project.

  2. Importa todo o conteúdo da revisão principal do caminho do depósito p4 informado em um único commit no ramo Git refs/remotes/p4/master.

  3. Cria um ramo local, master, deste ramo remoto e faz uma averiguação.

Para reproduzir todo o histórico p4 no Git, utilize o modificador @all no caminho do depósito:

$ git p4 clone //depot/path/project@all

Sync

À medida que o desenvolvimento continua no repositório p4, estas alterações podem ser incluídas no repositório Git utilizando:

$ git p4 sync

Este comando encontra as novas alterações no p4 e as importa conforme o Git realiza os commits.

Os repositórios P4 podem ser adicionados a um repositório Git já existente também utilizando o comando git p4 sync:

$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //path/in/your/perforce/depot

Faz a importação do depósito informado para refs/remotes/p4/master em um repositório Git já existente. A opção --branch pode ser utilizada para definir um ramo diferente que será utilizado no conteúdo do p4.

Caso um repositório Git inclua as ramificações refs/remotes/origin/p4, elas serão buscadas e consultadas primeiro durante um comando git p4 sync. Como a importação direta do p4 é consideravelmente mais lento do que extrair as alterações de um ramo Git remoto, pode ser útil em um ambiente com vários desenvolvedores.

Caso haja várias ramificações, ao executar o comando git p4 sync utilizará de forma automática o algoritmo "DETECÇÃO DO RAMO" para tentar particionar as novas alterações na ramificação correta. Pode ser substituído pela opção --branch para definir apenas um único ramo que será atualizado.

Rebase

Um padrão de trabalho comum é buscar as alterações mais recentes do depósito p4 e mesclá-las com os commits que não foram alterados localmente. Frequentemente, o repositório p4 é o local definitivo para todo o código, portanto, um fluxo de trabalho de reconstrução da fundação faz todo o sentido. Este comando executa o comando git p4 sync seguido do comando git rebase para mover os commits locais no topo das alterações atualizadas do p4.

$ git p4 rebase

Envio

O envio das alterações de um repositório Git de volta para o repositório p4, requer um espaço de trabalho do cliente p4 separado. Isso deve ser definido utilizando a variável de ambiente P4CLIENT ou a variável de configuração Git git-p4.client. O cliente p4 deve existir, porém a raiz do cliente será criada e preenchida caso ainda não exista.

Para enviar todas as alterações que estão no ramo Git atual, mas não no ramo p4/master, utilize:

$ git p4 submit

Para definir um ramo diferente do atual, utilize:

$ git p4 submit topicbranch

Para definir um único commit ou um intervalo de commits, utilize:

$ git p4 submit --commit <sha1>
$ git p4 submit --commit <sha1..sha1>

A referência upstream geralmente é refs/remotes/p4/master, mas pode ser substituída utilizando a opção da linha de comando --origin=.

As alterações no p4 serão criadas à medida que o usuário utilize o comando git p4 submit. A opção --preserve-user fará com que a propriedade seja modificada de acordo com o autor do commit. Esta opção requer privilégios de administrador em p4, que podem ser concedidos utilizando p4 protect.

Para arquivar as alterações em vez de enviá-las, utilize --shelve e --update-shelve:

$ git p4 submit --shelve
$ git p4 submit --update-shelve 1234 --update-shelve 2345

Unshelve

O desarquivamento pega uma lista de alterações P4 arquivada e produz o commit equivalente com o git no ramo refs/remotes/p4-unshelved/<changelist>.

O commit do git é criado com relação à revisão da origem atual (a predefinição retorna para HEAD). Um parente de um commit é criado com base na origem e em seguida, o commit desarquivado é criado com base nisso.

A revisão da origem pode ser alterada com a opção "--origin".

Se o ramo de destino em refs/remotes/p4-unshelved já existir, o antigo será renomeado.

$ git p4 sync
$ git p4 unshelve 12345
$ git show p4-unshelved/12345
<encaminha mais alterações através do p4 para os mesmos arquivos>
$ git p4 unshelve 12345
<se recusa a fazer o desarquivamento a menos que o git esteja em sincronia com o p4 novamente>

OPÇÕES

Opções gerais

Todos os comandos, exceto o clone, aceitam estas opções.

--git-dir <dir>

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

-v
--verbose

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

Opções de sincronização

Estas opções podem ser utilizadas no clone inicial, bem como nas operações subsequentes de sincronização.

--branch <ref>

Importe as alterações para o <ref> em vez do refs/remotes/p4/master. Caso <ref> começar com refs/, será utilizado como está. Caso contrário, se não iniciar com p4/, esse prefixo será adicionado.

É predefinido que um <ref> que não comece com refs/ seja tratado como o nome de um ramo monitorado remotamente (em refs/remotes/). Esse comportamento pode ser alterado utilizando a opção --import-local.

A predefinição do <ref> é "master".

Este exemplo importa um novo "p4/proj2" remoto para um repositório Git já existente:

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

Utilize o algoritmo de detecção do ramo para encontrar os novos caminhos no p4. Está documentado abaixo em "DETECÇÃO DO RAMO".

--changesfile <arquivo>

Importe exatamente os números da alteração p4 listados no arquivo, um por linha. Normalmente, o git p4 inspeciona a condição atual do repositório p4 e detecta quais as alterações que ele deve importar.

--silent

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

--detect-labels

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.

--import-labels

Importe os rótulos do p4 para o Git.

--import-local

É predefinido que os ramos p4 sejam armazenadas em refs/remotes/p4/, onde serão tratadas como ramificações monitoradas remotamente pelo git-branch[1] e outros comandos. Esta opção coloca as ramificações p4 no refs/heads/p4/. Observe que as futuras operações de sincronização tam bém devem especificar a opção --import-local para que eles possam encontrar as ramificações p4 em refs/heads.

--max-changes <n>

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.

--changes-block-size <n>

O tamanho do bloco interno que será utilizado ao converter um especificador da revisão como @all em uma 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.

--keep-path

É predefinido para o Git, que seja removido todo o caminho do depósito no mapeamento do caminho dos nomes dos arquivos do depósito p4. 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/, se torne foo/bar.c. Com --keep-path, o caminho do Git fica depot/main/foo/bar.c.

--use-client-spec

Use uma especificação do cliente para encontrar a lista dos arquivos interessantes no p4. Consulte a seção "CLIENT SPEC" abaixo.

-/ <caminho>

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

Opções de clonagem

Estas opções podem ser utilizadas em um clone inicial, juntamente com as opções de sincronização descritas acima.

--destination <diretório>

Onde criar o repositório Git. Caso não seja utilizado, o último componente no depósito p4 é utilizado para criar um novo diretório.

--bare

Faça uma clonagem simples. Consulte git-clone[1].

Opções de envio

Estas opções podem ser utilizadas para modificar o comportamento do git p4 submit.

--origin <commit>

Localização 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.

-M

Detecte as renomeações. Consulte git-diff[1]. As renomeações serão representadas em p4 utilizando operações move de forma explicita. Não há opção correspondente para detectar cópias, no entanto há variáveis tanto para mover como copiar.

--preserve-user

Re-escreva as alterações no p4 antes de enviá-lo ao p4 Esta opção requer privilégios de administração p4.

--export-labels

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

-n
--dry-run

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

--prepare-p4-only

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

--shelve

Em vez de enviar, crie uma série de listas de alterações que foram arquivadas. Depois de criar cada prateleira, os arquivos relevantes são revertidos/excluídos. Caso tenha vários commits pendentes, várias prateleiras serão criadas.

--update-shelve CHANGELIST

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.

--conflict=(ask|skip|quit)

Podem ocorrer conflitos durante a aplicação de um commit ao p4. Quando isso acontece, o comportamento predefinido ("ask") é perguntar se você deve ignorar este commit e continuar ou encerrar. Esta opção pode ser utilizada para ignorar o prompt, fazendo com que os commits conflitantes sejam ignorados automaticamente ou pare de tentar aplicar os commits sem nenhum alerta.

--branch <ramo>

Após o envio, sincronize esta ramificação informada em vez da predefinição p4/master. Consulte a seção "Opções de sincronização" acima para obter mais informações.

--commit <sha1>|<sha1..sha1>

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.

--disable-rebase

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.

--disable-p4sync

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.

Ganchos para envio

p4-pre-submit

O gancho p4-pre-submit é executado caso exista e seja executável. O gancho não aceita os parâmetros e nada da entrada padrão. Encerrando com uma condição diferente de zero deste script impede a execução do git-p4 submit. Pode ser contornada com a opção da linha de comando --no-verify.

Um cenário para a sua utilização é executar os testes da unidade no gancho.

p4-prepare-changelist

O gancho p4-prepare-changelist é executado bem depois de preparar a mensagem da lista de alterações predefinida e antes que o editor seja iniciado. É necessário um único parâmetro, o nome do arquivo que contenha o texto da lista das alterações. Encerrando com uma condição diferente de zero, faz com que o processo seja interrompido.

O propósito do gancho é para editar a mensagem do arquivo em questão, e não é sobreposto pela opção --no-verify. Este gancho é chamado mesmo que a opção --prepare-p4-only seja definida.

p4-changelist

O gancho p4-changelist é executado depois que mensagem da lista de alterações tenha sido editada pelo usuário. Pode ser ignorado com a opção --no-check. É necessário um único parâmetro, o nome do arquivo que contenha o texto da lista das alterações propostas. Encerre com uma condição diferente de zero, faz com que o comando seja cancelado.

O gancho tem permissão para editar o arquivo da lista de alterações e pode ser utilizado para normalizar o texto em algum formato predefinido pelo projeto. Também pode ser utilizado para recusar o envio após a inspeção da mensagem do arquivo.

p4-post-changelist

O gancho p4-post-changelist é executado depois que o envio tenha ocorrido com êxito no P4. Não precisa de quaisquer parâmetros e serve primeiramente para notificações e pode não afetar o resultado da ação do comando git p4 submit.

Opções para a reconstrução da fundação

Essas opções podem ser utilizadas para modificar o comportamento do git p4 rebase.

--import-labels

Importe as etiquetas p4.

Desfazer as opções

--origin

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

SINTAXE DO CAMINHO DO DEPÓSITO

O argumento do caminho do depósito p4 para o comando git p4 sync e o git p4 clone pode ser um ou mais caminhos para o depósito p4 separados com espaço, com um especificador opcional da revisão p4 no final:

"//depot/my/project"

Importe um commit com todos os arquivos na alteração #head sob essa árvore.

"//depot/my/project@all"

Importe um commit para cada alteração no histórico desse caminho do depósito.

"//depot/my/project@1,6"

Importe apenas as alterações entre 1 a 6.

"//depot/proj1@all //depot/proj2@all"

Importe todas as alterações dos dois caminhos do depósito informados para um único repositório. Somente os arquivos abaixo destes diretórios estão incluídos. Não há um subdiretório no Git para cada "proj1" e "proj2". Você deve utilizar a opção --destination ao informar mais de um caminho do depósito. O especificador de revisão deve ser definido de forma idêntica em cada caminho do depósito. Caso haja os arquivos com o mesmo nome nos caminhos do depósito, o caminho com a versão atualizada mais recente do arquivo é o que irá aparecer no Git.

Consulte revisões de ajuda p4 para obter a sintaxe completa dos especificadores da revisão p4.

ESPECIFICAÇÃO DO CLIENTE

A definição do cliente p4 é mantida com o comando p4 client e contém, entre os outros campos, uma visualização que define como o depósito é mapeado no repositório do cliente. Os comandos clone e sync podem consultar a especificação do cliente quando receber a opção --use-client-spec ou quando a variável useClientSpec for verdadeira. Após o git p4 clone, a variável useClientSpec é automaticamente definida no arquivo de configuração do repositório. Isso permite que futuros comandos git p4 submit funcionem corretamente; o comando submit examina apenas a variável e não possui uma opção na linha de comando.

A sintaxe completa de uma visualização p4 está documentada em p4 help views. O comando git p4 conhece apenas um subconjunto da sintaxe de visualização. Ele compreende os mapeamentos das várias linhas, sobreposições com +, exclusões com - e as aspas duplas ao redor do espaço. Dos possíveis curingas, o git p4 manipula apenas …​ e somente quando está no final do caminho. O git p4 irá reclamará caso encontre um curinga sem tratamento.

Existem bugs na implementação dos mapeamentos da sobreposição. Caso vários caminhos do depósito mapearem as sobreposições para o mesmo local no repositório, git p4 poderá escolher o caminho errado. Isso é difícil de resolver sem dedicar um cliente específico apenas ao git p4.

O nome do cliente pode ser atribuído ao git p4 de várias maneiras. A variável git-p4.client tem precedência, caso exista. Caso contrário, são utilizados os mecanismos p4 tradicionais para determinar o cliente utilizado: a variável de ambiente P4CLIENT, um arquivo referenciado por P4CONFIG ou o nome do host local.

DETECÇÃO DO RAMO

O P4 não tem o mesmo conceito de ramificação que o Git. Em vez disso, o p4 organiza o seu conteúdo como uma árvore de diretórios, onde por convenção de diferentes ramificações lógicas que ficam nos diferentes locais da árvore. O comando p4 branch é usado para manter os mapeamentos entre as diferentes áreas da árvore e indicar o conteúdo relacionado. O git p4 pode utilizar esses mapeamentos para determinar os relacionamentos dos ramos.

Caso você possua um repositório onde todas as ramificações de interesse existam como subdiretórios de um único caminho do depósito, é possível utilizar o comando --detect-branches durante a clonagem ou sincronização para que o comando git p4 encontre automaticamente os subdiretórios p4 e gere-os como os ramos no Git.

Por exemplo, se a estrutura do repositório P4 for:

//depot/main/...
//depot/branch1/...

E "p4 branch -o branch1" mostra uma linha View que se parece com:

//depot/main/... //depot/branch1/...

Então este comando git p4 clone:

git p4 clone --detect-branches //depot@all

produz uma ramificação separada em refs/remotes/p4/ para //depot/main, chamado master, e uma para //depot/branch1 chamada depot/branch1.

No entanto, não é necessário criar as ramificações p4 para poder utilizá-las como ramificações. Como é difícil inferir nos relacionamentos da ramificação de forma automática, uma configuração Git git-p4.branchList pode ser usada para identificar de forma explicita os relacionamentos da ramificação. É uma lista de pares "source:destination", como uma especificação p4 simples do ramo onde "origem" e "destino" são os elementos do caminho no repositório p4. O exemplo acima se baseou na presença do ramo p4. Sem os ramos p4, o mesmo resultado ocorrerá com:

git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .

DESEMPENHO

O mecanismo de importação rápida usado pelo git p4 cria um arquivo de pacote para cada chamada do git p4 sync. Normalmente, a compactação de lixo do Git (git-gc[1]) as compacta de forma automática com menos arquivos no pacote, porém a chamada explícita do comando git repack -adf pode ajudar a melhorar o desempenho.

VARIÁVEIS DE CONFIGURAÇÃO

As seguintes configurações podem ser usadas para alterar o comportamento do git p4. Todos eles estão na seção git-p4.

Variáveis gerais

git-p4.user

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

git-p4.password

Uma senha definida como uma opção para todos os comandos p4, com -P <senha>. A variável de ambiente P4PASS pode ser utilizada.

git-p4.port

Uma porta definida como uma opção para todos os comandos p4, com -p <porta>. A variável de ambiente P4PORT pode ser utilizada.

git-p4.host

O host definido como uma opção para todos os comandos p4, com -h <host>. A variável de ambiente P4HOST pode ser utilizada.

git-p4.client

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

git-p4.retries

Define a quantidade de vezes para tentar novamente um comando p4 (principalmente, p4 sync) caso a rede atinja o tempo limite. O valor predefinido é 3. Define o valor como 0 para desativar as tentativas ou se a sua versão p4 não for compatível com tentativas (anteriores a versão 2012.2).

Variáveis de clonagem e sincronização

git-p4.syncFromOrigin

Como a importação dos commits dos outros repositórios Git é muito mais rápido do que a importação através do p4, existe um mecanismo para encontrar as alterações p4 primeiro nos ramos remotos do Git. Caso existam ramos em refs/remote/origin/p4, elas serão buscadas e utilizada durante a sincronização a partir do p4. Para desativar esse comportamento, esta variável pode ser definida como false.

git-p4.branchUser

Uma fase na detecção do ramo envolve olhar para os ramos p4 para encontrar os novos que serão importados. É predefinido que todas as ramificações sejam inspecionadas. Essa opção limita a pesquisa apenas àqueles pertencentes ao único usuário informado na variável.

git-p4.branchList

A lista dos ramos que serão importados quando a detecção da ramificação estiver ativo. Cada entrada deve ser um par dos nomes das ramificações separados por dois pontos (:). Este exemplo declara que branchA e branchB foram criados a partir de main:

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

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

git-p4.importLabels

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

git-p4.labelImportRegexp

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

git-p4.useClientSpec

Define que a especificação do cliente p4 deve ser utilizada para identificar os caminhos de interesse do depósito p4. Isto é o mesmo que utilizar a opção --use-client-spec. Consulte a seção "ESPECIFICAÇÃO DO CLIENTE" acima. Essa variável é um booleano e não o nome de um cliente p4.

git-p4.pathEncoding

O Perforce mantém a codificação de um caminho conforme seja informado pelo sistema operacional da origem. O Git espera que os caminhos sejam codificados como UTF-8. Utilize esta configuração para informar ao git-p4 qual a codificação que o Perforce utilizou para os caminhos. Essa codificação é utilizada para transcodificar os caminhos para UTF-8. Como exemplo, o "Perforce" no Windows geralmente utilizam "cp1252" para codificar os nomes dos caminhos.

git-p4.largeFileSystem

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

git config       git-p4.largeFileSystem GitLFS
git-p4.largeFileExtensions

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 ..

git-p4.largeFileThreshold

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.

git-p4.largeFileCompressedThreshold

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.

git-p4.largeFilePush

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

git-p4.keepEmptyCommits

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.

git-p4.mapUser

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>"

Um mapeamento substituirá quaisquer informações do usuário do P4. Os mapeamentos para os vários usuários P4 podem ser definidos.

Envie as variáveis

git-p4.detectRenames

Detecte as renomeações. Consulte git-diff[1]. Pode ser true, false ou uma pontuação conforme é o esperado pelo comando git diff -M.

git-p4.detectCopies

Detecta cópias. Consulte git-diff[1]. Pode ser true, false ou uma pontuação conforme é o esperado pelo comando git diff -C.

git-p4.detectCopiesHarder

Detecte cópias com mais vigor. Consulte git-diff[1]. A boolean.

git-p4.preserveUser

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

git-p4.allowMissingP4Users

Quando preserveUser for verdadeiro, o comando git p4 normalmente é encerrado caso não consiga encontrar um autor no mapa do usuário p4. Esta configuração envia as alterações independentemente de qualquer coisa.

git-p4.skipSubmitEdit

O processo de envio chama o editor antes de cada alteração no p4 que será enviado. Caso esta configuração seja verdadeira, a etapa de edição será ignorada.

git-p4.skipSubmitEditCheck

Após editar a mensagem de alteração p4, o comando git p4 garante que a descrição realmente foi alterada observando a hora da modificação do arquivo. Esta opção desativa este teste.

git-p4.allowSubmit

É predefinido que qualquer ramo possa ser utilizado como uma fonte para uma operação git p4 submit. Esta variável de configuração, se definida, permite que apenas os ramos informado sejam utilizados como as fontes para envio. Os nomes das ramificações devem ser os nomes abreviados (sem "refs/heads/") e devem ser separados por vírgulas (",") e sem espaços.

git-p4.skipUserNameCheck

Caso o usuário executando o comando git p4 submit não existir no mapa do usuário p4, o git p4 será encerrado. Esta opção pode ser utilizada para impor o envio mesmo assim.

git-p4.attemptRCSCleanup

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.

git-p4.exportLabels

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

git-p4.labelExportRegexp

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

git-p4.conflict

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

git-p4.disableRebase

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

git-p4.disableP4Sync

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

DETALHES DA IMPLEMENTAÇÃO

  • Os conjuntos de alterações p4 são importados utilizando a importação rápida do Git.

  • A clonagem ou a sincronização não requer um cliente p4; o conteúdo do arquivo é coletado utilizando p4 print.

  • O envio requer um cliente p4, que não esteja no mesmo local que o repositório Git. Os patches são aplicados, um de cada vez neste cliente p4 e enviados a partir daí.

  • Cada commit importado pelo git p4 possui uma linha no final da mensagem do registro log indicando a localização do depósito p4 e o número da alteração. Esta linha é utilizada pelas operações posteriores do git p4 sync para saber quais foram alterações do p4 são novas.

scroll-to-top