1. PHP / Говнокод #12528

    +49

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    switch ( ! empty($rules['last_online']) )
    {
    			case '3days':
    				$where .= " AND last_online > NOW() - INTERVAL '3 DAYS' ";
    			break;
    
    			case 'week':
    				$where .= " AND last_online > NOW() - INTERVAL '7 DAYS' ";
    			break;
    
    			case 'month':
    				$where .= " AND last_online > NOW() - INTERVAL '1 MONTH' ";
    			break;
    }

    Внезапно сломался фильтр .... И такое найти можно. Впервые подобное вижу

    Запостил: nobody, 01 Февраля 2013

    Комментарии (74) RSS

    • То есть, раньше он работал что ли?
      Ответить
    • Это правило появилось при merge двух веток, от куда взялось не понятно, не там не там этого не было
      Ответить
      • При слиянии двух веток репозитория на большой скорости в результате столкновения частиц кода происходит взрыв, сопровождающийся выделением значительного количества энергии и возникновением новых частиц. В данном случае мы наблюдаем возникновение тяжелой частицы "switch". Ядро частицы состоит из трех пар частиц "case"/"break", связанных прочной кейс-брейковой связью.
        Ответить
        • Гитонный коллайдер?
          Ответить
          • В git проблем со слиянием не наблюдал. Если бы был конфликт - остались бы вмятины маркеры конфликта. Скорее всего это какой-то самопальный шайтан-VCS-коллайдер с педальным мерджем. Шибче педалишь - шибче мерджит.
            Ответить
            • Гит очень безалаберная программа, и "интересных" случайностей в ней случается - хоть отбавляй. Просто об этом никто не знает, т.как баг-треккера нет. Но в этом легко убедиться, если прийти к разработчикам с настоящим багом, особенно связанным с безопасностью, и обнаружить, что и через два года его никто не исправил. Я охотно поверю, что она не только может плохо автоматически мердж сделать, а даже в то, что она сама пхп код вставит в ваши исходники. Хотя код выше не выглядит как результат плохой работы сорц-контроля, но это уже второстепенно.
              Ответить
            • Да, чтобы не быть голословным: у меня при коммите в два репозитория Гит игнорировал логин/пароль от второго и посылал логин/пароль от первого. Я даже зарегистрировался когда-то в их подписке ради того, чтобы сообщить. Но, как бы Гит как посылал кому ни попадя пароли пользователей, так это и продолжает делать.
              Ответить
              • Это могло быть кеширование SSH-клиента (оба репозитория были на одном сервере, не так ли?). Собственно говоря, у репозиториев git нет паролей и аутентификации как таковой, и никаких паролей git никуда не посылает. Пароль может стоять только на SSH-доступ или в специальной надстройке для аутентификации вроде gitosis (что, собственно, опять сводится к SSH-доступу).

                Вместо баг-трекера у разработчиков есть mailing-list: http://news.gmane.org/gmane.comp.version-control.git/ - я тоже предпочитаю баг-трекеры, но в git слишком мало багов, чтобы об этом беспокоиться.
                Ответить
                • Нет, там вообще никакой SSH ни при чем. Это тупо неправильно работающая функция в Гите. Я ее даже нашел и мог бы поправить. Но нафиг нужно.

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

                  Это абсолютно не важно на каком сервере репозитории. Гит просто даже никогда не пытается прочитать логин/пароль второй раз, не важно куда коммитить. Это как раз таки можно настроить на уровне .netrc например, или там, например, в раутер зашить :) чтобы наверняка, но Гит сам по себе тупо игнорирует такие настройки.
                  Ответить
                  • Х.з. у меня в ~/.ssh/config прописаны ssh ключики для трех серверов - гитхаб, битбакет и внутрикорпоративный гитолайт. Добавляю к проекту ремоут с правильным хостом в духе git@internal:/test - и ... все работает. Даже если добавить два ремоута на разные сервера в один проект. Насчет паролей х.з., никогда не юзал их, видимо авторы гита тоже пользуются только ключами, поэтому и игнорируют баг.
                    Ответить
                  • Насчет паролей - сейчас провел вот такой эксперимент: создал файлик git-ssh.sh следующего содержания:
                    echo "Starting SSH, arguments: $*" >&2
                    strace ssh $*
                    echo "SSH done" >&2
                    Выставил переменную окружения GIT_SSH=./git-ssh.sh, добавил в репу тестовый ремоут:
                    git remote add test bormand@localhost:/tmp/2
                    После чего запустил git push test master и поглядел на выхлоп:
                    write(5, "bormand@localhost's password: "
                    И кто же тут спрашивает пароль, гит или ssh? ;)
                    Ответить
                  • > но Гит сам по себе тупо игнорирует такие настройки
                    Забыл дописать, что git push (при использовании ssh протокола) тупо вызывает ssh (или то, что прописано в переменной окружения GIT_SSH) с параметрами:
                    ssh bormand@localhost git-receive-pack '/tmp/2'
                    Поэтому ни о какой аутентификации со стороны гита, а следовательно и о чтении всяких там конфигов, посвященных аутентификации не может быть и речи.

                    P.P.S. Может быть у вас какой-нибудь гитовый гуй такой фигней с кешированием паролей страдает?
                    Ответить
                    • P.P.P.S. Попробовал и по HTTP с basic-auth, тоже нихрена не кеширует, спрашивает каждый раз.
                      Ответить
                    • А вот походу и тот баг - запилил на одном HTTP сервере две запароленных по basic-auth репы. Включил в гите кеширование HTTP паролей с помощью git config credential.helper cache. Да, на обе репы он пытается юзать один и тот же пароль, т.к. пароль привязывает только к хосту и имени юзера, без пути к репе. С двумя разными хостами багофича не наблюдается.

                      P.S. А есть ли смысл юзать запароленную HTTP/HTTPS репу? Имхо корячить WebDAV ради пуша в нее это намноого большее извращение чем gitolite/gitosis.
                      Ответить
                      • Не то пробовали. Вы вообще сейчас не Гит проверяли... в Гите можно, в его файлах настроек, которые хранятся вместе с репозиторием, указать пароли. Вот тогда и только тогда Гит будет сам логинится. А то, что вы проверяли - это то, как SSH логинится - ну так понятно, что оно работает...
                        Зачем нужно задавать пароли в файлах настроек Гита: предположим, у вас на одном сервере есть репозитории с разными логинами/паролями, тогда настройки SSH не достаточно специфические.
                        Ответить
                        • > в Гите можно, в его файлах настроек, которые хранятся вместе с репозиторием, указать пароли
                          Эм. Не знал о такой возможности. Можно ссылку на ман, где описывается подобная настройка?
                          Ответить
                        • P.S. Юзер один, сервер один, пароли разные... имхо попахивает каким-то извращением. Для чего такая конфигурация, если не секрет?
                          Ответить
                          • а зарплаты две!
                            Ответить
                          • А почему бы и нет? Есть у меня на гуглокоде репозиторий, который мне не стыдно показать, и я его регистрирую на своего пользователя, которого знают другие, и есть репозиторий, в котором, ну я не знаю... я разрабатываю порносайт? ну или что-то такое :) И я не хочу оба репозитория регистрировать на одного пользователя.

                            http://stackoverflow.com/questions/849308/pull-push-from-multiple-remote-locations

                            Вот тут описан механизм, только вместо user@repository используйте user:password@repository схему.
                            Ответить
                            • Для этого придумали закрытые репозитории, бесплатные есть на bitbucket.
                              Ответить
                              • Тоесть вы мне предлагаете решать проблему бажной авторизации в Гите созданием других репозиториев? Тогда уж лучше у себя локально репозиторий держать, и никуда не авторизироваться - всяко надежнее.
                                Ответить
                                • > Есть у меня на гуглокоде репозиторий, который мне не стыдно показать
                                  > и есть репозиторий, в котором, ну я не знаю... я разрабатываю порносайт?
                                  Мы начали с того, что у вас уже два репозитория, и есть желание, чтобы один из них никто не ассоциировал с вами и, желательно, не видел. При чём здесь сомнительные проблемы с разными паролями для одного пользователя на одном и том же хосте?
                                  Ответить
                                  • Нет, смысл в том, что 1 репозиторий = 1 пара логин/пароль. Не надо ничего кроме этого придумывать и доискиваться зачем это нужно. Возможно, значит нужно.
                                    Ответить
                                    • > Нет, смысл в том, что 1 репозиторий = 1 пара логин/пароль
                                      Ну для создания вашей схемы, в том же гитолайте можно сгенерить по ключу на каждую репу, и выставить этому ключу право на доступ только к своей репе.
                                      Ответить
                            • А, а такая ситуация довольно легко разруливается через ~/.ssh/config (если настроена авторизация по ключикам):
                              Host github
                                HostName github.com
                                IdentityFile ~/.ssh/keys/bormand-normal
                              Host github-pron
                                HostName github.com
                                IdentityFile ~/.ssh/keys/bormand-pron
                              Дальше, когда клонируем репу или добавляем ремоут, вместо github.com пишем соответствующий алиас:
                              git clone git@github:/bormand/nanochess
                              git clone git@github-pron:/bormand-pron/pron-downloader
                              И SSH аутентифицируется соответствующим алиасу ключем.
                              Ответить
                              • Вы все еще кипятите используете ssh пароли? Тогда мы идем к вам!
                                Ответить
                              • Я уже говорил в другом месте: в пределах организации, нельзя разрешать такую схему авторизации. В принципе. Какой-нибудь мудак-фрилансер зарегится с публичного компьютера и дальше рассказывать?
                                Ответить
                                • А чем здесь помогут пароли? Какой-нибудь мудак-фрилансер вобьет их на публичном компьютере, дальше рассказывать?
                                  Ответить
                                • А как же ДАО распределённости? Дайте мудакам-фрилансерам отдельный репозиторий как песочничу, пусть они в нём делают свои мудильные фрилансерские патчи. Потом пусть опытный местный гений ревьюит и мёржит патчи во внутренний репозиторий...
                                  Ответить
                                  • > Дайте мудакам-фрилансерам отдельный репозиторий как песочничу
                                    Кстати, в том же гитолайте можно мудаку-фрилансеру поставить R доступ на master и W доступ на их личную ветку. А мерджить самому, заодно просматривая чего они там наворотили. И овцы сыты, и волки целы.
                                    Ответить
                                    • Ох, так мы еще про Гитолайт не вспоминали... так это вообще феерия и буйство красок... но вокруг Гита написано столько дополнений, которые пытаются сделать за него то, что он не умеет делать... кульминацией для меня был случай, когда я через плечо у тестера на экране увидел, как он в Экселе составлял таблицу из гитовских номеров коммитов и привязывал их к номерам коммитов в хронологическом порядке, который он сам составил исходя из бесед с программистами, которые эти коммиты делали. Гит не просто затрудняет отчетность и работу тестеров в целом. Он ее делает во многих случаях бессмысленной. Наверное никто так не ненавидит Гит, как админы и Кю-Эй.
                                      Ответить
                                      • > Экселе составлял таблицу из гитовских номеров коммитов и привязывал их к номерам коммитов в хронологическом порядке
                                        О боже... git describe же. Показывает для коммита версию в виде 1.0-37-g86c283a, где 1.0 - последний тег, навешанный перед текущим коммитом, 37 - количество нетегированных коммитов после того самого тега. 86c283a - кусок айдишки коммита. Чем не хронология?
                                        Ответить
                                      • Непросвещённые люди будут страдать хернёй независимо от используемых инструментов.
                                        Ответить
                                      • Расскажите им про теги. Можно брать теги из баг-трекера и ставить их на коммиты, которые исправляют баг.
                                        Ответить
                                        • И что это меняет? Нужны именно номера версий. Теги нахер не нужны. Для тестeров принципиально необходимо знать, какой код был написан раньше, а какой позже. Иначе их работа становится бессмысленной.
                                          Ответить
                                          • Mercurial имеет псевдо-номера ревизий для коммитов. Если это так важно, возможно, стоит изменить VCS. В гите их нет, т.к. в распределённой гетерогенной среде невозможно сказать, какой коммит был сделан раньше, а какой позже, если коммиты не связаны отношениями parent-child напрямую.
                                            Ответить
                                          • У каждого коммита есть дата. Даже обычный git log умеет вывод в разных форматах, не говоря уже о том, что расширенная отчетность со свистелками как таковая не входит в обязанности VCS.

                                            После ваших примеров мне вспоминается это: "Я стою на асфальте, в лыжи обутый..."
                                            Ответить
                                            • Дата только сбивает с толку, т.как код в репозитори не соответствует датам. Он следует тому, как и когда его туда положили, и чьи (какой версии) изменения были в итоге приняты. Нужны именно версии, в хронологическом порядке.

                                              На практике, не зависимо от размера организации и внутреннего устройства, я никогда не сталкивался ни с реализацией преимуществ распределенной системы версий, ни с распределенной системой версий как таковой. Любая организация, по своей сути является строгой иерархией, не допускающей разногласий в смысле порядка принятия решений, и в том числе связанных с тем, какой код она производит. Я работал в проектах типа САС, использующихся в Бритиш Эирлайнз и в стартапах из 2-3 человек. Нигде и никогда распределенная система версий ничего не улучшила. Иногда запутывала. Т.е. ни одна организация, даже пользуясь Гитом или тем же Меркуриалом не использовала его возможности как распределенной системы. Админы в больших организациях предпочитают централизованные системы т.как ими проще управлять и они занимают вцелом гораздо меньше места (Гит хранит всю историю проекта в каждой копии, в то время как централизованные системы хранят историю в одном центральном месте).

                                              Чтобы лучше обьяснить это, приведу пример из САС-подобного проекта, где все программисты получали от компании ВМ на облаке в серверах компании для работы и клиентский компутер. С точки зрения админа Гит дублировал бы информацию на одном и том же физическом сервере. Т.е. заявленная "надежность" на практике была бы фикцией, только увеличивавшей нагрузку на сеть и требования к обьему носителей информации.
                                              Ответить
                                              • >код в репозитори не соответствует датам

                                                Что это значит?

                                                >Нужны именно версии, в хронологическом порядке

                                                git log выводит в хронологическом в пределах ветки.

                                                >я никогда не сталкивался ни с реализацией преимуществ распределенной системы версий, ни с распределенной системой версий как таковой

                                                Если вы работали с git, то сталкивались с DVCS - у каждого пользователя своя, независимая копия репозитория. Преимущество - отсутствие необходимости в сервере для того, чтобы работать с репозиторием, со всеми вытекающими плюсами. Мой коллега мне рассказывал о трудностях, которые у него возникали с svn, когда он работал удаленно - в тот раз пришлось поднимать наружный сервер.

                                                >Любая организация, по своей сути является строгой иерархией

                                                1. Не любая. Скорее наоборот: строгая иерархия является исключением. Христоматийные примеры организаций без иерархии: valve, 37signals. Бытовые примеры: любая маленькая компания, в которой иерархия весьма условна.
                                                2. Даже если так, это не является аргументом против DVCS

                                                >Нигде и никогда распределенная система версий ничего не улучшила.

                                                А у меня улучшила. Deal with it.

                                                >Иногда запутывала.

                                                Цитата про лыжи выше.

                                                >ни одна организация, даже пользуясь Гитом или тем же Меркуриалом не использовала его возможности как распределенной системы.

                                                Использовала. У каждого пользователя был свой репозиторий. См. выше.

                                                >Админы в больших организациях предпочитают централизованные системы т.как ими проще управлять

                                                Не относящийся к вопросу аргумент. Дело админа - установить и настроить.

                                                >и они занимают вцелом гораздо меньше места

                                                Приведите цифры. По моим данным git гораздо компактнее хранит файлы репозитория.

                                                >Гит хранит всю историю проекта в каждой копии

                                                И это удобно и быстро.

                                                >где все программисты получали от компании ВМ на облаке в серверах компании для работы и клиентский компутер

                                                Это действительно хороший пример, где централизованные VCS имеют преимущество. К сожалению, для большинства компаний это слишком дорогое решение.
                                                Ответить
                                                • На все отвечать нет смысла, т.как вам с амвона с такими списками цитат лучше бы.
                                                  Но про занимаемое место все-таки отвечу, т.как тут fail at reading comprehension. Гит хранит историю вместе с каждым репозиторием в то время как централизованые системы хранят историю только в одном месте. Как бы там Гит экономно ее не хранил, то при наличии более одного репозитория проиграет. А для компании с тысячами программистов это выливается в серьезные суммы. Когда я говорил с девушкой администрирующей билды / репозитори в Хьюлете, то она сказала, что по их подсчетам, им бы только на наш отдел пришлось бы купить еще две машины (т.как сотрудники получали каждый по ВМ для работы, и обьемы кода были такие, что пишлось бы по-другому разбивать дисковое пространство на уже имеющихся машинах, для того, чтобы Гит туда влез). Только над нашим проектом работало больше сотни человек (в нашем отделе - примерно десять). Итог - дешевле было бы купить хорошую систему версий, чем платить за железо для говенной, но бесплатной.
                                                  Ответить
                                                  • У меня есть основания полагать, что купить коммерческую VCS было бы гораздо дороже, чем дополнительные объемы HDD.

                                                    Вот цены на тот же perforce: http://www.perforce.com/purchase/pricing-licensing

                                                    При покупке за $480 на 100 человек имеем одноразовую трату в $48000. Самые дорогие HDD, которые я нашел, обойдутся в 20000 руб/Тб. На $48000 можно купить ~72Тб. В этот объем можно вместить 300-400 ТЫСЯЧ копий довольно больших git-проектов, то есть для исходных 100 человек имеем 3-4 тысячи репозиториев на брата.

                                                    Я не говорю, что из-за этого не стоит выбирать perforce, ведь у него наверняка есть множество преимуществ. Я также не утверждаю, что git - это лучший вариант. Я просто с ним лучше всего знаком.
                                                    Ответить
                                                    • 72 Тб - капля в море. Этого бы может и не хватило на один отдел. Кроме того, прийдется покупать не только диски - их нельзя бесконечно много присоединить к одному компьютеру. Кроме того, у диска его цена в магазине составляет примерно 1-10% от стоимости его использования. Большую часть стоимости составляет плата за электричество.
                                                      Ответить
                  • Гит вообще плевать хотел на управление доступом, он, как и любая годная юниксовая программа, делегирует не связанную с основной деятельностью работу другим, специализированным программам. SSH, например. О паролях он вообще ничего не знает. Ему интересны только юзернеймы и адреса почты коммитера и автора, и к аккаунтам на машинах они практически никакого отношения не имеют и конфигурятся отдельно.
                    Сорцы смотрел как-то ради интереса, никакого криминала не увидел. Обычный промышленный сишный код. Великов много, но это же pure Сишка, там такая библиотека, что свой велопарк приходится писать в любом проекте.
                    Багов за три года работы с git не наблюдал.
                    Ответить
                    • > он, как и любая годная юниксовая программа, делегирует не связанную с основной деятельностью работу другим, специализированным программам
                      Получается что не совсем. Для ssh, да, делегирует. А вот для HTTP/HTTPS он юзает cURL, и с паролями обращается самостоятельно (см. git-credential-cache).

                      > Багов за три года работы с git не наблюдал.
                      Плюсую.

                      P.S. Я видимо багов не наблюдал, т.к. за все время работы с гитом ни разу не пользовался http/https транспортом. Только ssh через гитолайт или ssh на гитхаб\битбакет.
                      Ответить
                      • s/http\/https транспортом/не анонимным http\/https транспортом/
                        Ответить
                    • Опять же неверно, смотри мой ответ выше - да, делает он это, и да делает плохо. Делать он это должен, т.как в том же .netrc нельзя достаточно специфично указать настройки (их нельзя указать для каждого репозитория, можно только для каждого сервера).
                      То, что он "Юниксовая" программа, не помешало им так же встроить вовнутрь свой grep с блекджеком и шлюхами и еще много чего такого.
                      Ответить
                    • Да, я это почему вспомнил... мне сейчас по работе приходится больше администрацией заниматься. Есть древняя база кода, которую всю можно было бы сюда выкладывать, но она просто очень уж избитая + написана на АСП-классик! блять. Я даже не знал, что бывает хуже, чем ПХП... так вот, местным обитателям системы кто-то сделал внушение о том, какой Гит замечательный и вообще весь из себя. Естесственно, когда их спрашиваешь о том, а что кроме Гита они пробовали - так кроме Сабвершна ничего и не пробовали, да и там, кроме обычных апдейт/коммит ничего не делали.

                      Ну вот мне выдали в вотчину какой-то покрывшийся плесенью Центос, на котором нужно соорудить багтрекер + вики + репу + тестовый сервер + СиАй сервер и т.п. Сабвершн поставился без инцидентов за меньше чем 5 минут. Немножко повозился прикручивая его г Багзилле, но срослось в итоге. Гит - это такая феерическая муть по сравнению... Тоесть, вы не подумайте, я не сравниваю работу (хотя и там у меня есть нарекания), я просто говорю об интерфейсе программа-человек. В Гите политика не задумываться об удобстве разработчика, а следовать каким-то надуманным принципам. Настроить авторизацию (серверную часть) - это ад, бессмысленный и беспощадный. При чем, мне было бы не жалко, если бы это несло в себе какие-то бонусы. Так ведь нет. Те "улучшения", изза которых система становится более сложной - как раз та часть системы, которую нужно сразу же удалить и никогда не использовать.

                      Так, например, авторизация по буличным ключам компьютера недопустима в мало-мальски большой организации, особенно, если она позволяет пользователям доступ с домашних компьютеров.
                      Ответить
                      • Не нужно забывать, для чего и кем был разработан git. Он отлично подходит для сетей доверия, subversion просто не способен на организацию подобных взаимодействий. Соответственно, для сильно централизованных организаций эта модель не несёт особых плюсов. А вот для распределённых команд и опен-сорса git просто незаменим. То, что вам не нужна распределённость, не означает, что она вообще никому не нужна. Например, я работал в компании, которая разрабатывала часть приложения для Сбербанка. При этом другие компоненты приложения разрабатывались ещё полудюженой компаний. Компании публиковали свои разработки в собственных git-репозиториях, сберовцы потом всё это дело мёржили. Мне сложно представить, как организовать подобный способ работы с Subversion.

                        > В Гите политика не задумываться об удобстве разработчика
                        В гите политика думать, что ты делаешь, и знать, как он работает. Гибкость просто неимоверна, позволяется даже переписывать историю (rebase, squash), чего вроде бы не позволяет ни одна другая система управления ревизиями. Если использовать централизованную топологию, отличия от subversion минимальны.

                        Гит хранит не последовательность патчей, он хранит полную историю коммитов, знает, что, когда, как мёржилось. Это превращает мёржи в довольно тривиальную задачу (если работа была правильно распределена и конфликтов не много). Я, к примеру, трижды подумаю прежде, чем использовать ветку в subversion. В гите я даже думать не буду. А ведь у меня довольно богатый опыт мёржа веток в svn.

                        > если она позволяет пользователям доступ с домашних компьютеров
                        В чём проблема с доступом с домашних компьютеров по ключу?

                        Основная проблема с гитом - относительная сложность организации аутентификации, т.е. разделение прав. Эту проблему решают отдельные приложения вроде gitlab и gerrit.
                        Ответить
                        • > В чём проблема с доступом с домашних компьютеров по ключу?
                          В том же самом, в чем и проблема с доступом с домашних компьютеров по паролю - в доступе с домашних компьютеров ;)
                          Ответить
                        • Людей, которые переписывают историю надо увольнять без разговоров. Это можно разрешать только человеку непосредственно ответственному за репозиторий. Т.е. админу. Программисту работающему в организации - никогда.

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

                          Проблема в том, что домашний компьютер не находится под защитой корпоративного фаирвола и т.п. Если компутер сам, без содействия пользователя (т.е. помня пароль) может залогиниться в корпоративную сеть - это беда. Если такому пользователю сделать веб-авторизацию, то у него по крайней мере будет выбор: запомнить пароль / использовать менеджер парлолей, или тупо записать где-нибудь. В случае с авотизацией по публичным ключам - в мире может быть есть человек десять, способных запомнить свой публичный ключ. Остальные его будут просто записывать где-нибудь. Фрилансеры почти наверняка будут логинится из Виндовса - где никаких ограничений на доступ к их кючу не предвидится.
                          Ответить
                          • > Если такому пользователю сделать веб-авторизацию, то у него по крайней мере будет выбор: запомнить пароль / использовать менеджер парлолей, или тупо записать где-нибудь.

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

                            Проблема то совсем не в ключах и паролях. Вы серьезно считаете, что трояну, сидящему на компе того самого фрилансера, ключ угнать легче чем спиздить пароль вводимый юзером с бумажки? Да это абсолютно равнозначные по сложности действия.
                            Ответить
                          • Я переписываю историю довольно часто. В моём локальном репозитории перед push. Чтобы исправить ошибку в тексте коммита, добавить забытый файл либо слить 5 коммитов в один, чёткий и понятный. Переписывание публичной истории порицается всеми, и гит даже не позволит сделать этого, если не указать ключ -f.

                            История в git ничем не хуже, чем в subversion, даже лучше, ибо хранит больше информации. Например, путём слияния каких коммитов был получен мёрж. Конфликты решаются практически также, как и в svn, впрочем, практически в любом VCS мёрж конфликтов есть тёмная магия и у неопытных пользователей вызывает ступор.

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

                            Нафига запоминать публичный ключ? Он на то и публичный, чтобы его все знали. Он не предоставляет никакой ценности. По-настоящему важен закрытый ключ, и он обычно генерится с правами доступа 600, чтобы кроме создателя его никто открыть не мог. И обычно его стараются либо переносить на защищённом носителе информации, либо генерить для каждого компьютера заново.
                            Ответить
                            • Вот кстати, svn из-за своей централизованной модели поощряет большие коммиты: когда я юзал svn, я не коммитил ничего до тех пор, пока код не начинал стабильно работать. Почему? А тупо потому, что ветки в svn это сущий ад, а за не собирающегося/бажного транка можно получить по ушам от коллег.

                              С гитом же ситуация намного лучше - можно коммититься сколько душе угодно, можно откатывать изменения, если что-то не то натворил. И, закончив логически осмысленный кусок (пофиксив баг, запилив небольшую фичу), можно смерджить свои изменения с матстером и запушить их.
                              Ответить
                              • И изменение истории в этом случае - отличный помощник. Если настроен CI, который билдит и прогоняет тесты на каждый коммит, а в локальном репозитории есть нерабочие ревизии, git rebase -i позволит убить двух зайцев: сделать коммит более понятным для коллег и не получать гневных писем от CI-сервера.
                                Ответить
                              • И вообще, я не агитирую за Сабвершн, я за Перфорс, если что. Но Сабвершн мне все равно больше нравится, т.как он по крайней мере пытается сделать правильную вещь. Гит - это просто горячечный бред: попыктта вополотить неправильные идеи под эгидой всеобщей любви к человеку руководящему проектом.
                                С Сабвершном - это вполне известная неприятность - очень затрудниетельно в любом виде отойти от основной рабочей версии. Как правило это нужно / приходится делать с разрешения / в присутствии админа. Но это правильно! Т.как программист не должен плодить версии безконтрольно, потому что этим он создает проблемы административного порядка, которые решать уже не ему. У Сабвершна нет такого понятия как "локальная история", поэтому тут и сравнивать бессмысленно, но если сравнивать с Перфорсом, то там это удобнее, чем в Гите, и ничего вообще не переписывается, т.как этот процесс не связан напрямую с историей всего репозитория.

                                > Вы серьезно считаете, что трояну [...]
                                Тут даже не про трояны речь. Если авторизируется компьютер, то любой, кто воспользуется этим компьютером без вообще каких либо усилий сможет авторизироваться. Это как разница между открытой дверью и дверью закрытой на амбарный замок. Амбарный замок просто сломать, имея инструменты, но все таки мы считаем такую дверь более защищенной.
                                Ответить
                                • Да, случай с ssh-ключем, не защищенным пассфразой, эквивалентен сохраненному паролю, здесь проверяется только комп - это как ключ, засунутый под коврик перед дверью.

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

                                  P.S. С перфорсом вживую не встречался, но посмотреть давно хочу. Надо будет попробовать поюзать его на каком-нибудь небольшом но реальном проекте.
                                  Ответить
                                  • У нас в городе мало кто использует perforce, из коммерческих в основном ClearCase. Сам как раз начинал с CC, в принципе, вещь неплохая, тормозит только шибко. От коллеги слышал организацию workflow с perforce, судя по всему, немного напоминает ClearCase UCM.
                                    Не знаю, нужно ли оно, когда вокруг столько бесплатных простых инструментов с отличной документацией.
                                    Ответить
                                    • Да, есть, не спорю, но если уже вибырать, то поводов выбрать Гит нет никаких. Гит не столько плохо работает, сколько заурядно бездарный проект, с типичным для многих такого плана проектов распиздяйством, непродуманной системой и плохим интерфейсом. Меня раздражает то, что люди, которые его используют фанатично и безосновательно верят в то, какой он лучше всех. И, что еще хуже, поскольку он всецело и безоговорчно принимается, то и все дурацкие идеи, типа того, что система должна быть распределенной - принимаются безапеляционно на веру. Из всех боготворителей Гита ни один толком не сможет даже описать зачем это нужно, но кого ни спроси - с умным видом об этом вспоминают.
                                      Вобщем, типичное необдуманное позерство и groupthink, которого везде и всегда полно.
                                      Ответить
                                      • > заурядно бездарный проект, с типичным для многих такого плана проектов распиздяйством

                                        Это уже слишком толсто. А с виду ты худенький
                                        Ответить
                                        • Тут где-то была дискуссия в том же ключе про JS с участием wvxvw, если мне не изменяет память.
                                          Ответить
                                          • > где-то была дискуссия в том же ключе про JS с участием wvxvw

                                            Перефразирую Классика

                                            "There are only two kinds of technologies: the ones wvxvw complains about and the ones nobody uses."
                                            Ответить
                            • История в Гит - это фикция, миф, ее в нем просто нет. Это все равно, что взять историю из того же Сабвершна, нарезать по одному слову и перемешать. - Получтся "почти то же самое".
                              Ответить
                              • Сейчас открыл ман по гитолайту, решил перечитать продвинутые опции, и нашел там опцию M, которая запрещает пушить merge коммиты.

                                С опцией M ваша история станет линейной и шелковистой.
                                Ответить
                                • Так Гит можно вообще просто взять и переписать, и исправить, и тот баг, который я нашел, я сам же мог бы и пофиксить - но у меня нет времени заниматься такими правками. Я лучше возьму что-то, что работает более вменяемо без того, чтобы его изящно допиливть напильником.
                                  Ответить
                                  • Ну так если гитовское workflow для ваших задач не подходит, а дописать пару букв в конфиге гитолайта для страховки от форс пушей и нелинейной истории и т.п. вам не хочется, зачем вы вообще с гитом связались?

                                    Если ваш перфорс такой удобный и хороший почему вы не убедили своих программистов его юзать?

                                    P.S. Если в гитолайте включены RW+M у админа и RW у программистов, то история линейная, менять ее без помощи админа нельзя, что же вам еще нужно ;)
                                    Ответить
                                    • В том-то все и дело, если начинать обвешиваться всякой херней вокруг Гита, чтобы с ним можно было нормально работать - то в чем смысл? Кроме того, Гитолайт сам по себе - кусок говна тот еще, с ним проблем приходит не меньше, чем решений. И это вообще порочный круг.

                                      Я один, а их много... люди, как правило не пытаются самостоятельно анализировать: что всплыло в Гугле с большим счетчиком - то и используют. Ни в одном месте, где я работал, за исключением того, где использовался Перфорс, люди либо ничего кроме Сабвершн никогда не видели, либо это был выбор между Сабвершн и Гит. Но дело даже не в этом. Перфорс - коммерческий. И если уже быть до конца откровенным, то тут у некоторых иногда даже Виндовса лицензионного нет, а о том, чтобы взять коммерческий продукт вместо популярного бесплатного, каким бы хорошим он ни был... честно, я бы тоже взял что-то бесплатное. :( Но я бы смотрел в сторону Базара, т.как написано на Питоне и его просто интегрировать с билд скриптами (если они тоже на Питоне), и с Си-Ай скриптами, если они тоже на Питоне, и с еще кучей всего, что тоже может случайно быть написано на Питоне...
                                      Ответить
                          • > Это можно разрешать только человеку непосредственно ответственному за репозиторий. Т.е. админу. Программисту работающему в организации - никогда.

                            Ок. Пишем в конфиге гитолайта обычным программистам RW, админу RW+. Выдыхаем.
                            Ответить
                            • Какой-то странный подход. Суть в том, что опубликованную историю не стоит менять, потому что это аффектит разработчиков, делая их локальные коммиты несовместимыми с основной веткой, и порождает хаос. А админ, разумеется, имеет доступ только к опубликованной истории, следовательно, права на изменение истории ему просто не нужны.

                              Далее. Из речей @wvxvw складывается ощущение, что админы - существа гораздо более глубокомысленные и знающие, чем программисты. По моему опыту они обычно ленивее и лучше противостоят нововведениям, ведь если что сломается, иметь будут их, и я ничего не имею против. Ещё они иногда лучше разбираются в железках и знают, что где лежит, и как оно включается. Но менять историю в репозитории я бы своим админам не доверил.
                              Так что единственный мотив давать права на изменение истории админам - тот факт, что она им абсолютно неинтересна, и они в неё никогда не полезут.
                              Ответить
                              • > Так что единственный мотив давать права на изменение истории админам - тот факт, что она им абсолютно неинтересна, и они в неё никогда не полезут.

                                Я так понял, что админ править историю будет только тогда, когда к нему прибегут программисты, и объяснят начерта им надо ее менять. Я думаю в остальное время ему будет просто лень копаться в проекте, у админов и без этого другой работы полно. А права админу, управляющему репой не помешают, т.к. иначе ему придется их выдать самому себе, когда возникнет критическая ситуация.
                                Ответить
                              • P.S. А может быть под админом тут понимается не системный администратор, а просто самый главный из программистов, отвечающих за проект, и соответственно адмнистрирующий его...
                                Ответить
                              • Под админом тут понимается человек, ответственный за билды. В больших организациях - это как правило отдельный человек, а то и целый отдел отдельных человеков, кому вменяется поддерживать систему в работоспособном состоянии. Это не системный администратор (человек который ползает с эзернет кабелем под столом у программиста), а человек который пишет плагины к Мейвену, скрипты к Дженкинсу и т.п.
                                Ответить
    • Какой интересный cvs-срач.
      wvxvw против gita.
      От создателей В js скушное ооп и Некошерный эрланг.
      Смотрите этой зимой на говнокоде.
      Лично мне эта часть показалась скушной и избитой. Актерская игра никакая. Сплошная толстота.
      Ответить
      • Git: история одного проекта.
        fix
        Ответить
      • Не знаю, что там у Джона Доу за претензия к Ричарду Роу, касательно багов или прочих осязаемых претензий, но мне не нравится сама идея РСОВ, хотя я не умаляю её преимуществ для ядер блинуксовразных и полезных опенсорс проектов, когда иметь множество локальных хранилищ вполне прельстиво и любовне.
        Соглашусь, срач вышел унылый. И возник на пустом месте.

        Возвращаясь к основному обсуждению. Само собой, опять даты, опять PHPSQL, но я почему-то пошёл против общественного мнения. Как много иррационального в наших поступках. Хотелось бы услышать мнение ещё троих.
        Ответить

    Добавить комментарий