CPython убежал на GitHub

Чтобы всех отыскать, воедино созвать
И единою чёрною волей сковать.

Мекка велосипедистов,
Причастность к великому.
Нажал на одну кнопочку -
и вот оно, импортозамещение.

По личному опыту скажу, что с SVN-а мне было проще переползти на mercurial. А вот уже после него и на git перебрался (сразу было сложно почему-то). Обратно, кстати, на hg никакими коврижками мну не заманишь ;)

Правда, я таки не признаю мержкоммиты. Ну и разрабы питона тоже судя по всему (они, правда, даже rebased забанили - ну это уж по желанию - мне в последнее время лень):

It should also be mentioned that we are doing squash commits and not rebased commits or merge commits as some projects on GitHub do. This basically means we will continue to have a single contribution lead to a single commit, keeping our history linear and compact.

Так намного проще работать, а гит позволяет это всё организовать.

It should also be mentioned that we are doing squash commits

Кстати, никогда не понимал этой тупости.

Родина им дала ветки - форкай, пользуйся! Не хотим, хотим жрать говно.

Для тру: ссылка

Ты вообще знаешь, кто такие Ъ?

Довольно странный ход, ведь Python это как бы оплот hg. Надеюсь, Mozilla и SDL так не сделают.

А где вы увидели отказ от веток?? Ветвится только в путь. Но в мастера (и в production) вливается именно что со squash или rebase-ом. Мерж - нахрен. Ну это в моей песочнице такие порядки (линейную историю как-то легче воспринимаю, что важно при поиске проблем и разборе истории - в том числе и с использованием bisect). Вы в вашей делайте, что хотите :)

Кстати, код ревью намного проще проводить сделав именно squash nocommit. Вы извините, что мы тут без gerrit-ов и gitlab-ов живем, в консольке...

Обратно, кстати, на hg никакими коврижками мну не заманишь ;)

Это называется sunk cost fallacy.

Так намного проще работать, а гит позволяет это всё организовать.

Mercurial тоже. Думаю, даже SVN это позволяет.

Кстати, код ревью намного проще проводить сделав именно squash nocommit.

Ты поехавший абсолютно, парень. Проще, когда всё свалено в кучу, чем когда аккуратно разделено на независимые части?

Был в нашей синагоге один любитель коммитить одну большую «sqhash»-какаху в конце дня. «bugfixes, new features added, MANY other changes». Это не ты, случайно?

Жаль, что не на GitLab.

Postmortem of database outage of January 31

Потом что дали им GitLab CE, ставь на свой хост и пользуйся - не хотим, хотим колхоз, большого брата и все яйца в одну мошонку.

Конечно. В этом-то вся ирония. =)

Я в курсе. Я даже застал это в прямом эфире.
Поэтому ничего критичного не держу на сторонних серверах.

Ой, как быстро вы мне поставили диагноз. Да ещё и оскорблять начали. Нехорошо.

Вообще-то squash делается не для «bugfix чего-то там + новая фича + хрень №10 + полная лажа.» А по отдельным задачам - чтобы слить историю реализации ОДНОЙ фичи в один коммит. Звиняйте. Я думал, что это «по-умолчанию» у всех нормальных.

Так что это у вас «всё свалено в одну кучу» (г..но?). :)

Нет, я в другой области работаю - программистом, а не золотарем :)

Ну и в синагогах ваших тож не был.

Это называется sunk cost fallacy.

А если перешёл с git на mercurial и не хочет обратно, это как называется?

А по отдельным задачам - чтобы слить историю реализации ОДНОЙ фичи в один коммит

Можно же пойти ещё дальше: слить историю реализации ОДНОГО проекта в один коммит. Тогда и VCS не понадобится. Когда-то было «по умолчанию» у всех «нормальных».

Нет, я в другой области работаю - программистом, а не золотарем :)

Don't call them developers. Monkeys. (c) Какой ты программист, если не осознаёшь, что squash - необратимая потеря информации. Слить коммиты в один дифф для просмотра можно в любой момент, если уж хочется одну большую кучу. В отличие от обратной операции. Но, видимо, это слишком сложно для кого-то.

Просветление.

