Dlaczego powinienem napisać komunikat zatwierdzenia?

18

Dlaczego powinienem napisać komunikat zatwierdzenia? Nie chcę i myślę, że za każdym razem jest to głupie.

Interfejs GUI, którego używam, który pozostanie nienazwany, zmusza cię do tego. Słyszę, że inni robią to za każdym razem, nawet jeśli używają VCS w wierszu poleceń.

Jeśli popełniam kilka razy dziennie i nie ukończyłem funkcji, o czym piszę? TYLKO piszę wiadomość po wielu zatwierdzeniach i czuję, że nadszedł czas na mini tag lub kiedy zrobię prawdziwy tag.

Czy mam rację, czy coś brakuje? również używam systemu rozproszonego

2528
źródło
1
Nie przejmuj się, po prostu powiedz „bla” w wierszu komentarza. Tak długo, jak nigdy nie udostępnisz kodu nikomu i tak długo, jak nikt inny nie będzie nad nim pracował, i tak długo, jak długo nie będziesz musiał przywracać kodu i dopóki nie popełnisz żadnego błędu kodu i ... poczekaj chwilę, dlaczego ponownie używasz kontroli wersji?
Michael Durrant

Odpowiedzi:

24

Wszystkim ludziom, którzy mówią: „zatwierdzaj tylko wtedy, gdy masz użyteczną, przemyślaną wiadomość do napisania, a gdy Twoja funkcja jest w 100% ukończona i masz do niej testy jednostkowe”, mówię: Nadal masz nastawienie SVN .

Jeśli używasz git , to właśnie nazwałbym inteligentny przepływ pracy:

  1. Zaangażuj się tak często, jak chcesz . Napisz tam jakąkolwiek starą szybką wiadomość. I tak nikt tego nie zobaczy.
  2. Po powiedzmy 10 zatwierdzeń, zakończyłeś pracę nad którą pracowałeś. Teraz napisz testy i zatwierdz je. Lub cokolwiek chcesz. Jeśli lubisz TDD, najpierw napisz testy, nie obchodzi mnie to, nie git.
  3. git rebase -iod pierwszego „niechlujnego” zatwierdzenia, które dodałeś i naprawiłeś swoją lokalną historię, zgniatając, edytując, pomijając i w inny sposób czyszcząc swoją najnowszą historię w logiczne, czyste zatwierdzenia z ładnymi wiadomościami .
  4. Po oczyszczeniu poproś kogoś, aby cię odciągnął.
  5. Wypłukać i powtórzyć.

Zauważ, że krok 3 ma miejsce, gdy skończysz z tymi ładnymi zatwierdzeniami, których szukałeś, i że używając SVN będziesz musiał powstrzymać się od zatwierdzania, dopóki nie zrobisz dwóch pierwszych kroków, co sugeruje większość pozostałych odpowiedzi. IOW, nie chcesz narzucać innym w połowie napisanego, nieprzetestowanego kodu innym osobom, więc nie robisz tego przez tydzień, dopóki nie skończysz swojej funkcji. Nie używasz kontroli wersji do pełnego potencjału.

Pamiętaj także, że gdziekolwiek pomiędzy krokami 1 i 3, możesz git pushwprowadzić zmiany w swoim prywatnym lustrze repo na serwerze, aby uzyskać bezpłatne kopie zapasowe, jeśli dysk twardy laptopa zginie.

rev Alex Budovski
źródło
Dobra odpowiedź, podoba mi się. Trochę boję się użyć bazy. Oto artykuł o tym, jak źle się dzieje i jak go odzyskać bluemangolearning.com/blog/2009/03/…
@kwas, jeśli publikujesz własne zmiany, nie powinno być żadnych konfliktów. Poza tym, trzeba spróbować ciężko stracić coś w git.
Alex Budovski
4
mój przepływ pracy, git rock
Nazgob
1
@Boris: Ponieważ wyraźnie mówi o git, który wyraźnie NIE jest subwersją
3
Naprawdę nie powinno być żadnej znaczącej pracy napisanie zdania stwierdzającego to, co właśnie zrobiłeś, a niszczenie historii za pomocą rebase wydaje się okropne. Załóżmy, że wprowadziłeś błąd w 5. z tych dziesięciu zatwierdzeń, który nie został wykryty dopiero tydzień później. Możliwość przypisania go do jednego małego zatwierdzenia bardzo ci pomoże.
Gort the Robot
55

