Завершён перевод книги «Pro Git»

Кто тебе такую чушь сказал? Я онлайн версию на nokia 5130 открыл.

Это везде так - в SVN, hg, git. Но пойнт в том, что достаточно легко намеренно внести ошибку, которая не бросается в глаза, но является, например, бэкдором.

в mercurial ВСЕ комменты подписаны, и имеют свою сигнатуру. В гите, насколько я знаю, тоже. Если у вас какие-то проблемы с сотрудниками, например вы боитесь, что что-то закоммитит уборщица - используйте ssh вместе с пассфразой, или подписывайте свои комменты своим ключом. Тогда коммент уборщицы просто не будет принят. Если вас это не волнует - откройте всё и всем. Гит, насколько я знаю, такое тоже допускает.

О краже исходников я даже не говорю.

можно подумать, что украсть их «из папки» будет сложнее.

в mercurial ВСЕ комменты подписаны, и имеют свою сигнатуру. В гите, насколько я знаю, тоже.

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

можно подумать, что украсть их «из папки» будет сложнее.

Не будет ни сложнее, ни проще. Так что волноваться по поводу дыр в безопасности svnserve я бы не стал.

Могут быть подписаны, могут не быть, то же и в Git.

можно поставить Win и писать программы в блокноте на VisualBasic.

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

я проверю все его правки. А ты будешь просматривать ВЕСЬ код.

Могут быть подписаны, могут не быть, то же и в Git.

можно поставить Win и писать программы в блокноте на VisualBasic.

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

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

я проверю все его правки.

И откуда ты знаешь, что в продукте бэкдор, а не ошибка? Откуда ты знаешь, что нужно проверять правки именно человека X?

А ты будешь просматривать ВЕСЬ код.

Ты тоже.

VCS уже 40 лет. Набор их команд не сильно менялся со времен RCS (CVS, SVN).

ну да, конечно. Особенно в svn он сильно не менялся, самая прямо таки 'классическая' vcs.

Особенно в svn он сильно не менялся, самая прямо таки 'классическая' vcs.

В общем, да. Сделана 10 лет назад, при проектировании особое внимание уделялось совместимости с существующей CVS.

А то, что все DVCS, кроме Git, по набору команд похожи между собой, как бы намекает нам - при разработке Git понтам уделялось особое внимание.

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

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

И откуда ты знаешь, что в продукте бэкдор, а не ошибка? Откуда ты знаешь, что нужно проверять правки именно человека X?

об этом мне сказал ты:

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

Ты тоже.

если _твоё_ условие верно, то весь код просматривать нет необходимости - крыса-кун вычислен, и достаточно проверить только его правки.

Важно сколько человек его могут изменять. Если всего один - очевидно подпись не нужна. А если более одного - очевидно нужна.

А ты конкретно расскажи, зачем именно она нужна в закрытом проекте, разработчики которого сидят на одном этаже (или в одной комнате).

если _твоё_ условие верно, то весь код просматривать нет необходимости - крыса-кун вычислен

Я _всего лишь_ сказал, что крыса-кун внес бэкдор и уволился. Никто не знает, что есть бэкдор и никто не знает, кто его внес.

Он либо с msdn подпиской

Виндовые конторы очень часто ее имеют.

А ты конкретно расскажи, зачем именно она нужна в закрытом проекте, разработчики которого сидят на одном этаже (или в одной комнате).

очевидно для того, что-бы знать, КТО и ЧТО внёс.

Я _всего лишь_ сказал, что крыса-кун внес бэкдор и уволился. Никто не знает, что есть бэкдор и никто не знает, кто его внес.

так тебе известно, что есть бэкдор? да/нет?

если нет, то о чём вообще говорить-то? может его и нет вовсе? причём тут VCS? VCS поможет лишь в том случае, если ты кого-то выпер обиженного, и этот кто-то мог-бы оказаться крысой-куном. Ты можешь проверить все его правки. Ну а если ты ничего не знаешь, то тебе в помощь маги и экстрасенсы.

Если - да, то VCS тебе окажет неоценимую помощь, в вычислении крысы-куна.

очевидно для того, что-бы знать, КТО и ЧТО внёс.

И чем это лучше простого указания имени пользователя? Только не нужно про «сигнатура верифицирует!!11» - крыса-кун мог украсть чужой ключ.

Я _всего лишь_ сказал, что крыса-кун внес бэкдор и уволился. Никто не знает, что есть бэкдор и никто не знает, кто его внес.

так тебе известно, что есть бэкдор? да/нет?

Кхм.

tailgunner> откуда ты знаешь, что в продукте бэкдор, а не ошибка?

tailgunner> Никто не знает, что есть бэкдор

т.е. всё, что ты знаешь - это «что-то идет не так». И тебе придется проверять весь код.

может его и нет вовсе?

Может быть. Но ты этого не знаешь и... см. выше.

Если - да, то VCS тебе окажет неоценимую помощь, в вычислении крысы-куна.

Как я уже сказал, он мог украсть ключ. Кроме того, скажи мне - что ты сделаешь, после того, как вычислишь крысу-куна - уволишь его? Даже если он уже? %)