Можно же пойти ещё дальше: слить историю реализации ОДНОГО проекта в один коммит. Тогда и VCS не понадобится. Когда-то было «по умолчанию» у всех «нормальных».

Да идите уже куда хотите :) Зачем вам мой текст подменять своим? Я уже даже написал что и как надо squash-ить.

У меня git не ради наличия git-а или сохранения каждого чиха каждого разработчика, а для решения вполне конкретных задач.

Какой ты программист, если не осознаёшь, что squash - необратимая потеря информации.

Мне в истории проекта не важно, в какой последовательности устранялась бага и какие варианты были испробованы (попробуем тут if-чик, не помогло, давай здесь ретурн воткнем и т.п.) - важно конечное решение. Разработческие ветки мы не чистим в течении квартала или полугода - если вдруг понадобится (а пока ни разу не понадобилось) - всю эту «архиважнуюисториюипутьсокамозгапрограммиста» можно достать оттуда.

А Вам я искренне желаю удачи в поиске коммита, который добавил ошибку (нетривиальную). Когда именно на этот функционал нет автотеста, когда у вас 7 человек в режиме нонстоп фигачат код (и коммитятся в среднем каждые полчаса а может и сильно чаще) и когда прошло чуть больше месяца. И проект на скриптовом языке (это так - «вишенка на торте»), если вы понимаете, о чем я.

А программист я обычный. squash-у в том числе и свои коммиты. Видимо, просто не оправдал ваших надежд. :)

Мне в истории проекта не важно, в какой последовательности устранялась бага и какие варианты были испробованы (попробуем тут if-чик, не помогло, давай здесь ретурн воткнем и т.п.) - важно конечное решение.

А вы что, всё это фиксируете в истории? Хм. Когда ты пользовался mercurial - ты о mq или obsolete вообще слышал?

Я тут не один код пишу. Или вы предлагаете мне регламентировать что, как и когда человек должен коммитить в гите в свою локальную ветку??? И таки да - некоторые делают коммиты столь часто, что я подозреваю, что он у них в кронтабе прописан. Или на Ctrl+S забинден.

Про mq obsolete не слышал. Я вообще mercurial плохо изучил - тогда и небо было голубее, и трава зеленее, и задачи другие стояли. Думаю, что он по сравнению с гитом - это те же яйца, только в профиль. Ну и некоторые ньюансы могут быть, связанные с реализацией и структурой хранения. Сейчас всё, что мне нужно, решает git.

Или вы предлагаете мне регламентировать что, как и когда человек должен коммитить в гите в свою локальную ветку???

Не совсем так. Завершенная работа, которая пушится в общий репозиторий, должна быть разбита на относительно независимые части, которые легче ревьюить и которые переводят систему из одного стабильного состояния в другое. При использовании mq (и аналогичных расширений git) и evolve частота коммитов не играет роли.

И таки да - некоторые делают коммиты столь часто, что я подозреваю, что он у них в кронтабе прописан. Или на Ctrl+S забинден.

И в результате получаются сотни мелких коммитов? Тогда конечно, не имеет смысла хранить этот мусор.

Про mq obsolete не слышал

Это две разных сущности: https://www.mercurial-scm.org/wiki/MqTutorial и https://www.mercurial-scm.org/wiki/EvolveExtension

И таки да - некоторые делают коммиты столь часто, что я подозреваю, что он у них в кронтабе прописан. Или на Ctrl+S забинден.

Лол, а комментарии к коммитам у вас не пишутся?

Не совсем так. Завершенная работа, которая пушится в общий репозиторий, должна быть разбита на относительно независимые части, которые легче ревьюить и которые переводят систему из одного стабильного состояния в другое.

Ну вот у нас примерно так и делается - если там пара-тройка коммитов, которые разделены специально - их сливать не будут. Речь идет о коммитах вроде «#1315 Херачу код - в процессе...».

При использовании mq (и аналогичных расширений git) и evolve частота коммитов не играет роли.

Нормальные разработчики сами перед окончанием работ делают коммиты «нормальными» - (через тот же rebase -i это занимает у них пару минут). Но, как говорится, «не только лишь все» ;)

