merlin2011's questions

Já vi essa pergunta e agora sei como passar variáveis ​​de shell corretamente para o awk.

Entretanto, notei um comportamento curioso em minhas tentativas incorretas iniciais:

ip=10.170.115.13

echo $ip
10.170.115.13

echo foo | awk "{print ${ip} }"
10.170.1150.13

Observe o 0 extra na saída acima.

Esse é um comportamento indefinido ou há uma razão lógica para o 0 aparecer onde aparece?

Aqui está minha versão awk:

awk --version
awk version 20200816

Isso também acontece com gawk:

gawk --version
GNU Awk 5.3.1, API 4.0, (GNU MPFR 4.2.1, GNU MP 6.3.0)
Copyright (C) 1989, 1991-2024 Free Software Foundation.

Suponha que eu use git read-tree <sha>without -um(porque não quero uma mesclagem, mas sim uma leitura simples).

Agora quero fazer o equivalente ao último passo git reset --hard(tornar a árvore de trabalho igual ao índice) sem alterar nenhuma referência.

Existe algum mecanismo gitpara fazer isso?

De forma equivalente, existe uma maneira de fazer semanticamente git read-tree -usem qualquer tipo de mesclagem, em vez de simplesmente substituir o índice e a árvore de trabalho pelo conteúdo da árvore fornecida?

Eu tentei git checkout-index -a -f, mas ele não remove arquivos no diretório de trabalho, apenas os adiciona.

Gostaria de executar um conjunto de operações que exigem salvar e depois restaurar o HEAD.

Aqui está uma representação lógica do que eu gostaria de fazer:

# Save HEAD
original_head="$(cat .git/HEAD)"

# Perform other operations that muck with HEAD
# ...

# Restore HEAD
echo -n "$original_head" > .git/HEAD

O uso de cate echoacima são meramente ilustrativos; eles não são nativos do git nem particularmente confiáveis, porque falharão em árvores de trabalho recém-criadas, onde .githá um arquivo e não um diretório.

Uma abordagem um pouco melhor é usar symbolic-ref:

# Save
original_head="$(git symbolic-ref HEAD)"

# Restore
git symbolic-ref HEAD "$original_head"

Essa abordagem é um pouco melhor, mas falha se HEAD foi originalmente destacado:

# Detach HEAD
git checkout $(git rev-parse HEAD)
 
# Try to get HEAD value to save:
git symbolic-ref HEAD
fatal: ref HEAD is not a symbolic ref

Aqui está o que estou fazendo atualmente para contornar isso:

# Save HEAD
symbolic_head=''
detached_head=''
if git symbolic-ref HEAD >/dev/null 2>&1; then
  symbolic_head="$(git symbolic-ref HEAD)"
else
  detached_head="$(git rev-parse HEAD)"
fi

# Perform other operations that muck with HEAD
# ...


# Restore HEAD
if [[ -n $symbolic_head ]]; then
  git symbolic-ref HEAD "$symbolic_head"
else
  git update-ref HEAD "$detached_head"
fi

Existe uma maneira mais direta de dizer "obter o valor de HEAD, independentemente de ser uma referência simbólica ou normal" e então "definir o valor de HEAD, independentemente de ser uma referência simbólica ou normal"?

A documentação dos git-commit-treeestados diz o seguinte:

A commit encapsulates:
     all parent object ids
     author name, email and date
     committer name and email and the commit time.

Entretanto, a presença do -Ssinalizador e os commits observados na natureza incluem um gpgsigcabeçalho, que não é mencionado na lista acima.

Além disso, a documentação indica que os commits também podem incluir um encodingcabeçalho, embora eu ainda não tenha visto nenhum por aí.

Objetos de commit criados com a configuração acima registram o valor de i18n.commitEncoding em seu cabeçalho de codificação. Isso é para ajudar outras pessoas que os vejam mais tarde. A falta desse cabeçalho implica que a mensagem de log de commit é codificada em UTF-8.

