Subdiretórios de checkout no Git?

É possível verificar os subdiretórios de um repositório no Git?

Imagine que estou configurando uma nova instalação do WordPress. Vou criar dois novos diretórios para a personalização do meu plugin e tema:

• wordpress/wp-content/plugins/myplugins/
• wordpress/wp-content/themes/mytheme/

Eu quero manter esses diretórios via Git. No Subversion, eu iria fazer isso por ter trunk/myplugins/e trunk/mytheme/diretórios e verificar subdiretórios. O Git tem uma maneira de realizar a mesma tarefa usando um único repositório?

Eu poderia estar perdendo o barco em algum paradigma do Git, como um usuário de SVN de longa data com pouca exposição ao Git.

Editar: Várias ramificações armazenando conteúdo diferente é uma maneira interessante de lidar com isso.

As verificações esparsas estão agora no Git 1.7 .

Consulte também a pergunta “ É possível fazer uma verificação esparsa sem verificar primeiro todo o repositório? ”.

Observe que checkouts esparsos ainda exigem o download de todo o repositório, mesmo que alguns dos arquivos baixados pelo Git não acabem na sua árvore de trabalho.

Não existe uma maneira real de fazer isso no git. E se você não fará alterações que afetem as duas árvores ao mesmo tempo como uma única unidade de trabalho, não há um bom motivo para usar um único repositório para ambas. Eu pensei que sentiria falta desse recurso do Subversion, mas descobri que a criação de repositórios tem tão pouca sobrecarga administrativa administrativa (simplesmente devido ao fato de que os repositórios são armazenados ao lado de sua cópia de trabalho, em vez de exigir que eu escolha explicitamente algum lugar fora do cópia de trabalho) que eu me acostumei a criar muitos repositórios de uso único.

Se você insistir (ou realmente precisar dele), poderá criar um repositório git com apenas mythemee mypluginsdiretórios e vincular os de dentro da instalação do WordPress.

MDCore escreveu:

fazer um comprometimento com, por exemplo, mytheme aumentará o número de revisão para myplugin

Observe que isso não é uma preocupação para o git, se você decidir colocar os dois diretórios em um único repositório, porque o git acaba inteiramente com o conceito de aumentar monotonicamente os números de revisão de qualquer forma.

O único critério para quais coisas reunir em um único repositório no git é se constitui uma única unidade, ie. no seu caso, se há alterações nas quais não faz sentido examinar as edições em cada diretório isoladamente. Se você tiver alterações nas quais precisa editar arquivos nos dois diretórios de uma vez e as edições pertencerem juntas, elas deverão ser um repositório. Caso contrário, não os junte.

O Git realmente deseja que você use repositórios separados para entidades separadas.

submódulos

Os submódulos não atendem ao desejo de manter os dois diretórios em um repositório, porque na verdade imporiam um repositório separado para cada diretório, que é reunido em outro repositório usando submódulos. Pior ainda, como os diretórios dentro da instalação do WordPress não são subdiretórios diretos do mesmo diretório e também fazem parte de uma hierarquia com muitos outros arquivos, usar os repositórios por diretório como submódulos em um repositório unificado não traria nenhum benefício, porque o arquivo unificado repositório não refletiria nenhum caso / necessidade de uso.

Uma coisa que eu não gosto nos checkouts esparsos é que, se você quiser fazer check-out de um subdiretório com poucos diretórios, sua estrutura de diretórios deve conter todos os diretórios que o conduzem.

A maneira de solucionar isso é clonar o repositório em um local que não seja minha área de trabalho e criar um link simbólico no diretório da minha área de trabalho para o subdiretório no repositório. O Git funciona dessa maneira muito bem, porque coisas como o status do git exibirão os arquivos de alteração em relação ao seu diretório de trabalho atual.

Na verdade, os checkouts "restritos" ou "parciais" ou "esparsos" estão em desenvolvimento pesado e atual para o Git. Observe que você ainda terá o repositório completo em .git. Portanto, as outras duas postagens são atuais para o estado atual do Git, mas parece que seremos capazes de fazer checkouts esparsos eventualmente. Confira as listas de discussão se você estiver interessado em mais detalhes - eles estão mudando rapidamente.

git clone --filter do Git 2.19

Essa opção realmente pula a busca de objetos desnecessários do servidor:

git clone --depth 1 --no-checkout --filter=blob:none \
  "file://$(pwd)/server_repo" local_repo
cd local_repo
git checkout master -- mdir/

O servidor deve ser configurado com:

git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1

