Come ripristinare git --hard una sottodirectory?

AGGIORNAMENTO² : Con Git 2.23 (agosto 2019), c'è un nuovo comando git restoreche fa questo, vedi la risposta accettata .

AGGIORNAMENTO : Funzionerà in modo più intuitivo a partire da Git 1.8.3, vedi la mia risposta .

Immagina il seguente caso d'uso: voglio sbarazzarmi di tutte le modifiche in una specifica sottodirectory del mio albero di lavoro Git, lasciando intatte tutte le altre sottodirectory.

• Posso fare git checkout ., ma git checkout. aggiunge le directory escluse dal checkout sparse

• Sì git reset --hard, ma non mi permette di farlo per una sottodirectory:

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

  Ancora: perché git non è in grado di eseguire reimpostazioni hard / soft per percorso?

• Posso applicare una patch inversa allo stato corrente usando git diff subdir | patch -p1 -R, ma questo è un modo piuttosto strano di farlo.

Qual è il comando Git corretto per questa operazione?

Lo script seguente illustra il problema. Inserisci il comando corretto sotto il How to make filescommento: il comando corrente ripristinerà il file a/c/acche dovrebbe essere escluso dal checkout sparse. Nota che non voglio ripristinare esplicitamente a/ae a/b, solo "so" ae voglio ripristinare tutto ciò che segue. EDIT : E anche io non "sapere" b, o quali altre directory risiedono allo stesso livello di 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

Con Git 2.23 (agosto 2019), hai il nuovo comandogit restore

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

Ciò sostituirebbe sia l'indice che l'albero di lavoro con HEADcontenuti, come reset --hardfarebbe, ma per un percorso specifico.

Risposta originale (2013)

Nota (come commentato da Dan Fabulich ) che:

• git checkout -- <path> non esegue un hard reset: sostituisce il contenuto dell'albero di lavoro con il contenuto graduale.
• git checkout HEAD -- <path>esegue un hard reset per un percorso, sostituendo sia l'indice che l'albero di lavoro con la versione dal HEADcommit.

Come risposto da Ajedi32 , entrambe le forme checkout non rimuovere i file che sono stati eliminati nella revisione di destinazione .
Se nella struttura di lavoro sono presenti file aggiuntivi che non esistono in HEAD, git checkout HEAD -- <path>non verranno rimossi.

Nota: con git checkout --overlay HEAD -- <path>(Git 2.22, Q1 2019) , i file che appaiono nell'indice e nell'albero di lavoro, ma non in, <tree-ish>vengono rimossi per farli corrispondere <tree-ish>esattamente.

Ma quel checkout può rispettare un git update-index --skip-worktree(per quelle directory che vuoi ignorare), come menzionato in " Perché i file esclusi continuano a riapparire nel mio checkout sparso git? ".

Secondo lo sviluppatore di Git Duy Nguyen, che ha gentilmente implementato la funzionalità e un interruttore di compatibilità , i seguenti funzionano come previsto da Git 1.8.3 :

git checkout -- a

(dove si atrova la directory da ripristinare). È possibile accedere al comportamento originale tramite

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

Prova a cambiare

git checkout -- a

per

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

Dalla versione 1.7.0, Git's onora la bandiera skip-worktree .ls-files

Esecuzione dello script di test (con alcune piccole modifiche che cambiano git commit... in git commit -qe git statusto git status --short) output:

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

Esecuzione dello script di test con gli checkoutoutput di modifica proposti :

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

Nel caso di scartare semplicemente le modifiche, i comandi git checkout -- path/o git checkout HEAD -- path/suggeriti da altre risposte funzionano alla grande. Tuttavia, quando si desidera reimpostare una directory su una revisione diversa da HEAD, quella soluzione presenta un problema significativo: non rimuove i file che sono stati eliminati nella revisione di destinazione.

Quindi, invece, ho iniziato a utilizzare il seguente comando:

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

Funziona individuando la differenza tra il commit di destinazione e l'indice, quindi applicando la differenza inversa alla directory e all'indice di lavoro. Fondamentalmente, questo significa che fa corrispondere il contenuto dell'indice al contenuto della revisione specificata. Il fatto che git diffaccetta un argomento path consente di limitare questo effetto a un file o una directory specifici.

Poiché questo comando è abbastanza lungo e ho intenzione di usarlo frequentemente, ho creato un alias per questo che ho chiamato reset-checkout:

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

Puoi usarlo in questo modo:

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

O semplicemente:

git reset-checkout 451a9a4

Offrirò una terribile opzione qui, dal momento che non ho idea di come fare qualsiasi cosa con git tranne , add commited pushecco come ho "ripristinato" una sottodirectory:

Ho avviato un nuovo repository sul mio PC locale, ho ripristinato il tutto sull'impegno da cui volevo copiare il codice e quindi ho copiato quei file nella mia directory di lavoro, add commit pushecc. Non odiare il giocatore, odia il signor Torvalds per essere più intelligente di tutti noi.

Un reset normalmente cambia tutto, ma è possibile utilizzare git stashper scegliere ciò che si desidera conservare. Come hai detto, stashnon accetta direttamente un percorso, ma può comunque essere utilizzato per mantenere un percorso specifico con la --keep-indexbandiera. Nel tuo esempio, devi nascondere la directory b, quindi reimpostare tutto il 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)

Questo ti porta a un punto in cui l'ultima parte dello script produrrà questo:

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

Credo che questo sia stato il risultato finale (b rimane modificato, i file a / * sono tornati, a / c non è stato ricreato).

Questo approccio ha l'ulteriore vantaggio di essere molto flessibile; puoi ottenere la granularità che desideri aggiungendo file specifici, ma non altri, in una directory.

Se la dimensione della sottodirectory non è particolarmente grande, E si desidera stare lontani dalla CLI, ecco una rapida soluzione per ripristinare manualmente la sottodirectory:

1. Passa al ramo principale e copia la sottodirectory da ripristinare.
2. Ora torna al ramo delle funzionalità e sostituisci la sottodirectory con la copia appena creata nel passaggio 1.
3. Conferma le modifiche.

Saluti. Hai appena ripristinato manualmente una sottodirectory nel tuo ramo delle caratteristiche per essere uguale a quella del ramo principale !!

La risposta di Ajedi32 è ciò che stavo cercando, ma per alcuni commit ho riscontrato questo errore:

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

Può essere perché alcuni file della directory sono file binari. Aggiunta dell'opzione '--binary' al comando git diff risolto:

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

Che dire

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