A documentação do Pretty Formats lista informações que podem ser extraídas de um commit, mas não faz nenhuma afirmação sobre se essas informações são exaustivas.

A lista completa de cabeçalhos possíveis e valores válidos está documentada em algum lugar?

Ou não é seguro escrever código que faça suposições sobre o conjunto de cabeçalhos possíveis?

Esta é uma generalização da minha pergunta anterior , com o objetivo de melhorar meu entendimento sobre o que pode e o que não pode ser feito internamente no Git.

Suponha que eu tenha um commit A, e eu queira alterar alguns metadados arbitrários, sejam os pais, a árvore, o autor/committer, o autor/data do commit, a mensagem do commit ou a assinatura gpg, para produzir um novo commit B que compartilhe todos os metadados com A, exceto os bits que eu alterei. Além disso, suponha que minhas alterações não exijam a criação de uma nova árvore; estou usando a árvore original ou substituindo outra árvore existente.

Atualmente, estou ciente de pelo menos duas maneiras de fazer isso:

• Posso git checkout Ae então usar git commit --amendcom várias opções. Isso é nativo do git e moderadamente flexível em termos do que pode ser alterado. No entanto, é interativo e toca a árvore de trabalho.
• Posso usar git cat-file | <insert_sed_script> | git hash-object -w -t commit --stdincomo descreve esta resposta à minha pergunta anterior.

A segunda maneira é semanticamente o que estou procurando, mas requer um script externo que execute manipulação de texto na representação de texto de um commit.

A manipulação de texto é a única opção atual para transformar objetos de confirmação de forma não interativa ou existe uma maneira mais estruturada e semântica de manipular os metadados de confirmação?

• Exemplo 1: Em vez de escrever um script sed que semanticamente diz "exclua as linhas que começam com parente então insira novas linhas que começam com pai", posso escrever um comando git que diz "defina os pais deste commit como X, Y, Z" e gerar o commit com essa alteração? (o git replace pode lidar com esse caso, mas não com o caso geral.)
• Exemplo 2: Em vez de escrever um script sed que identifica a mensagem de confirmação com base em expressões regulares e a substitui, posso escrever um comando git que diz "defina a mensagem de confirmação desta confirmação como 'hello world'" e gerar a confirmação com essa alteração?

Parte da motivação para perguntar isso é curiosidade intelectual; a outra parte é que estou pensando em criar essas ferramentas externamente (envolvendo a manipulação de texto), caso elas ainda não existam.

Considere a seguinte sequência de comandos:

git replace --graft <sha> <new_parent_sha>
new_commit_sha="$(git show-ref refs/replace/<sha> | awk '{print $1}')"
git update-ref -d refs/replace/<sha>

O resultado final é que temos um commit (new_commit_sha) com novos pais, que é idêntico ao commit original (mesma árvore, mesma mensagem, mesmo autor e responsável pelo commit, data do autor, data do commit), exceto que os pais são diferentes.

Existe uma maneira mais direta de obter o mesmo efeito de duplicar um commit com pais substituídos sem primeiro criar uma replacereferência e depois excluí-la?

Eu olhei git-commit-tree, mas não vi uma opção para pegar a maioria das propriedades de commit de um commit de origem.

Eu também brinquei com git cherry-pickmas isso tenta aplicar um patch que pode entrar em conflito e resultar em uma árvore diferente se o pai for diferente. Estou tentando produzir um commit com exatamente a mesma árvore (e outras propriedades).

Suponha que eu execute o seguinte comando em um repositório git:

git rev-list --objects HEAD^..HEAD

Este comando me fornece apenas objetos que são referenciados por HEAD e não referenciados por HEAD^.

Entretanto, se houver um objeto referenciado por HEAD^^e também por HEAD, mas não por HEAD^, esse objeto aparecerá na saída?

