«
»

2017-04-10 splitpatch

by Vasil Kolev

Нов ценен tool – splitpatch (има го в debian, нищо, че е на ruby).

Трябваше да вкараме едно парче код (на perl) в главното ни repo, и след code review имаше забележки като за 11 промени. Вкарахме ги, тествах го и открих, че не работи – output-а беше много много различен от този в началото (който си се знаеше, че е верен).

Един вариант беше някой да гледа промените ред по ред и да се разбере какво е объркано. Вместо да се стига до такива крайни мерки, намерих tool, който може да сцепи patch-а на hunk-ове, и след това направих следното:

for i in ptch/* ; do patch -o test TOOL $i ; ./test debug > $i.output ; done

и след това с един прост for и diff видях кои съвпадат и кои се различават, и проблемния commit лъсна…

Имаше и варианта вместо да patch-вам оригинала, да махам по един patch от финалния, докато не изчезне проблема. При зависещи един от друг hunk-ове пък може да се направи нещо още по-забавно – да се направят всичките комбинации от patch-ове (като са 11 не са толкова много), да се изтества и пак да се хване разликата сравнително лесно (ако например два са виновни).

Изводът е, че човек може да дебъгва код на нещо в много случаи и без да знае езика…

Tags:

This entry was posted on Monday, April 10th, 2017 at 15:40 and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

4 Responses to “2017-04-10 splitpatch”

  1. Антон Тодоров Says:
    April 13th, 2017 at 23:24

    Не отива на добре света…

    Цяла програма написали вместо да се ползва инструмент от GNU coreutils който се намира във всяка дистрибуция* и върши общо взето същата работа?!

    $ csplit -k -f “prefix-” -b “%04d.patch” git_patch_file.patch /diff\ \-\-git/ {*}

    Лесно се преправя да цепи не-git пачове, тогава прави първия файл празен, но го преживявам :)

    [*] На FreeBSD версията е малко тегава ама пак може да се докара да свърши работа

  2. Иван Says:
    April 14th, 2017 at 12:41

    `man git-bisect`

  3. Vasil Kolev Says:
    April 14th, 2017 at 14:10

    @Иван, git-bisect работи в/у цял commit, и е интерактивен донякъде, докато това можах да го пусна веднъж и да се види много лесно коя точно промяна го прави. bisect-а не е лош, но за някои неща е в категорията “тъпа брадва”.
    (в сборника админски задачи ще вкарам една такава, може да пробваш да я решиш с bisect:) )

  4. Иван Says:
    May 1st, 2017 at 23:44

    Ти спомена че си намерил tool, който да сцепи файла на hunk-ове, следователно вече имаме случай където се тестват множество отделни patch-ове, които лесно могат да се вкарат като множество отделни commit-и.

    `git bisect run ` позволява автоматизиране проверката за добър/лош/счупен commit, което е много полезно, когато компилирането и тестването отнемат повече време. Не е панацея, но в твоя случай ще работи.

    Отделно, идеята която исках да посоча е, че оптималният метод е двоично търсене.

    За любителите на git, давам две команди които могат да бъдат полезни в подобни ситуации.

    `git add -i` Позволява да се разбият незаписани промени като отделни commit-и. Командата стартира интерактивен режим, където първо избираш кои файлове да обработваш, после с избор на “patch” ти позволява да добавиш промените hunk по hunk.

    Ако commit-а е вече затрупан от други, може да се ползва `git rebase -i` който (отново) позволява интерактивно преименуване, сливане, пренареждане и дори редактиране на комитите. Разбиването може да стане като изберете редактиране(“edit”), следвате процедурата (reset HEAD^, add -i, rebase —continue) описана
    тук (git-scm book).

    Вярно, интерактивното разбиване на patch-ове не е като автоматизираното.

Leave a Reply