Вот я пришёл к Git из SVN. За полчаса настроил Git и завёл проект на GitHub, ничего сверхсложного. Вести работу в стиле SVN смог сразу же, в стиле Git - уже через неделю, да.

И чем это лучше простого указания имени пользователя? Только не нужно про «сигнатура верифицирует!!11» - крыса-кун мог украсть чужой ключ.

не говори - подходит крыса-кун к другу: «скопируй мне свой ключ на эту флешку, и запиши пассфразу на эту бумажку». «Зачем?» «Меня завтра уволят, хочу бекдор от твоего имени запостить!».

т.е. всё, что ты знаешь - это «что-то идет не так». И тебе придется проверять весь код.

ты не от мира сего - где ты видел проекты, в которых «всё идёт так, как надо»?

Как я уже сказал, он мог украсть ключ.

ну давай ещё паспорта и удостоверения отменим... И да, регистрацию на LORе тоже (:

Кроме того, скажи мне - что ты сделаешь, после того, как вычислишь крысу-куна - уволишь его? Даже если он уже? %)

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

подходит крыса-кун к другу: «скопируй мне свой ключ на эту флешку, и запиши пассфразу на эту бумажку»

Хорошо быть тобой - всё всегда идет как надо.

т.е. всё, что ты знаешь - это «что-то идет не так». И тебе придется проверять весь код.

ты не от мира сего - где ты видел проекты, в которых «всё идёт так, как надо»?

У тебя в голове говорят какие-то голоса.

Кроме того, скажи мне - что ты сделаешь, после того, как вычислишь крысу-куна - уволишь его? Даже если он уже? %)

скорее всего - нет. отклоню бекдор под надуманным предлогом

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

Ну да ладно... веришь ты, что подпись каждого коммита дает какие-то выгоды - верь дальше.

Особенно в svn он сильно не менялся, самая прямо таки 'классическая' vcs.

В общем, да. Сделана 10 лет назад, при проектировании особое внимание уделялось совместимости с существующей CVS.

Самому не стыдно такую херню писать? Может быть при проектировании svn хотели так сделать, но не сделали. Во времена перехода с cvs на svn стояло точно такое же нытьё людей привычек на счёт «не таких команд» и непривычной работы с репами.

А то, что все DVCS, кроме Git, по набору команд похожи между собой, как бы намекает нам - при разработке Git понтам уделялось особое внимание.

Похожи между собой ровно на столько, на сколько с каждым из них похож git. Наверное, это трудно понять человеку, который считает svn классической vcs и совместимой с cvs.

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

А ревью кода вы вообще не делает? т.е. все пушу, что хотят и как хотя лишь бы работало так?

ты не от мира сего - где ты видел проекты, в которых «всё идёт так, как надо»?

У тебя в голове говорят какие-то голоса.

ты не ответил на прямой вопрос.

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

ещё я могу откатить этот бекдор из кода. Этого мало?

А ревью кода вы вообще не делает?

Мы стараемся.

все пушу, что хотят и как хотя лишь бы работало так?

Кхм. А подписанность коммита точно улучшает качество кода?

ты не ответил на прямой вопрос.

Нет смысла отвечать на очевидные вопросы.

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

ещё я могу откатить этот бекдор из кода. Этого мало?

Наличие сигнатуры это никак не облегчает.

Во времена перехода с cvs на svn стояло точно такое же нытьё людей привычек на счёт «не таких команд» и непривычной работы с репами.

Набор команд SVN отличался от набора команд CVS ровно настолько, насколько нижележащая модель SVN отличается от модели CVS. Набор команд Git отличается от набора команд любой другой CVS на величину понтов Линуса.

Похожи между собой ровно на столько, на сколько с каждым из них похож git.

Что значит «похож на Git»? Любая современная DVCS - это распределенный граф ревизий; граф ревизий, связанный криптохешами - это и OpenCM, и Monotone, и Git (который изначально делался под влиянием Monotone), и Mercurial. DVCS на криптохешах отличаются между собой меньше, чем SVN от CVS.

s/другой CVS/другой DVCS/

подписанность коммита точно улучшает качество кода?

Разве что оочень косвенно — если добавляющий каку коммит подписан твоей ЭЦП, то уже не отмажешься, что, мол, это кто-то другой тебя подставить хочет, написав в качестве автора коммита твоё имя.

подписанность коммита точно улучшает качество кода?

Разве что оочень косвенно

А по-моему вообще никак.

Все эти книги, конечно, хороши и полезны. Ни чаще всего на практике возникает необходимость просто начать и работать с Git, не читая до этого 150-1000 страниц. И тут на помощь приходит такой вот замечательный книго-мануал gitmagic. Конечно, он не даст вам 100% понинимания ВСЕГО, что может Git, но для работы хватит с головой.

Можно скорректировать вариант fb2? А то в том, который выложен сейчас, не только оглавления нет, но и примеры кода все в одну строчку слиты.

сочувствую

Кхм. А подписанность коммита точно улучшает качество кода?

Нет смысла отвечать на очевидные вопросы.

ещё я могу откатить этот бекдор из кода. Этого мало?