Com base na experimentação, parece que a resposta é sim.

Entretanto, a documentação não parece especificar a intenção, então não tenho certeza se meus resultados experimentais são acidentais ou não.

Atualização sobre meu entendimento atual para esclarecer a questão:

• Entendo que isso <old>..<new>é equivalente a ^<old> <new>, o que significa pegar todos os commits que podem ser acessados ​​de <new>, mas não podem ser acessados ​​de <old>.
• (Implementação A1) Filosoficamente, se expandíssemos essa noção literalmente para "árvores e blobs referenciados por commits", então o comportamento "semanticamente correto" git rev-list --objects ^<old> <new>seria "encontrar todos os objetos (commits, árvores e blobs) que são acessíveis a partir <new>dos quais não são acessíveis a partir de <old>.
• Levando isso ao pé da letra, isso implicaria que um blob X com as seguintes propriedades NÃO deveria aparecer em git rev-list --objects HEAD^..HEAD, porque o conjunto completo de objetos acessíveis a partir de HEAD^inclui o blob X.
  • referenciado pela árvore de propriedade deHEAD^^
  • referenciado pela árvore de propriedade deHEAD
  • não referenciado diretamente pela árvore de propriedade deHEAD^
• Entretanto, meus experimentos indicam que o blob X aparece na saída de git rev-list --objects HEAD^..HEAD, o que implica na seguinte implementação alternativa (chame-o de A2) :
  • Pegue todos os objetos referenciados pelos commits no intervalo <old>..<new>.
  • Remova SOMENTE os objetos referenciados pelo commit <old>e NÃO todos os seus ancestrais e retorne este conjunto.

Portanto, minha pergunta pode ser reformulada como: O comportamento de é git rev-list --objects <old>..<new>equivalente a A1, A2 ou algo completamente diferente que às vezes se comporta como A1 e às vezes como A2?

Em um grande repositório, executei recentemente os seguintes comandos:

git rev-list --objects <my_rev_list> RevListOut.txt

echo -e "<my_rev_list>" | git pack-objects --revs /tmp/XXX
git verify-pack -v /tmp/XXX-b569475c51d937df848abbcfe16433e2f8ebc0f5.pack > Unpack.txt

Quando comparei os objetos em RevListOut.txte Unpack.txtdescobri que há exatamente dois objetos em Unpack.txtque não existem em RevListOut.txt, e eles têm os seguintes shas:

380a0876f57a4708b4a73a29d2ace2d4506880a2
2000687bd2701ff5c7c37013178d15384f0deefa

Fiz mais algumas investigações e descobri que ambos os objetos correspondem a arquivos rastreados pelo git.

Por que posso git rev-list --objectsperder um objeto?

Quero usar um arquivo de índice alternativo para criar uma estrutura de sistema de arquivos completamente independente com um histórico independente no mesmo repositório Git, no estilo git notes.

Para facilitar isso, gostaria de poder pegar um diretório arbitrário e git addcolocá-lo em um arquivo de índice (alternativo) e confirmá-lo como se fosse a raiz da árvore de trabalho.

Por exemplo, suponha que minha estrutura de diretório seja a seguinte:

.
└── subdir
    └── hello.txt

1 directory, 1 file

Se eu executasse git add subdirnormalmente, meu índice ficaria assim:

git ls-files -s
100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0   subdir/hello.txt

Em vez disso, quero que meu índice fique assim:

git ls-files -s
100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0   hello.txt

Existe algum mecanismo no git para adicionar um diretório especificado pelo usuário ao arquivo de índice como se fosse o diretório raiz , ou minha única opção é usar comandos de encanamento, como update-indexadicionar manualmente cada arquivo ao índice no caminho apropriado (relativo)?

Em um grande monorepo (diretório .git de 10 GB), observei o seguinte comportamento.

# When outputing to a file, it is very fast:
time git  log   -2  > /tmp/X