Ponieważ gdy jakiś słaby opiekun poluje na błąd i stwierdza, że ​​został on dodany w rev. Xyz, będzie chciał wiedzieć, co rev. Xyz miał zrobić.

Peter Taylor
źródło
38
Więc może odczytać 5000 wierszy spaghetti, które właśnie zameldowałem, JEESH !!! Niektórzy ludzie są po prostu leniwi!
Edward Strange
9
PONIEWAŻ, gdy biedny frajer podąża za tobą (za 3 lata) i patrzy na historię i idzie ... WTF .. WTF .. WTF, przynajmniej będzie miał pojęcie o tym, co się dzieje. Możesz łatwo dodać komentarz, np. „Rutynowe sprawdzanie, funkcja X, niekompletne”.
szybko_now
3
@ acidzombie24: Ponieważ każde zatwierdzenie powinno powiedzieć, po co było - nawet jeśli jest to „poprawiona literówka w…”, historia zmian nie ma sensu, chyba że wiesz, do czego służą poprawki.
Orbling
11
@ quickly_now, biedny frajer może nawet być sobą. Niestety jest to jedna z rzeczy, których musisz doświadczyć, aby w pełni to docenić.
2
@acidzombie - dlaczego sprawdzasz niepełne zmiany?
Edward Strange
35

Komentujesz swój kod źródłowy, prawda?

Piszesz najlepsze komentarze, które mówią dlaczego, ponieważ kod mówi tylko jak ?

Komunikat zatwierdzenia jest takim komentarzem, dlatego jest bardzo ważny i im więcej myślisz o jego poprawnym wykonaniu, tym bardziej jest on użyteczny dla przyszłego opiekuna oprogramowania.

W przypadku każdego aktywnego oprogramowania ten komentarz zostanie wyświetlony w coś podobnego

gitk - wszystkie próbki