Наличие сигнатуры это никак не облегчает.

а наличие истории?

Отличная новость - отличная книжка! Да Git не совсем прост, но нужно потратить всего пару дней на изучение!

Кому совсем сложно и в голове не помещаются все команды, а записывать на бумажку лень, рекомендую bazaar - очень простая система («один каталог - одна ветка», потому команд и их опций в 3 раза меньше). Освоите, а там и до Git'а руки дойдут.

Hg(Mercurial) - тоже ничего так, что-то среднее между Git и Bazaar. Почти такой же сложный как Git и почти такой же «не популярный» как bazaar.

А вот SVN - барахло, присоединяюсь.

> А ревью кода вы вообще не делает?
Мы стараемся.

Тогда ситуация с бэкдор вообще мало вероятна.

А подписанность коммита точно улучшает качество кода?

Качество кода конечно не зависит от месседжа в коммите, но на качество работы влияет. При правильной политике ведения подписей в коммитах работать в команде становиться на много приятней.

При правильной политике ведения подписей в коммитах работать в команде становиться на много приятней.

Хм, интересно. То есть криптографически подписанный коммит в среднем качественнее, чем коммит, подписанный просто именем пользователя?

Виндовые конторы очень часто ее имеют.

У меня в конторе 2010 Professional без подписки(коробка) и я пользуюсь svn, git для меня как для разрабатывающего в одиночку был бы странным решением. А так в конце рабочего дня правой кнопкой по дереву проектов - commit и все норм. Все проекты в виде папок в одном репо на смонтированном серверном диске.

полезная книга
Pro Git

Ну и да, реквизиты в теле новости - это сильно.

git для меня как для разрабатывающего в одиночку был бы странным решением

Использование VCS вообще никак не связано с коллективной разработкой.

А так в конце рабочего дня правой кнопкой по дереву проектов - commit и все норм

Бгг.

В качестве замечания.

В fb2 версии сбито форматирование для текста, описывающего командную строку. Все слитно без переводов строки. Разобраться достаточно сложно.

И есть подозрение что в fb2 версии сбито форматирование глав. Т.е., насколько я понял, нормальных глав там просто нет.

А вообще - спасибо за книжку. Даже с учетом неудобств, связанных с неправильным форматированием. Я только из нее понял особенности работы add в git. :) Помню как я удивлялся когда его пробовал по аналогии с svn что изменения не уходят в коммит. :)

это конечно очень хорошо, но английский нужно знать по дефолту тем, кто юзает гит

и что-же вы там такое пишете?

да есть софтины, точим... сырцов много, собирается все это дело несколько часов (если с нуля)...

сейчас все это крутится под svn (на серваке, размер базы не знаю, но подозреваю что за 4 года там базука разрослась на много гигов)

потребность отзеркаливать всю репу локально несказанно огорчает... svn в плане работы с бранчами нервно курит в сторонке даже по сравнению с cvs...

А разработчики и не должны по несколько раз на дню создавать проекты.

Hg(Mercurial) - тоже ничего так, что-то среднее между Git и Bazaar. Почти такой же сложный как Git и почти такой же «не популярный» как bazaar.

hg не сложный. Достаточно понять основную идею.

Хм, интересно. То есть криптографически подписанный коммит в среднем качественнее, чем коммит, подписанный просто именем пользователя?

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

А если подпись криптостойкая, то быдлокодер не сможет съехать, на тему «мопед не мой».

git для меня как для разрабатывающего в одиночку был бы странным решением.

вы многое теряете. впрочем - каждый ССЗБ.

сейчас все это крутится под svn (на серваке, размер базы не знаю, но подозреваю что за 4 года там базука разрослась на много гигов)

размер истории редко превышает размер исходников более чем на порядок. Ну НЕ МОГЛИ вы столько написать. В принципе. Попробуйте - скорее всего получится в 2..3 раза больше, чем исходники.

потребность отзеркаливать всю репу локально несказанно огорчает... svn в плане работы с бранчами нервно курит в сторонке даже по сравнению с cvs...

дык всего один раз надо отзеркалить эти 2..3Гб. Разве это так долго, даже на 100Мбпс? Затем вытягиваются/пушаться лишь изменения, что происходит мгновенно. Во всяком случае, в hg так. В гите с такими репами вроде были проблемы, но их ЕМНИП решили (а тож, ядро Линуса тоже не маленькое, и ничего, работают)

в конце рабочего дня правой кнопкой по дереву проектов - commit и все норм.

Круто.

use gpl or die =)

никак нет, просто грусно читать такие утверждения от «программиста»

инвертированный мир такой инвертированный.

для того чтобы создать нового пользователя на сервере git надо сгенерировать открытый ключ, запихнуть его через ssh на сервер каждому! проекту.

незнание технологий не значит, что у них действительно есть этот минус.

gitorious раскатайте, делов то

Это везде так - в SVN, hg, git. Но пойнт в том, что достаточно легко намеренно внести ошибку, которая не бросается в глаза, но является, например, бэкдором. О краже исходников я даже не говорю.

рецепт с объяснением почему в других SCM это сложнее можно?