= Сообщение: 2594 из 5324 ========================================= RU.HUSKY = От : Pavel Gulchouck 2:463/68 23 May 17 14:57:26 Кому : Alexey Vissarionov 23 May 17 14:57:26 Тема : миграция на git FGHI : area://RU.HUSKY?msgid=2:463/68+5924298c На : area://RU.HUSKY?msgid=2:5020/545+591b2b10 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hi Alexey!
16 May 17, Alexey Vissarionov ==> All:
AV> Что сделано: AV> 1. Создано хранилище git.huskyproject.org AV> 2. Туда скопирован код из CVS
Без истории и веток, что ли? :-(
AV> 3. Попутно fidoroute (сафроутер) обрел собственную репу AV> 4. Для документации создана отдельная репа huskydoc AV> 5. Поднято read-only зеркало https://github.com/huskyproject AV> 6. Настроена синхронизация из git.huskyproject.org в github
AV> Как я представляю себе дальнейшую работу: AV> 0. Все виды коммуникаций между разработчиками происходят только фидошными средствами. Объяснение: если человек не может AV> написать в эху - вряд ли есть смысл принимать от него какие-то патчи. Именно поэтому github - read-only.
Ох... :-( Самое интересное, что есть на гитхабе - это пул-реквесты, ревью, комменты и их merge. Именно это - то, что делает удобным развитие opensource-проектов и даёт им жизнь. Если без всего этого, то зачем вообще оно на гитхабе нужно? Только для того, чтобы проект жил на твоём личном домене, или есть другие причины?
И вопрос не только в том, каким путём передать патч. Пул-реквест - это больше, чем патч. Это может быть несколько коммитов, это обсуждение, вопросы по изменениям, возможные доработки в результате ревью...
Процесс внесения изменений нужно сделать максимально удобным, тогда у проекта будет больше шансов развиваться. А оценивать патч исходя из того, каким путём он прислан - в фидошном netmail, в email или в виде пул-реквеста на гитхаб - это глупость. Ладно бы, если бы реквестов было несколько штук в день, и была необходима какая-то их первичная фильтрация, тогда можно было бы усложнять требования к оформлению реквестов. Но тут-то ситуация прямо противоположная.
AV> 1. Для любых исправлений, кроме совсем уж очевидных (например, опечаток в документации) создаем новые экспериментальные AV> ветки, и все работы ведем там. AV> 2. В ветку master изменения попадают только после того, как их работа будет проверена как минимум в двух AV> системах - GNU/Linux и Windows. AV> 3. Объявляется, что `git reset --hard` является штатным действием в процессе разработки. AV> Лично я это делать умею и люблю, а также готов научить уметь и любить всех желающих.
Сам по себе "git reset --hard" - действие над локальной копией репозитория. Это личное дело разработчика, никак других разработчиков не затрагивающее, "каждый дрочит, как он хочет". Как и "git rebase", и много других удобных инструментов для формирования красивого пул-реквеста.
Если же ты имеешь ввиду, что штатным средством является "git push --force", то... Наверное, у тебя просто не было опыта командной разработки, других объяснений такому решению я найти не могу.
Lucky carrier, Паша aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