(znalezione pod adresem http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Pozwala to widok z lotu ptaka , który pracował nad oprogramowaniem kiedy i co zrobili.

Należy pamiętać, że to jest ostatecznym celem zatwierdzenia komentarza, a mianowicie pokazuje się w takiej listy powiedzenie „ co ” do swojej własnej przyszłości lub kolegi, i to jest powód, dlaczego należy dbać w pisanie dobrych popełnić wiadomości.

1249
źródło
2
@acidzombie, mogę mówić tylko w imieniu git, ale możesz popełnić bardzo małe kroki lokalnie, a następnie zgrupować je wszystkie razem w jednym zatwierdzeniu podczas przesyłania w górę. Ten komunikat zatwierdzenia może być opisowy.
2
@acidzombie, dlaczego popełniasz błędy, jeśli nie wprowadziłeś wystarczających zmian, aby uzasadnić komentarz? Proszę wytłumacz.
2
@Thor: Ponieważ kontrola wersji chroni kod przed utratą, a nawet częściowo zrobiony kod powinien być chroniony.
Ben Voigt
1
@Ben, zatwierdzenia służą do długoterminowego przechowywania i powinny dokładnie odzwierciedlać „fragmenty” pracy. Ochrona przed utratą jest moim zdaniem prostopadła do kontroli wersji i powinna być obsługiwana przez odpowiedni system tworzenia kopii zapasowych. Znalazłem Time Machine na komputery Mac wyjątkowo dobrze nadające się do tego celu - mam nadzieję, że podobny system jest dostępny dla systemu Windows.
2
+1 Jestem fanem nie zanieczyszczania mojej kontroli źródła bezsensownymi zatwierdzeniami. Ułatwia to wyszukiwanie konkretnego zatwierdzenia (dzięki przydatnym komentarzom) i wiem, że kiedy sprawdzam kod, zawsze działa. Tradycyjne oprogramowanie do tworzenia kopii zapasowych jest lepszą opcją do ochrony mojego lokalnego repozytorium pomiędzy zatwierdzeniami. Działa to dobrze z DVCS, ale musisz pamiętać, że lokalna odprawa nie jest tak naprawdę kopią zapasową twojego kodu.
Adam Lear
15

Jeśli komunikat zatwierdzenia wydaje ci się głupi, oznacza to, że używasz niepoprawnych zatwierdzeń.

Zatwierdzenia powinny być dokonywane z dobrego powodu - powinny być powiązane z zadaniami, które podzieliłeś dla funkcji, nad którą pracujesz. Niezależnie od tego, czy zadania te są formalne, czy tylko w twojej pamięci, każda dokonana zmiana powinna mniej więcej zakończyć zadanie, a zatem być w jakiś sposób funkcjonalna.

Wtedy twoje komunikaty zatwierdzenia służą znacznie lepszemu celowi. Opisz ukończone zadanie, a jeśli nie jest ono śledzone w innym miejscu, dlaczego to zadanie było potrzebne lub do jakiego celu służy:

  • Przebudowano klasę użytkownika, aby uzyskać lepszą enkapsulację
  • Utworzono kody pośredniczące API, aby interfejsy mogły być używane w klasie kontrolera
  • Przekształcił klasę bazy danych w klasę abstrakcyjną, aby w przypadkach testowych można było użyć próbnej bazy danych

Następnie Ty lub inni programiści możecie przeglądać repozytorium lub historię plików i dość łatwo zobaczyć, gdzie nastąpiły pewne ewolucje i dlaczego. Lub, jeśli konkretna wersja zostanie uznana za winną błędu, komunikat zatwierdzenia da wskazówkę, dlaczego ta linia została wstawiona, abyś nie tylko ją rozerwał i możliwe było ponowne rozbicie czegoś, co było uważane za naprawiono, a zamiast tego można to naprawić we właściwy sposób.

NickC
źródło
1
+1, wydaje się, że popełnia zbyt często lub w złych punktach zatrzymania. Jeśli chce tylko dobrego punktu rezerwowego dla niektórych eksperymentalnych zmian, może użyć indeksu, gałęzi tymczasowej, zmienić poprzednie zatwierdzenia zamiast tworzyć nowe, a nawet użyć bufora cofania w swoim edytorze.
Karl Bielefeldt
1
@Karl: IIRC linus w swoim git google talk powiedział, że średnio 6 zmian jest wykonywanych dziennie. Teraz nie wiem, ile za dużo jest uważane, ale w tym projekcie zobowiązałem się, gdy zacząłem pracować nad refleksją (zapętlam odpowiednie dane, nic z tym nie robię), po wygenerowaniu interfejsu, ale przed serializacją. i pracuję teraz nad uruchomieniem serializacji, mimo że miałem interfejs 2 godziny temu. Kiedy to zadziała, popełnię i powiem „podstawy refleksji”, ale w pierwszych trzech przypadkach miałbym kiedykolwiek zostawiać komentarz, kiedy łatwo mogę zobaczyć, kiedy funkcja „działa” co każde zatwierdzenie x.
Właściwie mogę się wstrzymać, dopóki nie dostanę podstawowego testu, ponieważ w przeciwnym razie, jeśli komentuję każde zatwierdzenie, skąd mam wiedzieć, który z nich ma stabilne odbicie? „podstawy refleksji”, „serializacja refleksji” „test serializacji refleksji” Zakładając, że serializacja jest koniecznością, może to być 2. lub 3. pozycja. Test może oznaczać test jednostkowy lub test może oznaczać testowanie, jeśli działa na podstawowych klasach, których wymagam. Po prostu myślę, że komentowanie ma sens, kiedy mogę powiedzieć „podstawy do refleksji”, zamiast zgadywać, które z nich faktycznie oznaczają, że podstawy działają. Również łatwiej jest przeglądać / znajdować, gdy jest mniej do czytania.
@acid, całym celem zatwierdzenia jest możliwość powrotu do niego lub porównania z nim zmian. Jeśli kiedykolwiek musisz to zrobić ze swoimi wcześniejszymi zobowiązaniami, skąd wiesz, który wybrać? Tutaj nie musisz pisać powieści. „interfejs działa”, „serializacja działa” i „refleksja działa”, moim zdaniem, jest w porządku. Nie ma ustalonej maksymalnej liczby zatwierdzeń na dzień, ale jeśli twoje wiadomości brzmią „trochę pracy nad interfejsem”, „trochę więcej pracy nad interfejsem” „interfejs prawie gotowy”, to popełniasz zbyt często i powinieneś po prostu użyć indeks.
Karl Bielefeldt
@Karl: Jaki jest indeks btw? Wiem, że git ma zapas, ale nie sądzę, że o tym mówisz. Co to robi?
12

Komentarze zatwierdzenia nie rozwiązują wszystkiego. Zawsze istnieje szansa, że ​​mogą wprowadzić w błąd tak samo, jak pomagają - zwłaszcza gdy deweloperzy są źli z powodu konieczności wejścia na nie. Spróbuj tego: pomyśl o nich jak o śladzie okruchów chleba w lesie lub o punktach wspinaczkowych lub pociskach znakujących. Zrobione prawidłowo, mogą nakreślić mylącą ścieżkę.

Nie rób z nich wielkiego interesu. Bądź szczery:

  • „Edytowane encje indeksu przestrzennego, Daos i interfejsy użytkownika do obsługi operacji X”
  • „Przyrostowe zameldowanie dla żądania funkcji # 1234 i błędu # 5678”
  • „Zepsułem ostatnią wersję. Są to pliki, które przegapiłem”.

Mów krótko i „duży obraz”. Jeśli to możliwe, sprawdź numer problemu w swoim systemie funkcji / błędów. Niektóre interfejsy kontroli wersji zawierają pole do tego rodzaju rzeczy.

Scant Roger
źródło
2
+1 za pomysł skrócenia terminu. Krótki, prosty i wystarczająco dobry jest w porządku.
szybko_now
1
IMHO jeszcze lepszym wskazówką byłby wspólny przepis „tak krótki, jak to możliwe, tak długo, jak to konieczne”; ponieważ czasami po prostu nie można tego
streścić
11

Zmniejsza liczbę WTF / minutę;)