Я предпочитаю, что порядок был уже на уровне хранения, т.к. работаю с гитом большей частью в консоли и, признаться, расширения разные не изучал. Спасибо за наводку - посмотрю, что есть аналогичного в гите (именно консольного).

Это две разных сущности: https://www.mercurial-scm.org/wiki/MqTutorial и https://www.mercurial-scm.org/wiki/EvolveExtension

Сорри, запятую случайно пропустил. С mercurial работал давно - тогда мы столько кода не ревьюили (короткие проекты, мало legacy).

Ну всё, ждём на github firefox, nginx и sdl.

А они разве не там?

Ну для начала они в hg, так что если и там, то это зеркала куда pull не заслать.

Нет. Там только их read-only official/unofficial mirrors.

// fatmode: on
Пора смириться уже - git куда мощнее меркуриала.
// farmode: off

В отличие от обратной операции.

В чем проблема? Я в локальной ветке могу спокойно:
- слить нужные коммиты в один
- разобрать большой коммит на мелкие части (и потом чере-пикнуть нужное в другую ветку/фичу)
- поменять коммиты местами

Behold the power of interactive rebase!

Например, бывает так, что в процессе работы появляются quick-fix'ы некоторых мелких багов - тупо черепикаешь их в отделькую ветку, пихаешь в геррит и потом в мастер. Когда коммит в мастере, можно смело выкинуть из своей ветки фикс и ребейзнуть ветку на актуальное состояние мастера.

Ещё один досвидос mercurial'у.

Всё давно к этому шло, они заранее об этом предупредили. К сожалению, github всех подсадил на git, а жаль.

Там интерфейс удобнее.

Хз, хз...

Допуостим, в исходной ветке были коммиты:

- Move face detection code to detect_faces()

- Optimize memory usage in detect_faces()

- Use multi-scale pyramid in detect_faces()

И т. д. Один коммит - одно независимое атомарное изменение. Ты взял и схреначил всё это в одну кучу. Как ты будешь это разделять это твоим интерактивным rebase? У тебя было много маленьких hunk-ов, ты их слепил в один большой: в одном месте удалилось много кода, в другом месте прибавилось много совсем другого кода. Давай, разделяй, чем бы дитя не тешилось, не работать же. А особенно удобно бисектить потом твою большую какаху. Бисект, натурально, говорит: «баг - в твоей большой какахе». Нет дерьма, Шерлок. Дальше что?

Сегодня я узнал, что Python освободился от гнёта GPL двадцать два с хвостиком года назад: https://github.com/python/cpython/commit/b85ae1aa65ff03413f35c40fb0082523032d...

Как же быстро на Github'е стал blame работать. Раньше blame через веб-интерфейс был занятием для экстремально терпеливых. А теперь быстренько так.

- Move face detection code to detect_faces()
- Optimize memory usage in detect_faces()
- Use multi-scale pyramid in detect_faces()

- Refactor and optimize face detection.

Никого не волуют мелкие изменения и технические особенности реализации. Зачем вообще комментировать что куда и зачем и почему перенесено? Это как комментировать в коде:

// create int variable and set to 0
int i = 0;

Один коммит - одно независимое атомарное изменение.

Один коммит - одна небольшая ограниченная тема (1-2 дня работы максимум).

Как ты будешь это разделять это твоим интерактивным rebase?

edit и руками нужное закоммитить.

А особенно удобно бисектить

При нормальной организации работы даже бисектить ничего не надо - все коммиты тематически рассортированы и ограничены. Сломалась подсистема X - смотришь, какие коммиты ее затрагивали.

А ведь ты тупой однако. Сейчас бить буду.

Один коммит - одна небольшая ограниченная тема (1-2 дня работы максимум).

Ох лол. Ну давай, позорься. Такими темпами щас выяснится, что ты и git commit -am «daily commit» практикуешь.

edit и руками нужное закоммитить.

Как ты руками нужное закоммитишь, чучело, когда в диффе больше нет отдельных изменений? Ты там видишь, что из файла A был удалён один большой кусок в 150 строк, а в файл B добавился совершенно другой кусок в 148 строк. Что ты собрался отдельно закоммичивать?

