Однажды старший программист Антон искал причину очередного бага в очень важном проекте компании:
git bisect start
git bisect bad
git bisect good
…
В компании использовали rebase, история коммитов была линейной, и поиск по ней доставлял Антону одно удовольствие.
— Ага, нашел. Ну конечно: в коде написано «2*3=5», ещё бы оно работало с этим бредом! Какой @#$%^ это написал?
Читать полностью »
В последних двух выпусках Радио-T ведущие пытались обсудить GIT. Евгений (Umputun) задавался вопросом зачем нужен rebase и очень удивился, когда я спросил, редактирует ли он коммиты. На мой взгляд, чтоб понять GIT, достаточно вникнуть в процесс разработки Linux Kernel, т к создавался он именно для этого.
Читать полностью »
В процессе перехода с SVN на Git мы столкнулись с необходимостью переписывания наших внутренних инструментов, связанных с развёртыванием кода, которые ориентировались на существование линейной истории правок (и разработку в trunk). На Хабре уже публиковались возможные решения этой проблемы через Git-SVN, но мы пошли другим путём. Нам нужна поддержка таких возможностей Git, как branching и merge, поэтому мы решили разобраться в основах, как же работает Git и каким способом должна осуществляться интеграция с ним.
Читать полностью »
Я долгое время думал, что написать сортировку массива слиянием так, чтобы она не использовала дополнительной памяти, но чтобы время работы оставалось равным O(N*log(N)), невозможно. Поэтому, когда karlicos поделился ссылкой на описание такого алгоритма, меня это заинтересовало. Поиск по сети показал, что про алгоритм люди знают, но никто им особо не интересуется, его считают сложным и малоэффективным. Хотя, может быть, они имеют в виду какую-то «стабильную» версию этого алгоритма, но нестабильная при этом все равно никому не нужна.
Но я все-таки решил попробовать.
Слияние за линейное время
Идея алгоритма довольноЧитать полностью »