wprowadź opis zdjęcia tutaj

co przekłada się na szczęśliwszy zespół (który cię nie nienawidzi) i lepszą wydajność zespołu potencjalnie przy niższych kosztach

wieża
źródło
4
Głosowałbym za tym, gdybyście wyjaśnili, dlaczego to prawda.
SingleNegationElimination
@TokenMacGuy - Przepraszam, nie śledzę.
Gawron
1
W jaki sposób ekspresyjne komunikaty zatwierdzania zmniejszają WTF / minutę (robią to z całą pewnością)
SingleNegationElimination
@TokenMacGuy - Myślałem, że to oczywiste.
Wież
9

Tak więc reszta twojego zespołu wie, że WTF robisz sprawdzanie zmian w drzewie projektu.

Edward Strange
źródło
7
Dodam komunikaty zatwierdzania do moich projektów, gdy jestem TYLKO DEWELOPEREM! Ponieważ kiedy wrócę za 2 lata, aby przyjrzeć się tym rzeczom, chcę wiedzieć, że robiłem wtedy WTF. Wiem doskonale, że 99% czasu na to nie będzie patrzeć. 1% czasu zaoszczędzi mi 2 tygodnie cierpienia i myślę, że cena wpisania 10-sekundowej wiadomości zatwierdzenia jest warta długoterminowej korzyści, jaką otrzymam.
szybko_niedz.
@ quickly_now, agonia nawet? Czy twój kod jest taki zły?
1
@quickly_now: Amen do tego. W ciągu roku lub dwóch wychodzi ze mnie dużo kodu, co co ostatni miesiąc miał zrobić miesiąc później, Bóg tylko wie. Bóg i moja historia zmian.
Orbling
O tak. Też się zgadzam. Uważam to za doświadczenie == pokora.
Michael Durrant,
8

ponieważ jeśli nie ćwiczysz wprowadzania porządnych wiadomości zatwierdzania, skończysz jak mój kolega, który wprowadza wiadomości takie jak

no changes

lub

testing

dla zatwierdzeń z ponad stu zmienionymi plikami (tutaj nie żartuję !!).

Jeśli zostaniesz takim programistą, będziesz wyglądać głupio w oczach reszty świata, bez względu na to, jak głupio myślisz, po prostu wpisując wiadomość.

stijn
źródło
1
brzmi jak idealny kandydat do wzajemnej oceny przed zatwierdzeniem, jeśli kiedykolwiek go usłyszałem.
2
o rany, pracowałem z takimi ludźmi. Doprowadza mnie do szału.
sevenseacat
4

Dlaczego popełniasz błędy, jeśli zmiany nie mają znaczenia?