При нормальной организации работы даже бисектить ничего не надо - все коммиты тематически рассортированы и ограничены. Сломалась подсистема X - смотришь, какие коммиты ее затрагивали.

Подсистему X затрагивал здоровенный коммит размером в «1-2 дня работы». Где конкретно в нём баг? Неудивительно, что тебе бисект не нужен, чучело - он рассчитан на человека разумного, а не на обезьяну с клавиатурой.

ты тупой
чучело

С будлом вроде тебя серьезно дискутировать бесполезно => в игнор.

Ой, всё.

Ты так и не понял зачем это делается. Вот есть задача что-нибудь заимплементить или пофиксить. При этом по умолчанию считается, что задача уже тривиальна ровно настолько, что нет смысла разбивать ее на подзадачи. Программист в отдельной ветке пишет код, отправляет на ревью и вносит правки в соответствии с комментариями коллег. Последние два шага повторяются до тех пор, пока все не будут довольны качеством кода и, собственно, решения. В конце все 20 (или сколько там) коммитов этой ветки сквошатся в один «Заимплементил Х» или «Пофиксил Y» и отправляются мерж реквестом. Смысл в том, чтобы не устраивать свинарник вида http://engineering.adslot.com/assets/branch-madness.png Одна задача – один коммит.

Вам уже десяток причин назвали, почему так делать не нужно, а вы кроме своей песенки ничего не знаете: одна задача - один коммит. Один народ, один Линус, один гитхаб.

Смысл в том, чтобы не устраивать свинарник вида http://engineering.adslot.com/assets/branch-madness.png

И зачем для этого сливать всё в один коммит? Что мешает сделать ребейз? Что мешает включить голову и перестать беспорядочно мёржиться между собой, как кролики? Мёржься с мастером, и всё у тебя будет хорошо. Если есть мусорные коммиты типа «fix a typo» - надо сделать интерактивный ребейз (или mq в меркуриале) и влить их куда надо. Чтобы в конце получилась серия независимых атомарных изменений, переводящих код из одного стабильного состояния в другое. Это, как бы, Основная Идея VCS. Но, наверно, это для кого-то слишком сложно.

В конце все 20 (или сколько там) коммитов этой ветки сквошатся в один «Заимплементил Х» или «Пофиксил Y» и отправляются мерж реквестом.

Вот и выросло поколение. А во времена мейл-листов всем было очевидно, что надо свои изменения посылать в виде серии патчей, где каждый патч - одно независимое изменение. Но, наверно, от нынешних детей с дефицитом внимания я слишком многого хочу.

Чтобы в конце получилась серия независимых атомарных изменений, переводящих код из одного стабильного состояния в другое.

Для меня в понятие атомарности уже входит требование сохранения стабильного состояния. Если таких коммитов по-прежнему несколько, то нужно под них заводить отдельные таски с отдельными код-ревью, QA и, в ряде случаев, A/B тестом. Как видишь, сколько людей, столько и мнений, это нормально.

Неугомонный попался...

Ты же никого не слушаешь и не слышишь. Херли тебе что-то объяснять и доказывать? Одно непонятно - почему под своим ником пишешь, а не под анунимусом?

Тут так вышло, что всем кроме одного пользователя (зато очень упорного в своём невежестве), всё понятно и очевидно... :)

Обычно логическая противоречивость и незавершённость вызывают живой интерес и привлечение новых сил и энергий. Обратное не особо. Делайте выводы.

Для меня в понятие атомарности уже входит требование сохранения стабильного состояния. Если таких коммитов по-прежнему несколько, то нужно под них заводить отдельные таски с отдельными код-ревью, QA и, в ряде случаев, A/B тестом. Как видишь, сколько людей, столько и мнений, это нормально.

А целую ветку послать на ревью мама не разрешает?

Невѣждъ надобно учить.

Кому надобно :) ? Лично мне с твоих «проблем со слухом» (точнее с пониманием собеседника) ни холодно, ни жарко.

Как же тебя понимать, если ты ни на один аргумент по существу не ответил.

Логическая противоречивость чего?

Логическая противоречивость чего?

Git, Linux, X.org, Android, iPhone, ZX-Spectrum, СССР, IBM PC...