Como git reset --hard um subdiretório?

ATUALIZAÇÃO² : Com o Git 2.23 (agosto de 2019), há um novo comando git restoreque faz isso, veja a resposta aceita .

ATUALIZAÇÃO : Isso funcionará de forma mais intuitiva a partir do Git 1.8.3, veja minha própria resposta .

Imagine o seguinte caso de uso: Quero me livrar de todas as alterações em um subdiretório específico da minha árvore de trabalho Git, deixando todos os outros subdiretórios intactos.

• Eu posso fazer git checkout ., mas git checkout. adiciona diretórios excluídos pelo checkout esparso

• Existe git reset --hard, mas não me permite fazer isso para um subdiretório:

  > git reset --hard .
  fatal: Cannot do hard reset with paths.
  

  Novamente: Por que o git não pode fazer redefinições de hardware / software por caminho?

• Posso fazer o patch reverso do estado atual usando git diff subdir | patch -p1 -R, mas essa é uma maneira bastante estranha de fazer isso.

Qual é o comando Git apropriado para esta operação?

O script abaixo ilustra o problema. Insira o comando apropriado abaixo do How to make filescomentário - o comando atual restaurará o arquivo a/c/acque deveria ser excluído pelo checkout esparso. Observe que eu não quero restaurar explicitamente a/ae a/b, apenas "sei" ae quero restaurar tudo abaixo. EDIT : E eu também não "sei" b, ou quais outros diretórios residem no mesmo nível que a.

#!/bin/sh

rm -rf repo; git init repo; cd repo
for f in a b; do
  for g in a b c; do
    mkdir -p $f/$g
    touch $f/$g/$f$g
    git add $f/$g
    git commit -m "added $f/$g"
  done
done
git config core.sparsecheckout true
echo a/a > .git/info/sparse-checkout
echo a/b >> .git/info/sparse-checkout
echo b/a >> .git/info/sparse-checkout
git read-tree -m -u HEAD
echo "After read-tree:"
find * -type f

rm a/a/aa
rm a/b/ab
echo >> b/a/ba
echo "After modifying:"
find * -type f
git status

# How to make files a/* reappear without changing b and without recreating a/c?
git checkout -- a

echo "After checkout:"
git status
find * -type f

Com o Git 2.23 (agosto de 2019), você tem o novo comandogit restore

git restore --source=HEAD --staged --worktree -- aDirectory
# or, shorter
git restore -s@ -SW  -- aDirectory

Isso substituiria o índice e a árvore de trabalho pelo HEADconteúdo, como reset --hardfaria, mas por um caminho específico.

Resposta original (2013)

Observe (como comentado por Dan Fabulich ) que:

• git checkout -- <path> não faz uma reinicialização completa: substitui o conteúdo da árvore de trabalho pelo conteúdo preparado.
• git checkout HEAD -- <path>faz uma redefinição definitiva para um caminho, substituindo o índice e a árvore de trabalho pela versão do HEADcommit.

Conforme respondido por Ajedi32 , os dois formulários de checkout não removem arquivos que foram excluídos na revisão de destino .
Se você tiver arquivos extras na árvore de trabalho que não existem no HEAD, a git checkout HEAD -- <path>não os removerá.

Nota: Com git checkout --overlay HEAD -- <path>(Git 2.22, primeiro trimestre de 2019) , os arquivos que aparecem no índice e na árvore de trabalho, mas não dentro, <tree-ish>são removidos, para fazer com que correspondam <tree-ish>exatamente.

Mas esse check-out pode respeitar um git update-index --skip-worktree(para os diretórios que você deseja ignorar), conforme mencionado em " Por que os arquivos excluídos continuam reaparecendo no meu check-out esparso do git? ".

De acordo com o desenvolvedor do Git Duy Nguyen, que gentilmente implementou o recurso e um comutador de compatibilidade , o seguinte funciona como esperado no Git 1.8.3 :

git checkout -- a

(onde aé o diretório que você deseja restaurar). O comportamento original pode ser acessado via

git checkout --ignore-skip-worktree-bits -- a

Tente mudar

git checkout -- a

para

git checkout -- `git ls-files -m -- a`

Desde a versão 1.7.0, o Git honra o sinalizador skip-worktree .ls-files

Executando seu script de teste (com alguns pequenos ajustes mudando git commit... para git commit -qe git statuspara git status --short) saídas:

Initialized empty Git repository in /home/user/repo/.git/
After read-tree:
a/a/aa
a/b/ab
b/a/ba
After modifying:
b/a/ba
 D a/a/aa
 D a/b/ab
 M b/a/ba