Não há suporte para servidor a partir da v2.19.0, mas ele já pode ser testado localmente.

file://$(path)é necessário para superar as git clonetravessuras do protocolo: Como clonar superficialmente um repositório git local com um caminho relativo?

Lembre-se que isso --depth 1já implica --single-branch, veja também: Como clonar uma única ramificação no Git?

TODO: --filter=blob:noneignora todos os blobs, mas ainda busca todos os objetos da árvore. Mas em um repositório normal, isso deve ser pequeno comparado aos arquivos em si, portanto, isso já é bom o suficiente. Perguntado em: https://www.spinics.net/lists/git/msg342006.html Os Devs responderam que um --filter=tree:0está sendo trabalhado para fazer isso.

O formato de --filterestá documentado em man git-rev-list.

Foi feita uma extensão ao protocolo remoto Git para suportar esse recurso.

Documentos na árvore Git:

• https://github.com/git/git/blob/v2.19.0/Documentation/technical/partial-clone.txt
• https://github.com/git/git/blob/v2.19.0/Documentation/rev-list-options.txt#L720
• https://github.com/git/git/blob/v2.19.0/t/t5616-partial-clone.sh

Teste

#!/usr/bin/env bash
set -eu

list-objects() (
  git rev-list --all --objects
  echo "master commit SHA: $(git log -1 --format="%H")"
  echo "mybranch commit SHA: $(git log -1 --format="%H")"
  git ls-tree master
  git ls-tree mybranch | grep mybranch
  git ls-tree master~ | grep root
)

# Reproducibility.
export GIT_COMMITTER_NAME='a'
export GIT_COMMITTER_EMAIL='a'
export GIT_AUTHOR_NAME='a'
export GIT_AUTHOR_EMAIL='a'
export GIT_COMMITTER_DATE='2000-01-01T00:00:00+0000'
export GIT_AUTHOR_DATE='2000-01-01T00:00:00+0000'

rm -rf server_repo local_repo
mkdir server_repo
cd server_repo

# Create repo.
git init --quiet
git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1

# First commit.
# Directories present in all branches.
mkdir d1 d2
printf 'd1/a' > ./d1/a
printf 'd1/b' > ./d1/b
printf 'd2/a' > ./d2/a
printf 'd2/b' > ./d2/b
# Present only in root.
mkdir 'root'
printf 'root' > ./root/root
git add .
git commit -m 'root' --quiet

# Second commit only on master.
git rm --quiet -r ./root
mkdir 'master'
printf 'master' > ./master/master
git add .
git commit -m 'master commit' --quiet

# Second commit only on mybranch.
git checkout -b mybranch --quiet master~
git rm --quiet -r ./root
mkdir 'mybranch'
printf 'mybranch' > ./mybranch/mybranch
git add .
git commit -m 'mybranch commit' --quiet

echo "# List and identify all objects"
list-objects
echo

# Restore master.
git checkout --quiet master
cd ..

# Clone. Don't checkout for now, only .git/ dir.
git clone --depth 1 --quiet --no-checkout --filter=blob:none "file://$(pwd)/server_repo" local_repo
cd local_repo

# List missing objects from master.
echo "# Missing objects after --no-checkout"
git rev-list --all --quiet --objects --missing=print
echo

echo "# Git checkout fails without internet"
mv ../server_repo ../server_repo.off
! git checkout master
echo

echo "# Git checkout fetches the missing directory from internet"
mv ../server_repo.off ../server_repo
git checkout master -- d1/
echo

echo "# Missing objects after checking out d1"
git rev-list --all --quiet --objects --missing=print

GitHub upstream .

Saída no Git v2.19:

# List and identify all objects
c6fcdfaf2b1462f809aecdad83a186eeec00f9c1
fc5e97944480982cfc180a6d6634699921ee63ec
7251a83be9a03161acde7b71a8fda9be19f47128
62d67bce3c672fe2b9065f372726a11e57bade7e
b64bf435a3e54c5208a1b70b7bcb0fc627463a75 d1
308150e8fddde043f3dbbb8573abb6af1df96e63 d1/a
f70a17f51b7b30fec48a32e4f19ac15e261fd1a4 d1/b
84de03c312dc741d0f2a66df7b2f168d823e122a d2
0975df9b39e23c15f63db194df7f45c76528bccb d2/a
41484c13520fcbb6e7243a26fdb1fc9405c08520 d2/b
7d5230379e4652f1b1da7ed1e78e0b8253e03ba3 master
8b25206ff90e9432f6f1a8600f87a7bd695a24af master/master
ef29f15c9a7c5417944cc09711b6a9ee51b01d89
19f7a4ca4a038aff89d803f017f76d2b66063043 mybranch
1b671b190e293aa091239b8b5e8c149411d00523 mybranch/mybranch
c3760bb1a0ece87cdbaf9a563c77a45e30a4e30e
a0234da53ec608b54813b4271fbf00ba5318b99f root
93ca1422a8da0a9effc465eccbcb17e23015542d root/root
master commit SHA: fc5e97944480982cfc180a6d6634699921ee63ec
mybranch commit SHA: fc5e97944480982cfc180a6d6634699921ee63ec
040000 tree b64bf435a3e54c5208a1b70b7bcb0fc627463a75    d1
040000 tree 84de03c312dc741d0f2a66df7b2f168d823e122a    d2
040000 tree 7d5230379e4652f1b1da7ed1e78e0b8253e03ba3    master
040000 tree 19f7a4ca4a038aff89d803f017f76d2b66063043    mybranch
040000 tree a0234da53ec608b54813b4271fbf00ba5318b99f    root

# Missing objects after --no-checkout
?f70a17f51b7b30fec48a32e4f19ac15e261fd1a4
?8b25206ff90e9432f6f1a8600f87a7bd695a24af
?41484c13520fcbb6e7243a26fdb1fc9405c08520
?0975df9b39e23c15f63db194df7f45c76528bccb
?308150e8fddde043f3dbbb8573abb6af1df96e63

# Git checkout fails without internet
fatal: '/home/ciro/bak/git/test-git-web-interface/other-test-repos/partial-clone.tmp/server_repo' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

# Git checkout fetches the missing directory from internet
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.

# Missing objects after checking out d1
?8b25206ff90e9432f6f1a8600f87a7bd695a24af
?41484c13520fcbb6e7243a26fdb1fc9405c08520
?0975df9b39e23c15f63db194df7f45c76528bccb

Conclusões: todos os blobs de fora d1/estão ausentes.

Note-se que root/roote mybranch/mybranchtambém estão desaparecidos, mas --depth 1esconde que a partir da lista de arquivos ausentes. Se você remover --depth 1, eles serão exibidos na lista de arquivos ausentes.

Conforme sua edição indica, você pode usar duas ramificações separadas para armazenar os dois diretórios separados. Isso os mantém no mesmo repositório, mas você ainda não pode ter confirmações abrangendo as duas árvores de diretório. Se houver uma alteração em uma que exija uma alteração na outra, você precisará fazer isso como duas confirmações separadas e abrirá a possibilidade de que um par de caixas dos dois diretórios fique fora de sincronia.

Se você deseja tratar o par de diretórios como uma unidade, pode usar 'wordpress / wp-content' como raiz do seu repositório e usar o arquivo .gitignore no nível superior para ignorar tudo, exceto os dois subdiretórios de interesse. Esta é provavelmente a solução mais razoável neste momento.

Supostamente, há poucos anos, os checkouts esparsos estão chegando, mas ainda não há sinal deles no repositório de desenvolvimento do git, nem qualquer indicação de que as mudanças necessárias chegarão lá. Eu não contaria com eles.

Você não pode fazer check-out de um único diretório de um repositório porque o repositório inteiro é tratado pela única pasta .git na raiz do projeto, em vez da miríade de diretórios .svn do subversion.

O problema com o trabalho em plug-ins em um único repositório é que fazer um commit em, por exemplo, mytheme aumentará o número de revisão do myplugin , portanto, mesmo no subversion, é melhor usar repositórios separados.

O paradigma de subversão para subprojetos é svn: externals, que se traduz um pouco em submódulos no git (mas não exatamente no caso de você ter usado svn: externals antes.)

Há uma inspiração aqui. Basta utilizar shell regexou git regex.

git checkout commit_id */*.bat  # *.bat in 1-depth subdir exclude current dir, shell regex  
git checkout commit_id '*.bat'  # *.bat in all subdir include current dir, git regex

Use cotação para escapar da interpretação do regex do shell e passar caracteres curinga para o git.

O primeiro não é recursivo, apenas arquivos em uma profundidade subdir. Mas o segundo é recursivo.

Quanto à sua situação, o seguinte pode ser suficiente.

git checkout master */*/wp-content/*/*
git checkout master '*/wp-content/*'

Basta cortar as linhas conforme necessário.

Você pode reverter as alterações não confirmadas apenas para um arquivo ou diretório específico:

git checkout [some_dir|file.txt]