real    0m0.076s
user    0m0.007s
sys     0m0.046s

# When outputting to the tty, it is more than 10x slower:
time git  log   -2
# ... Output omitted

real    0m0.830s
user    0m0.078s
sys     0m0.586s

Aqui estão todas as minhas configurações relacionadas ao log:

$ git config -l | grep log

log.mailmap=true
core.logallrefupdates=true

O que causa a diferença no desempenho e como posso obter o mesmo desempenho quando o git log está gerando saída para um tty?

Mais observações:

• Em um repositório menor, git log -2é rápido mesmo ao enviar para tty, então o problema parece estar correlacionado com um repositório grande.

  real    0m0.057s
  user    0m0.008s
  sys     0m0.022s
  

• O Cat no arquivo de saída é rápido, então não é apenas a escrita no stdout que é lenta.

  time cat /tmp/X
  real    0m0.015s
  user    0m0.001s
  sys     0m0.005s
  

• Forçar um tty com expect's unbuffertambém torna mais lento git log:

  time unbuffer git  log   -2 > /tmp/X
  
  real    0m1.007s
  user    0m0.104s
  sys     0m0.669s
  

• Em comparação, unbufferele próprio tem uma sobrecarga de ~240 ms:

  time unbuffer cat /tmp/X
  
  real    0m0.239s
  user    0m0.033s
  sys     0m0.111s
  

No momento, estou tentando fazer uma compilação personalizada envoyem uma máquina que não tem acesso ao PyPi. A equipe de segurança da minha empresa exige que usemos um proxy corporativo com uma URL diferente para acessar os repositórios do PyPi.

Quando tento executar bazel build ..., recebo o seguinte erro:

ERROR: An error occurred during the fetch of repository 'pypi__pip_tools':
   Traceback (most recent call last):
        File "/home/ubuntu/.cache/bazel/_bazel_ubuntu/b4e0fd0e207e6fdf5e33997b6741cf2d/external/bazel_tools/tools/build_defs/repo/http.bzl", line 132, column 45, in _http_archive_impl
                download_info = ctx.download_and_extract(
Error in download_and_extract: java.io.IOException: Error downloading [https://files.pythonhosted.org/packages/0d/dc/38f4ce065e92c66f058ea7a368a9c5de4e702272b479c0992059f7693941/pip_tools-7.4.1-py3-none-any.whl] to /home/ubuntu/.cache/bazel/_bazel_ubuntu/b4e0fd0e207e6fdf5e33997b6741cf2d/external/pypi__pip_tools/temp12252431299166532778/pip_tools-7.4.1-py3-none-any.whl.zip: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

O erro de segurança é uma pista falsa neste caso porque preciso substituir https://files.pythonhosted.orgpor um domínio diferente.

Para a linha de comando pip, tive que fazer o seguinte:

python3 -m pip config set global.index-url  <new_url_here>

Existe alguma maneira equivalente de forçar bazelo uso de um domínio diferente ao buscar ferramentas Python?

Observe que já vi esse problema , mas isso não ajuda porque esse erro está acontecendo como parte do processo de instalação do pip, antes de qualquer pip_installchamada ser feita.

Considere a sequência hello(world).

Eu queria usar uma awkinvocação para extrair arquivos world.

Esta foi minha primeira tentativa e a saída foi uma string vazia, sem erros.

echo 'hello(world)' | awk -F'(|)'  '{print $2}'

Minha segunda tentativa foi usar classes de caracteres, que produziram o comportamento esperado:

echo 'hello(world)' | awk -F'[()]' '{print $2}'

No entanto, dado que a documentação do awk afirma que o separador de campos pode ser uma expressão regular, eu esperava que a primeira tentativa funcionasse.

Aqui está minha versão awk:

$ awk --version
GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.2.0)
Copyright (C) 1989, 1991-2019 Free Software Foundation.

Por que a expressão (|)não alcança o resultado desejado?