After checkout:
 M b/a/ba
a/a/aa
a/c/ac
a/b/ab
b/a/ba

Executando seu script de teste com as checkoutsaídas de mudança propostas :

Initialized empty Git repository in /home/user/repo/.git/
After read-tree:
a/a/aa
a/b/ab
b/a/ba
After modifying:
b/a/ba
 D a/a/aa
 D a/b/ab
 M b/a/ba
After checkout:
 M b/a/ba
a/a/aa
a/b/ab
b/a/ba

No caso de simplesmente descartar alterações, os comandos git checkout -- path/ou git checkout HEAD -- path/sugeridos por outras respostas funcionam muito bem. No entanto, quando você deseja redefinir um diretório para uma revisão diferente de HEAD, essa solução tem um problema significativo: ela não remove os arquivos que foram excluídos na revisão de destino.

Então, em vez disso, comecei a usar o seguinte comando:

git diff --cached commit -- subdir | git apply -R --index

Isso funciona encontrando a diferença entre a confirmação de destino e o índice, aplicando essa diferença inversamente ao diretório e índice de trabalho. Basicamente, isso significa que faz com que o conteúdo do índice corresponda ao conteúdo da revisão que você especificou. O fato de git diffusar um argumento de caminho permite limitar esse efeito a um arquivo ou diretório específico.

Como esse comando é bastante longo e pretendo usá-lo com frequência, configurei um apelido para ele, que chamei de reset-checkout:

git config --global alias.reset-checkout '!f() { git diff --cached "$@" | git apply -R --index; }; f'

Você pode usá-lo assim:

git reset-checkout 451a9a4 -- path/to/directory

Ou apenas:

git reset-checkout 451a9a4

Vou oferecer uma opção terrível aqui, já que não tenho idéia de como fazer algo com o git, exceto , add commite pushaqui está como eu "reverti" um subdiretório:

Iniciei um novo repositório no meu PC local, reverti tudo para o commit do qual eu queria copiar o código e depois copiei esses arquivos para o meu diretório de trabalho, add commit pushe pronto. Não odeie o jogador, odeie o Sr. Torvalds por ser mais esperto do que todos nós.

Uma redefinição normalmente muda tudo, mas você pode usar git stashpara escolher o que deseja manter. Como você mencionou, stashnão aceita um caminho diretamente, mas ainda pode ser usado para manter um caminho específico com o --keep-indexsinalizador. No seu exemplo, você esconderia o diretório b e redefiniria todo o resto.

# How to make files a/* reappear without changing b and without recreating a/c?
git add b               #add the directory you want to keep
git stash --keep-index  #stash anything that isn't added
git reset               #unstage the b directory
git stash drop          #clean up the stash (optional)

Isso leva você a um ponto em que a última parte do seu script produzirá isso:

After checkout:
# On branch master
# Changes not staged for commit:
#
#   modified:   b/a/ba
#
no changes added to commit (use "git add" and/or "git commit -a")
a/a/aa
a/b/ab
b/a/ba

Acredito que esse foi o resultado desejado (b permanece modificado, arquivos a / * estão de volta, a / c não é recriado).

Essa abordagem tem o benefício adicional de ser muito flexível; você pode obter a granulação mais fina que desejar adicionando arquivos específicos, mas não outros, em um diretório.

Se o tamanho do subdiretório não for particularmente grande E você desejar ficar longe da CLI, aqui está uma solução rápida para redefinir manualmente o subdiretório:

1. Alterne para a ramificação principal e copie o subdiretório a ser redefinido.
2. Agora volte para o ramo de recursos e substitua o subdiretório pela cópia que você acabou de criar na etapa 1.
3. Confirme as alterações.

Felicidades. Você acabou de redefinir manualmente um subdiretório no ramo de recursos para ser o mesmo do ramo principal !!

A resposta do Ajedi32 é o que eu estava procurando, mas para alguns commits, encontrei este erro:

error: cannot apply binary patch to 'path/to/directory' without full index line

Pode ser porque alguns arquivos do diretório são arquivos binários. A adição da opção '--binary' ao comando git diff o corrigiu:

git diff --binary --cached commit -- path/to/directory | git apply -R --index

A respeito

subdir=thesubdir
for fn in $(find $subdir); do
  git ls-files --error-unmatch $fn 2>/dev/null >/dev/null;
  if [ "$?" = "1" ]; then
    continue;
  fi
  echo "Restoring $fn";
  git show HEAD:$fn > $fn;
done