Po prostu zatwierdzaj zmiany, które mają znaczenie. Np. Zrobiłem dość dużą refaktoryzację w drugim tygodniu, co zajęło mi około 3 dni. W tym czasie miałbym mnóstwo zobowiązań. Niektóre były raczej niewielkimi zmianami („przemianowano klasę X na Y, aby odzwierciedlić nową odpowiedzialność” lub „przeniesiono metodę Z () na klasę Q”), a inne były naprawdę duże. Kiedy skończę z funkcją / refaktoryzacją, sprawdzam, czy niektóre zatwierdzenia mogą zostać zmiażdżone (przynajmniej git obsługuje to, nie wiem o innych narzędziach), ale zwykle zostawiam je bez zmian, ponieważ pomaga to później.

Chyba nie popełnilibyście w trakcie edycji linii, więc powinna ona mieć znaczenie. Po prostu opisz, co zrobiłeś od ostatniego zatwierdzenia.

EricSchaefer
źródło
3

wyobraź sobie sytuację, w której zepsułeś system wprowadzając pewne zmiany i zdaj sobie z tego sprawę po kilku zatwierdzeniach przez zespół. Nie pamiętasz, jaka była zmiana, ale pamiętasz, że coś mogło pójść nie tak, gdy ulepszałeś funkcję X lub usuwałeś plik z modułu Y.

Ale niestety numer wersji nie mówi ci, kiedy zmieniłeś X lub Y. Więc twój wybór albo odczytaj wszystkie kody zatwierdzone w ciągu ostatnich N dni, albo po prostu przeczytaj szczegółowe napisane komunikaty zatwierdzeń (znacznie bardziej czytelne niż kod).

Więc jeśli piszesz ten sam, nudny, bezużyteczny, niepowiązany tekst w komunikacie zatwierdzenia, ponieważ musisz, jest bardziej szkodliwy niż posiadanie komunikatu zatwierdzenia. Ponieważ zamiast znaleźć źródło błędu błędna wiadomość Cię wprowadzi w błąd.

Dlatego staraj się pisać sensowne komunikaty zatwierdzania przy każdym zatwierdzeniu, które mogą pomóc tobie i opiekunowi.

GG01
źródło
Dlaczego powinienem to robić przy każdym zatwierdzeniu zamiast na koniec dnia, co drugi dzień lub kiedy kończę funkcję?
1
dlaczego popełniasz to często, skoro nie ma „naturalnego” powodu?
Zatwierdzam za każdym razem, gdy wprowadzę jakieś znaczące zmiany, aby mogły zostać odzwierciedlone w repozytorium, a inni programiści mogą sprawdzać te zmiany. Ale udzielona odpowiedź pomaga z lotu ptaka obserwować, co i przez kogo jest zrobione.
GG01
@ acidzombie24 Cóż, nie popełniaj w połowie ukończonych rzeczy, chyba że naprawdę musisz. Aby inni mogli zobaczyć, co robisz / pracujesz, kiedy pewnego dnia zadzwonisz z powodu choroby i nic nie działa. A może pamiętasz, gdzie przerwałeś, kiedy musisz siedzieć na spotkaniach przez 2 dni. Tak więc łatwiej jest wskazać, która wersja złamała kompilację i spojrzeć na różnicę.
nos
@ Thorbjørn: Dlaczego nie chciałbym dokonać zmiany, której nie chcę ponownie robić?
3

Jeśli pracujesz z innymi, komunikaty zatwierdzania są bardzo ważne, aby zobaczyć, co zrobili inni: sprawdzanie różnic dla każdego z nich to znacznie więcej pracy i możesz nie zrozumieć, dlaczego ktoś to zrobił. Jeśli pracujesz z innymi, a ktoś (być może nie ty) musi spojrzeć wstecz, na przykład, aby śledzić zmiany zachowań od poprzedniej wersji w nieoczekiwany sposób ... naprawdę utrudniasz życie, nie wykorzystując pomocnej wskazówki w zatwierdzeniu wiadomość.

