Perché git-bisect deve essere eseguito dalla directory di livello superiore dell'albero di lavoro?

Question

Se si cerca di eseguire uno dei comandi git-bisect da qualsiasi diversa dalla directory radice del repository, si è detto:

è necessario eseguire questo comando dal toplevel dell'albero di lavoro.

Perché è quello? Non conosco altri comandi Git che abbiano questo requisito, e non vedo ragioni ovvie per cui bisect dovrebbe essere speciale. La pagina man non menziona nemmeno questa restrizione.

Non è davvero un grosso problema. Sono per lo più solo curioso.

Answer 1

Guardando alcuni impegna nel progetto, vedo uno di Marcel M. Cary (marcel@oak.homeunix.org)

Dice in un commit (che sembra essere su git-pull, ma penso è rilevante)

"git pull" fallisce perché shell POSIX hanno un concetto di corrente directory di lavoro che è diverso da getcwd(). La shell memorizza questo percorso in PWD. Di conseguenza, "cd ../" può essere interpretato in modo diverso in uno script di shell di chdir ("../") in un programma C. La shell interpreta "../" eliminando essenzialmente l'ultimo componente del percorso testuale da PWD, mentre C chdir() segue il collegamento ".." nella directory corrente sul filesystem. Quando PWD è un collegamento simbolico, queste sono diverse destinazioni . Di conseguenza, i comandi C di Git trovano la struttura di lavoro di livello superiore corretta e gli script di shell no.

https://github.com/git/git/commit/08fc0608657ee91bc85276667804c36a93138c7d

Quindi direi parte del motivo è perché git-bisect è uno script di shell che non può essere di fiducia per trovare il primo livello da solo (quando sono coinvolti i collegamenti simbolici).

Answer 2

Il processo di bisecatura deve verificare diverse revisioni del progetto. Se una revisione particolare non contiene la cartella corrente, la cartella corrente verrà rimossa.

In tal caso, la shell potrebbe finire in una cartella che non si trova più nel filesystem! Git non sarà quindi in grado di trovare la cartella .git e quindi il processo di bisect non può continuare senza intervento.

A dimostrazione:

$ git rev-parse --show-toplevel 
/path/to/project 
$ mkdir tmp 
$ cd tmp 
$ rmdir ../tmp 
$ git rev-parse --show-toplevel 
fatal: Unable to read current working directory: No such file or directory 

Naturalmente questo stesso problema si può verificare quando si fa git checkout, e può essere facilmente fissato dopo il fatto, ad esempio con cd .. (willoller spiega perché funziona nella shell ma non in git).

Tuttavia, poiché bisecatura è un processo , è opportuno evitare questa situazione prima di iniziare, soprattutto se si desidera utilizzare l'automazione come git bisect run.