Jeśli pracujesz sam ... nad projektem, który jest w większości zakodowany „tak jak jest” (na przykład pojedyncza prosta strona internetowa lub skrypt), mniej więcej widzę, skąd pochodzisz. Jeśli pracuję nad czymś takim, dbam tylko o datę / godzinę lub najnowsze zmiany podczas kontynuowania pracy nad czymś (musisz przywrócić, ale to ma znaczenie tylko podczas programowania, a nie po jego wdrożeniu). Kontrola wersji to tylko sposób tworzenia kopii zapasowych z kilkoma dodatkowymi zaletami - w pełni zgadzam się, że nie w pełni wykorzystuję system - ale w niektórych małych projektach może to nie być potrzebne.

Przychodzi mi do głowy, zanim Kontrola wersji jest wykorzystywana na dwa różne sposoby, jeden z dokumentowania zmian w projekcie, a drugi jako pomocna dłoń dla programistów w miejscu ... a te dwie są całkowicie różne od siebie. Komunikaty zatwierdzania są bardzo ważne z jednej strony, a z drugiej strony mogą być w większości bezużyteczne.

Inka
źródło
3

Coś brakuje. Tam musi być powodem do wykonywania popełnić w przeciwnym razie nie byłoby to robić.

Jedyne, co musisz zrobić w komentarzu, to podać powód w słowa, nawet jeśli tylko on wip: adding new state objects

Richard Harrison
źródło
dokładnie. Nawet jeśli (jak wspomniano wcześniej) jest to po prostu kod, którego nie chcesz ponownie robić, to oczywiście coś znaczy, dlatego nie powinno być trudno napisać bardzo szybkie streszczenie.
sevenseacat
2

Podobnie jak wiele innych, w wolnym czasie robię trochę kodowania i używam systemu kontroli wersji, aby śledzić zarówno mój rozwój, jak i zmiany. Ilość wolnego czasu, którą mam, różni się znacznie w poszczególnych tygodniach i miesiącach. Wiele razy zdarzyło się, że nie miałem czasu na pisanie kodu w projekcie przez wiele tygodni, a nawet miesięcy, a taki czas, jaki miałem, zwykle wahałby się od 10 minut (typowy dzień) do 40 minut (dobry dzień). Z pewnością nie są to świetne warunki - szczególnie w przypadku problemów z debugowaniem.

Konieczne było przechowywanie notatek, które się nie zgubiły i były łatwe do odzyskania. Pod koniec każdej sesji praca sesji zostanie poświęcona szczegółowym komunikatem. Mógłbym wtedy przejść do historii zatwierdzeń i śledzić mój postęp i proces myślowy. To pozwoliło mi wybrać miejsce, w którym byłem w zeszłym tygodniu lub w zeszłym miesiącu z najmniejszą ilością straconego cennego czasu.

Próbuję zilustrować to, że dobre wiadomości zatwierdzania pomagają Tobie (i każdemu, kto przyjdzie po Tobie) dowiedzieć się, co się stało, co się dzieje, dokąd wszystko idzie, a przede wszystkim dlaczego.

iskrzący
źródło
2

Pomyśl o tym logicznie przez minutę. Kiedy popełniasz, oznacza to, że coś zostało zrobione. Jeśli nie zostawisz żadnej wiadomości, skąd inni ludzie będą wiedzieć, co zostało zrobione?

Sergio
źródło
Jedno spojrzenie na mój niesamowicie oczywisty kod, a oni natychmiast dowiedzą się wszystkiego, co robi i wszystkich niesamowitych testów, które przejdzie w 100%. Przepraszam, jestem dziś w humorze [więc KIDDING];)
Michael Durrant
1

Jeśli nie skomentujesz swoich zobowiązań, możesz ulec pokusie skomentowania zmiany w źródle. Z czasem może to zagracić źródło.

Joris Geer
źródło
2
nie mam ochoty tego robić
1

Komunikaty zatwierdzania to szybki sposób na sprawdzenie, co się dzieje podczas odprawy, i pomoże innym deweloperom w zespole, gdy będą chcieli wiedzieć, który aspekt kodu zmienił się w jakich wersjach (z różnych powodów).

W powiązanej notatce sugerowałbym określenie numeru sprawy modułu śledzenia błędów (mam nadzieję, że go używasz) w komunikacie zatwierdzenia, aby w przyszłości pomocne było łatwe śledzenie rzeczy.

Mahesh Velaga
źródło
1

Aby opiekun tego kodu 1 rok później wiedział, kogo ścigać za ten okropny kod. :)

talonx
źródło
Po to jest blamefunkcja vcs.
Peter Taylor,