Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.143.9.115] |
|
Сообщ.
#1
,
|
|
|
кто что думает?
|
Сообщ.
#2
,
|
|
|
git канеш. Если уж не технологиями, то хотя бы наличием github
|
Сообщ.
#3
,
|
|
|
Алло, народ! Изделие Микрософта противопоставляется детищу Линуса! Где холивар???
|
Сообщ.
#4
,
|
|
|
Это как сравнивать тёплое с мягким. Одно используется только в студии, другое - почти что стандарт вообще любого опенсорсного проекта (начиная с линуксов, заканчивая какими-нибудь Unreal Engine 4), и некоторых проприетарных.
Добавлено Так что никаких холиваров, тут уже известный победитель. |
Сообщ.
#5
,
|
|
|
Тем более в новых студиях есть поддержка git из коробки.
Если уж нужен холивар, то давайте git vs hg. Лично я не понимаю, почему все выбирают первый. Неужели только из-за популярности? |
Сообщ.
#6
,
|
|
|
Цитата OpenGL @ Если уж нужен холивар, то давайте git vs hg. ну создавай =) Цитата OpenGL @ Неужели только из-за популярности? да |
Сообщ.
#7
,
|
|
|
Цитата OpenGL @ Не все. Лично я не понимаю, почему все выбирают первый. |
Сообщ.
#8
,
|
|
|
Цитата OpenGL @ уже почти год использую второй как рабочий инструмент (в смысле, приходится по работе). Вердикт: Лично я не понимаю, почему все выбирают первый. Из хорошего могу назвать только лучшую интеграцию с Eclipse. И в общем-то удобный bisect (хотя не лучше чем у git-а). Из плохого: - медленный. очень. очень-очень прям -- даже на сравнительно небольших репозиториях как и всё, что на питоне - удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую. - git add -p ужасно не хватает. и вообще разделения за committed/staged/unstaged. hg record -- урезанный -- конкретно урезанно: -- нельзя перейти в режим редактирования патча -- нельзя разбить патч на более мелкие части -- нельзя временно пропустить патч, чтоб посмотреть что ещё в этом файле изменилось, чтоб принять решение по данному чанку - откатить можно только последний коммит. (тут мат, много мата). hg mq я правда ниасилил. описание весьма сумбурное + на оф. страничке предупреждение "This extension is often considered for deprecation, but there's no consensus yet". докоммитить нельзя, можно только откатить коммит и заново коммитить. (если это делать -- как я -- через hg record, это становится испытанием силы воли). - git stash порой тоже не хватает. приходится делать hg diff > patch && some shit && patch -p1 < patch (всё вышесказанное сравнительно с Git. Если сравнивать с svn например, то hg не небо и земля конечно, но значительный шаг вперёд). Ну и постоянно по мелочи слышу от коллег мол "это низя". короче, никогда, никогда не вводите в своей организации эту дрянь. (для своего hello world -- сколько угодно, но не надо это другим впаривать) Добавлено Цитата Serafim @ Цитата OpenGL @ Неужели только из-за популярности? да нет |
Сообщ.
#9
,
|
|
|
negram, это вот устарело?
http://habrahabr.ru/post/123700/ |
Сообщ.
#10
,
|
|
|
хм. непомню подобных проблем на практике. надо осилить опус...
|
Сообщ.
#11
,
|
|
|
Цитата negram @ нет наверное |
Сообщ.
#12
,
|
|
|
Неправильная постановка вопроса.
TFS - это Team Foundation Server. И в качестве системы контроля версий он предлагает на выбор Git либо TSVC ( Team Foundation Version Control). Т.е. если и имеет смысл сравнивать, то Git и TSVC в рамках работы с TFS. |
Сообщ.
#13
,
|
|
|
negram, а как насчет черезжопной уродской системы команд git? http://habrahabr.ru/post/175943/
Короче, hg хорош, если вы НЕ знаете толк в извращениях и никто в команде не пытается прострелить ногу репозитария. |
Сообщ.
#14
,
|
|
|
Цитата negram @ Что именно надо делать, чтобы медленность "ощутить"? - медленный. очень. очень-очень прям -- даже на сравнительно небольших репозиториях как и всё, что на питоне Проект, если что: Total Physical Source Lines of Code (SLOC) = 310,135 Правда я не особо продвинутый юзер - с обоими знаком не сильно глубоко, так что разницы особой и не вижу. Поэтому только производительностью и заинтересовался. |
Сообщ.
#15
,
|
|
|
Цитата DarkEld3r @ Наверное что-нибудь в районе kernel.org Что именно надо делать, чтобы медленность "ощутить"? |
Сообщ.
#16
,
|
|
|
Цитата applegame @ Не все. Велик и могуч русский язык - иногда в нём "все" означает "большинство" Цитата negram @ - медленный. очень. очень-очень прям -- даже на сравнительно небольших репозиториях как и всё, что на питоне Не знаю. В целом скорость устраивает. Вероятно, потому, что я исключительно через гуй работаю. Так что ок, запишем в плюс гиту. Цитата negram @ - удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую. Не вижу проблемы - клонируешь дважды репу в разные места и ведёшь как обычно. То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно. Цитата negram @ - git add -p ужасно не хватает. А что это? Беглый гуглинг не помог. Цитата negram @ и вообще разделения за committed/staged/unstaged. А под этим что понимается? Ручное задание этих пометок файлам что ли? Цитата negram @ hg record -- урезанный -- конкретно урезанно: -- нельзя перейти в режим редактирования патча -- нельзя разбить патч на более мелкие части -- нельзя временно пропустить патч, чтоб посмотреть что ещё в этом файле изменилось, чтоб принять решение по данному чанку В консоли - может быть. В TortoiseHG при коммите разве что сами патчи нельзя редактировать. Но коммитить только часть патча и смотреть всё, что поменялось в файле вполне можно. Цитата negram @ - git stash порой тоже не хватает. приходится делать hg diff > patch && some shit && patch -p1 < patch Есть же shelve. В гуе это так вообще мегаудобно делается. Цитата negram @ - откатить можно только последний коммит Ты про hg rollback? Имхо, нафиг не надо - проще просто обновиться к нужной ревизии, а все ошибочные коммиты удалить или пометить секретными. Цитата applegame @ а как насчет черезжопной уродской системы команд git? http://habrahabr.ru/post/175943/ Или постоянные "шозанах", стандартное объяснение которых сводится к "это не баг - это фича". Например, вот. Ну и на том же хабре в статьях-комментах периодически проскакивают советы "как надо делать нечто, чтобы не сломать репозиторий". Для hg таких советов я не припомню, да и вообще слабо представляю, как его можно сломать случайно. |
Сообщ.
#17
,
|
|
|
Цитата Total Physical Source Lines of Code (SLOC) = 310,135 Это - маленький. Едва приближается к среднему. |
Сообщ.
#18
,
|
|
|
M Поменял название темы |
Сообщ.
#19
,
|
|
|
Цитата Бобёр @ Дык, речь шла о "сравнительно небольших". Ну посмотрим через годик будут ли заметны тормоза. Это - маленький. Едва приближается к среднему. |
Сообщ.
#20
,
|
|
|
Чем мне нравится в hg, так это то, что его завел и работаешь над проектом без головной боли, а в git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx.
Нет у меня желания углубляться в тонкости "как оно работает". git меня заставляет углубляться, hg нет. А так в целом git - няшка, особенно github. |
Сообщ.
#21
,
|
|
|
Мм. Вероятно, не устарело, но я так и не понял проблемы Вроде, через gitk очень даже показывается что надо
Цитата applegame @ Всё ж не стоит использовать худ.литературу как мануал negram, а как насчет черезжопной уродской системы команд git? Пока я вижу, что hg достаточно далёк от функционала git-а. Причём, это касается именно повседневной работы, уже не говоря о таких извращениях как например rerere Цитата DarkEld3r @ push? Хотя, у меня чаще тормозит pull (обе эти команды занимают 5-20 секунд). На той неделе много раз пришлось клонировать репу, так это занимало по нескольку минут. А репозиторий-то -- всего 500K строк в сумме. Что именно надо делать, чтобы медленность "ощутить"? Добавлено Цитата OpenGL @ Цитата negram @ - удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую. Не вижу проблемы - клонируешь дважды репу в разные места и ведёшь как обычно. То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно. Мне вот как-раз такое и надо было: есть несколько проектов, с одной кодовой базой, но иногда разными плюшками и разной релизовой жизнью. Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\ |
Сообщ.
#22
,
|
|
|
Цитата negram @ Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\ Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать. |
Сообщ.
#23
,
|
|
|
Цитата OpenGL @ Цитата negram @ - git add -p ужасно не хватает. А что это? Беглый гуглинг не помог. Цитата negram @ и вообще разделения за committed/staged/unstaged. А под этим что понимается? Ручное задание этих пометок файлам что ли? Ответ сразу на оба вопроса картинкой, ибо расписывать долго. В кратце: изменения в коммит можно набирать в несколько этапов. Причём не файлами, а отдельными патчами. Алсо помогает при мерже, если произошли конфликты: всё, что нормально смержилось сразу добавляется в коммит (staged), остальное предлагается поправить и добавить. Добавлено Цитата OpenGL @ Ммм.. по описанию, похоже что надо... Попробую... Есть же shelve. Цитата OpenGL @ Эх Даже если отбросить то, что гуй не всегда доступен, есть такой момент: сколько я этих гуёв видел, обычно всё какое-то урезанное. (TortoiseSVN, TortoiseGit, плагины к разным IDE -- практически всё не пригодно к использованию). TortoiseHg поэтому даже не пытался смотреть. Думаешь, стоит попробовать? В гуе это так вообще мегаудобно делается. Добавлено Цитата OpenGL @ Цитата negram @ Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\ Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать. Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна, во вторых: Цитата looks like not an option. A local tag is a convenience identifier that is not revision controlled, does not propagate with other changes, and lives in the Добавлено Цитата applegame @ Вот только если в гите, скорее всего, таки можно нагуглить как что-то сделать, в hg упираешься в то, что -- низя git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx. Прикреплённая картинка
|
Сообщ.
#24
,
|
|
|
Цитата negram @ остальное предлагается поправить и добавить. Не совсем понимаю "поправить". Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()? Если да, то в thg такого не сделать. Но выбрать для коммита отдельные части diff-а (например, менял пятую и двадцатую строки, а коммитить решил только пятую) я могу. Цитата negram @ Думаешь, стоит попробовать? Не знаю. Я гуй считаю априори более удобным для большинства задач, ты, скорей всего, наоборот. По крайней мере в thg можно удобно сделать большинство из того, что ты записал в минусы hg record. А окно shelve выглядит как на скриншоте - перемещаешь файлы или их части направо в выбранный shelve или наоборот. Прикреплённая картинка
Цитата negram @ Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна Всё равно не вижу проблемы. Ну есть ревизии в репе, и что? Не мешают же. Вот с тегами засада, да. Придётся вводить префиксы, чтобы в разных ветках они обязательно назывались по-разному. Но в таком случае я бы в первую очередь подумал, как решить ту же задачу, которую ты решаешь в гите частичным клонированием репозитория со своими тегами. |
Сообщ.
#25
,
|
|
|
Цитата OpenGL @ Ага. Редко требуется, конечно, но бывает.Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()? Цитата OpenGL @ Ошибаешься, у меня нет априоных установок на этот счёт. Diff я к примеру в 95% случаев смотрю в kompare и не понимаю соседей которые делают ревью с помощью hg diff. Просто я после нескольких лет сидения на TortoiseSVN перешел на консольный SVN-клиент. И внезапно он реально оказался более послушным. Хотя, судя по скриншотам, у тебя система в которой отсутствует автодополнение и подсветка в консоле, так-что наверное там просто выбора нет.Я гуй считаю априори более удобным для большинства задач, ты, скорей всего, наоборот. Цитата OpenGL @ Ну я не нашел оправдания тому, чтоб во все проекты пихать баги-фичи всех проектов (к тому же их ещё и клиент видит; ну специфика у нас такая). Всё равно не вижу проблемы. Ну есть ревизии в репе, и что? |
Сообщ.
#27
,
|
|
|
А у нас на работе щас Perforce стоит. До этого работал с Mercurial и SVN. Поначалу вообще в этом Перфорсе непривычно, сейчас немного уже привык в нем.
|
Сообщ.
#28
,
|
|
|
Вообще то, perforce, во первых стоит деньги, во вторых закрытая система, да и еще клиент-сервер.
А fossil открытая, бесплатная и распределённая. При этом, в отличии от тот же git у fossil все преимущества клиент-сервер архитектуры сохраняются. |
Сообщ.
#29
,
|
|
|
Во, хороший холивор.
Я все еще с удовольствием держу свои проекты в mercurial. И все также сильно страдаю, когда приходится работать с чужими гитхабовскими репами. Особо бесит оторванная башка (detached head), при малейшем отклонении от свежепрочитанного мануала. |
Сообщ.
#30
,
|
|
|
|
Сообщ.
#31
,
|
|
|
cvsnt! дцать лет по мере перехода к svn, затем к git (модно), работать с скв становится всё сложнее, сами они всё медленнее, а функционал всё паршивее
|
Сообщ.
#32
,
|
|
|
Цитата wind @ Тормознее SVN я ничего не встречал. сами они всё медленнее, а функционал всё паршивее |
Сообщ.
#33
,
|
|
|
Цитата applegame @ Тормознее SVN я ничего не встречал. zip архивчики медленнее |
Сообщ.
#34
,
|
|
|
Цитата TFS vs Git vs Mercurial vs SVN vs ..., папочки с проектами рулят (шутка) |
Сообщ.
#35
,
|
|
|
Цитата Serafim @ Ви таки считаете, что SVN - это формат архивирования? zip архивчики медленнее |
Сообщ.
#36
,
|
|
|
Ну тормоза за SVN я не замечал, если честно, проработал с ним где то года 3-4. Причем я бы не сказал что маленький проект, около 1000 сотрудников. Проект очень масштабный был.
Тормозов не замечал |
Сообщ.
#37
,
|
|
|
Цитата KILLER @ А я замечал. Mercurial и Git намного быстрее. Они собственно архитектурно быстрее, тут дело даже не в возросшей мощности компьютеров. Ну тормоза за SVN я не замечал, если честно, проработал с ним где то года 3-4. Причем я бы не сказал что маленький проект, около 1000 сотрудников. Проект очень масштабный был. Тормозов не замечал |
Сообщ.
#38
,
|
|
|
Цитата applegame @ А я замечал. Mercurial и Git намного быстрее. Они собственно архитектурно быстрее, тут дело даже не в возросшей мощности компьютеров. Ну а пример можно? В чем это выражалось например? Тупило/подвисало еще что то? Сколько человек работало с проектом? |
Сообщ.
#39
,
|
|
|
да не подвисает, просто работает очень медленно, всё делает очень медленно, катастрофически медленно, без связи с количеством клиентов
то что в/из цвс чекаутилось и комиталось секунды, выполняет в течение минут, буквально ну и гит, канеш, значительно пошустрее, чем свн |
Сообщ.
#40
,
|
|
|
Цитата KILLER @ Цитата applegame @ А я замечал. Mercurial и Git намного быстрее. Они собственно архитектурно быстрее, тут дело даже не в возросшей мощности компьютеров. Ну а пример можно? В чем это выражалось например? Тупило/подвисало еще что то? Сколько человек работало с проектом? Даже элементарные вещи делались дольше. Но основное, наверное, это тормозные ветки. |
Сообщ.
#41
,
|
|
|
Цитата Besha @ папочки с проектами рулят (шутка) Вот ты смеёшься, а я своими глазами в одной конторе видел систему контроля версий в виде набора папок с именами <проект>-копия (n). По-моему при мне n до 147 доходило Добавлено Цитата D_KEY @ Даже элементарные вещи делались дольше. Но основное, наверное, это тормозные ветки. Может быть это исключительно из-за того, что svn - централизованное хранилище? Так-то разницы в скорости между svn commit и hg commit && hg push на примерно одинаковых по размеру проектах я не замечал. |
Сообщ.
#42
,
|
|
|
Цитата OpenGL @ Цитата Besha @ папочки с проектами рулят (шутка) Вот ты смеёшься, а я своими глазами в одной конторе видел систему контроля версий в виде набора папок с именами <проект>-копия (n). По-моему при мне n до 147 доходило Как-то в одном крупном банке, на собеседовании, мне сказали, что "мы просто в файлике делаем ремарку что было сделано, чейнджлог такой". Было это где-то в 2010-м. А сам банк сейчас в TOP10 по версии banki.ru |
Сообщ.
#43
,
|
|
|
Цитата OpenGL @ Вот ты смеёшься, а я своими глазами в одной конторе видел систему контроля версий в виде набора папок с именами <проект>-копия (n). По-моему при мне n до 147 доходило Вот тебе смешно, а у них изначально решена задача получения среза проекта на определенный момент времени |
Сообщ.
#44
,
|
|
|
Цитата wind @ да не подвисает, просто работает очень медленно, всё делает очень медленно, катастрофически медленно, без связи с количеством клиентов то что в/из цвс чекаутилось и комиталось секунды, выполняет в течение минут, буквально ну и гит, канеш, значительно пошустрее, чем свн Ну у меня проект чекаутился с нуля где то минут 15. Объем проекта - около 2 гигов исходных кодов/различных скриптов и т.д. Неужто гит за секунды все это выкачает? |
Сообщ.
#45
,
|
|
|
Цитата KILLER @ За секунды -- нет, но при прочих равных будет ощутимо шустрее. Да чекаут с нуля - в общем-то не особо интересно сравнивать. Вот постоянные коммиты, чекауты, переключение между ветками, мерж -- вот где git вырывается в перёд по производительности, фичастости и по качесву. Правда, остаётся позади по newbie-friendly Неужто гит за секунды все это выкачает? |
Сообщ.
#46
,
|
|
|
Цитата negram @ Вот постоянные коммиты, чекауты, переключение между ветками, мерж -- вот где git вырывается в перёд по производительности, фичастости и по качесву. Правда, остаётся позади по newbie-friendly Ну с чекаутом и комитами проблем в свне особых не замечал. Сейчас работаю с перфорсом, переключится между ветками - ну пара секунд, 2 раза мышкой ткнуть. получить последнюю версию ветки - тоже быстро. По крайней мере когда я месяц не выкачивал новую, у меня это заняло несколько секунд - ну может секунд 10 Ну комиты вроде тоже быстро проходят. Единственное в Perforce - чекаут имеет другой смысл, нежели в меркуриал или свн. Я поначалу именно в этом терялся. Для меня после SVN - чекаут был равносильно получению последней версии сборки. В Perforce все не так. Там эту функцию выполняет Get Latest Revision, а checkout снимает пометку только чтение для файлов. Добавлено Ну и плюс для перфорса есть плагин под студи.ю. Т.е. с репозиторием можно работать прямо из студии. Что в принципе напрочь перечеркивает использование гуя, если приловчится. Но я пока не на столько его освоил. Хотя в студии плагин стоит и делать чекаут могу прямо из студии. |
Сообщ.
#47
,
|
|
|
Цитата KILLER @ переключится между ветками - ну пара секунд Доооолго... |
Сообщ.
#48
,
|
|
|
Цитата Астарот @ Доооолго... А быстро это сколько? Вот я щас посчитал - у меня вышло 3 нажатия мышкой, чтобы полностью перейти на другую ветку. Возможно там можно еще сочетания клавиш настроить. Добавлено Причем это один из методов только. Вот есть второй - в 1 нажатие мыши. Причем разными способами - перетаскиванием, либо вызовом контекстного меню. Думаю можно настроить хот кеи, тогда еще быстрее будет. Ну пол секунды. |
Сообщ.
#49
,
|
|
|
Цитата KILLER @ А быстро это сколько? Вот я щас посчитал - у меня вышло 3 нажатия мышкой, чтобы полностью перейти на другую ветку. Возможно там можно еще сочетания клавиш настроить. А зачем ты считаешь нажатия мышкой, когда считать надо переключение с ветки на ветку? |
Сообщ.
#50
,
|
|
|
Цитата Астарот @ А зачем ты считаешь нажатия мышкой, когда считать надо переключение с ветки на ветку? Ну вот смотри, прочитал твое сообщение, засек время, переключился на перфорс, и в нем перешел на другую ветку, все вместе заняло буквально секунды 3-4. Это при том, что я еще искал где там в контекстном меню Work In this stream. Добавлено Вот например, у нас щас есть две ветки, Dev и Release, все пишется в Dev, и потом сливается в релиз, некоторые. Так вот я комичусь, тут же секунды 2-3 уходит на то, чтобы перейти в ветку релиз, беру закомиченный ченжлист, и мержу его сходу в релиз, ну единственное я там еще пишу вменяемый комментарий, какой номер бага, кроме того, что подставляет сам перфорс(аля мерж из Dev в Release). В итоге по времени у меня уходит меньше минуты чтобы закомитится и смержить все это в релиз(если не считать написание коментариев, и разруливания конфликтов при мерже, если они есть) Добавлено Я просто не знаю куда еще быстрее и проще У тебя есть либо графическое дерево веток, либо таблица(как ты хочешь), и по сути ты берешь выбираешь нужную ветку и говоришь - хочу в ней работать. Все, куда еще проще и быстрее то? разве что только ты во всех сразу одновременно будешь работать - но тогда смысл в ветках напрочь теряется. |
Сообщ.
#51
,
|
|
|
Цитата KILLER @ И всё? Вот например, у нас щас есть две ветки |
Сообщ.
#52
,
|
|
|
Цитата negram @ И всё? Нет, это конкретно те, с которыми я вот прям щас работаю, а так их - 28, и это тех, для которых есть стримы. А в реале их еще больше. |
Сообщ.
#53
,
|
|
|
Возможно, скорость из консоли будет ощущаться. В начале темы, когда шло обсуждение hg vs git, я так и не понял, почему в плюсы второго записали скорость - по субъективным ощущениям из gui первый ничуть не медленней.
|
Сообщ.
#54
,
|
|
|
Цитата OpenGL @ Возможно, скорость из консоли будет ощущаться. Что у hg что у svn, что у perforce - у всех есть дублирующие команды. В перфорсе, когда ты что то делаешь из гуи, он прям воспроизводит эту команду в output окне, и можно посмотреть - как действие которое ты делаешь, будет выглядет ьв консоли. |
Сообщ.
#55
,
|
|
|
Цитата KILLER @ Ну вот смотри, прочитал твое сообщение, засек время, переключился на перфорс, и в нем перешел на другую ветку, все вместе заняло буквально секунды 3-4. Это при том, что я еще искал где там в контекстном меню Work In this stream. Кого вообще волнует сколько ты что искал? Ты можешь быть тормозом преклонных годов, но на быстродействие системы контроля версий это не скажется никак. В гите переключение на ветку командой git checkout branchName выполняется моментально. Цитата KILLER @ Вот например, у нас щас есть две ветки, Dev и Release, все пишется в Dev, и потом сливается в релиз, некоторые. Так вот я комичусь, тут же секунды 2-3 уходит на то, чтобы перейти в ветку релиз, беру закомиченный ченжлист, и мержу его сходу в релиз, ну единственное я там еще пишу вменяемый комментарий, какой номер бага, кроме того, что подставляет сам перфорс(аля мерж из Dev в Release). В итоге по времени у меня уходит меньше минуты чтобы закомитится и смержить все это в релиз(если не считать написание коментариев, и разруливания конфликтов при мерже, если они есть) Интересный у вас flow... Добавлено Цитата OpenGL @ по субъективным ощущениям из gui первый ничуть не медленней. Гуйня временами адово тормозит, а иногда еще и глючит Мерять быстродействие по гуйне все равно что мерять быстродействие гуйни, которое имеет мало общего с реальностью. |
Сообщ.
#56
,
|
|
|
Цитата Астарот @ Кого вообще волнует сколько ты что искал? Ты можешь быть тормозом преклонных годов, но на быстродействие системы контроля версий это не скажется никак. В гите переключение на ветку командой Ага, вот мне дали задачу, а зафикси вот эту багу в версии 3.1 Так я щас пришел сразу и git checkout - и полез искать как branchName называется Или ты названия всех веток наизусть помнишь? Цитата Астарот @ Интересный у вас flow... Обычный флоу, маленькие баги, которые точно ничего не сломают - можно выкладывать в релиз сразу. А серьезные сначало идут в Dev, потом это все тестится на Dev, и раз в две недели мержится в релиз, если все норм. |
Сообщ.
#57
,
|
|
|
Цитата KILLER @ Ага, вот мне дали задачу, а зафикси вот эту багу в версии 3.1 Так я щас пришел сразу и git checkout - и полез искать как branchName называется Или ты названия всех веток наизусть помнишь? Каких - всех? Нафига мне помнить названия ВСЕХ веток? По нашему флоу есть релиз, есть девелоп, и от этого девелопа отщелкиваются фичабрэнчи, в которых делается вся работа. Уж имя бранча на котором я работаю я запомнить в состоянии, да и нафига его помнить, когда я один раз его создал, и коммичу в него, и хрен с ним как он там назван? Понадобится другая ветка - таки узнаю ее название, и сделаю чекаут. Всю дорогу миллионы программистов так делают, и ничего, не перемерли еще. Сделал работу, слил ветку в девелоп - и удалил ее нахрен, что б не мешалась. |
Сообщ.
#58
,
|
|
|
Цитата OpenGL @ Очень мало (всего год) работал с гуями обоих, но поработав hg годик, совсем не хочется добровольно возвращаться туда В начале темы, когда шло обсуждение hg vs git, я так и не понял, почему в плюсы второго записали скорость - по субъективным ощущениям из gui первый ничуть не медленней. Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю |
Сообщ.
#59
,
|
|
|
Цитата Астарот @ выполняется моментально. Ну вот кстати аналог в перфорсе p4 switch branchName Цитата Астарот @ Каких - всех? Нафига мне помнить названия ВСЕХ веток? По нашему флоу есть релиз, есть девелоп, и от этого девелопа отщелкиваются фичабрэнчи, в которых делается вся работа. Уж имя бранча на котором я работаю я запомнить в состоянии, да и нафига его помнить, когда я один раз его создал, и коммичу в него, и хрен с ним как он там назван? Понадобится другая ветка - таки узнаю ее название, и сделаю чекаут. Всю дорогу миллионы программистов так делают, и ничего, не перемерли еще. Сделал работу, слил ветку в девелоп - и удалил ее нахрен, что б не мешалась. Ааа, то есть у вас всегда 1 версия и два бренча Дев и Релиз? Или как? Я сегодня работал с одним бренчем, завтра мне сказали - вот тут нужно в другой версии, вообще в другой ветке пофиксить багу, а после завтра, вот тут вообще в левой версии для другого клиента, нужно реализовать вот такую фигушечку. И к основным веткам Dev и релиз - эти бренчи никак не относятся. Я у себя открыл в перфорсе Стримы - и вижу все которые есть. Выбрал нужный, выкачал и работаю с ним. Комитить/выкачивать новые файлы, отправлять на ревью и все остальное я могу прямо из IDE. Мне даже не нужно лезть в консоль для того что бы что то там набирать. Понимаешь? Добавлено Более того, я даже могу все эти действия - по выбору стримов и их выкачке делать прямо из IDE. Добавлено при прочих равных, ты набирать команду будешь даже не быстрее, чем я тоже самое буду делать в гуях. И что у меня в гуях, что у тебя в консоли - все это выполняется моментально. |
Сообщ.
#60
,
|
|
|
Цитата negram @ Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю А что с ним? Вроде тот же гит, вид сбоку... Цитата KILLER @ Ааа, то есть у вас всегда 1 версия и два бренча Дев и Релиз? Или как? Я сегодня работал с одним бренчем, завтра мне сказали - вот тут нужно в другой версии, вообще в другой ветке пофиксить багу, а после завтра, вот тут вообще в левой версии для другого клиента, нужно реализовать вот такую фигушечку. Конкретно на том проекте, на котором я работаю сейчас вообще все просто - у нас внутренняя софтана, то есть продакт овнер наш же директор, поэтому поддерживать несколько версий одновременно нафиг не нужно. А так вообще версия - это мерж в релизную ветку. Как смержил девелоп в релиз - так и версия. Ну, и где-то рядышком канитель из веток с патчами и хотфиксами Цитата KILLER @ отправлять на ревью и все остальное я могу прямо из IDE. Мне даже не нужно лезть в консоль для того что бы что то там набирать. Понимаешь? Да все я понимаю. Это сахар, который в пределе работает с той же консолью. Добавлено Цитата KILLER @ при прочих равных, ты набирать команду будешь даже не быстрее, чем я тоже самое буду делать в гуях. И что у меня в гуях, что у тебя в консоли - все это выполняется моментально. Когда тебе говорят про бстродействие речь идет не о том, насколько быстро ты можешь сделать коммит, а о том, насколько велики задержки в работе самой скв. Ну, блин, какой-нибудь не к ночи будь помянут clear case на тупом чекауте произвольной ревизии зависал на десятки секунд, если склероз не врет. |
Сообщ.
#61
,
|
|
|
Цитата Астарот @ А так вообще версяия - это мерж в релизную ветку. Как смержил девелоп в релиз - так и версия. Еще тегом с номером версии ее можно обозначить. |
Сообщ.
#62
,
|
|
|
Цитата Астарот @ Конкретно на том проекте, на котором я работаю сейчас вообще все просто - у нас внутренняя софтана, то есть продакт овнер наш же директор, поэтому поддерживать несколько версий одновременно нафиг не нужно. А так вообще версия - это мерж в релизную ветку. Как смержил девелоп в релиз - так и версия. Ну, и где-то рядышком канитель из веток с патчами и хотфиксами Ну у нас примерно так же - каждый комит по сути новая версия. Но я лично говорю не за версии, а за бранчи. Вот есть 5 клиентов и 5 разных бранчей(к примеру), вот и попереключайся в консоли, если ты активно прыгаешь с одного бранча на другой. или нужно побыстрому смержить в 3 разные ветки одни и те же изменения. Цитата Астарот @ Да все я понимаю. Это сахар, который в пределе работает с той же консолью. Ну вот. Что ты будешь альтабится и набирать в консоли, что я тоже самое сделаю прямо из среды разработки, улетит одно и то же время. Считать миллисекунды тут бессмысленно. |
Сообщ.
#63
,
|
|
|
Цитата Kray74 @ Еще тегом с номером версии ее можно обозначить. Это само собой У нас тимсити при сборке аж сам какими-то тегами гадит. Вообще теги удобная штука, что б помечать удаленные за ненадобностью ветки. Добавлено Цитата KILLER @ Ну у нас примерно так же - каждый комит по сути новая версия. Коммит? Ты ничего не перепутал? Цитата KILLER @ вот и попереключайся в консоли, если ты активно прыгаешь с одного бранча на другой Во-первых не вижу реальной необходимости активно прыгать Во-вторых не вижу ничего ужасного. В-третьих активно пользуюсь И консолью, И гуйней, которая таки имеет как множество недостатков, так и множество преимуществ. И в-четвертых, бляха-муха, речь шла не об этом. Добавлено Цитата KILLER @ Считать миллисекунды тут бессмысленно. Так не считай - тут только ты этим занят. |
Сообщ.
#64
,
|
|
|
Цитата Астарот @ Когда тебе говорят про бстродействие речь идет не о том, насколько быстро ты можешь сделать коммит, а о том, насколько велики задержки в работе самой скв. Ну, блин, какой-нибудь не к ночи будь помянут clear case на тупом чекауте произвольной ревизии зависал на десятки секунд, если склероз не врет. О госпади какая трагедия. Целые 10 секунд. Ты тут на форуме тратишь больше в рабочее время А по факту, смотря сколько и каких файлов ты выкладываешь. Вот я когда выкладываю штук 50 файлов по 2-3 мегабайта каждый(очень большие хмл скрипты, которые иногда подвергаются изменениям), так у меня бывает и по 20 секунд скв комит делает. Лично для меня 20 секунд не критично, я же не биоробот какой. Чтоб считать секунды. Добавлено Цитата Астарот @ Коммит? Ты ничего не перепутал? немного не так выразился, не коммит, а отдельная компиляция - это считай поднимается версия на какое то значение. Цитата Астарот @ Во-первых не вижу реальной необходимости активно прыгать Во-вторых не вижу ничего ужасного. Так а зачем тогда вообще спорить - если прыгать никуда не нужно? У меня на прошлой работе вообще отдельный бранч под каждого клиента был, поэтому их стало на столько много, что их было очень тяжело контролировать ,и когда их поделили на три или четыре, их осталось всеравно много! И порой дают задачи под разных клиентов, вот тогда то и начинаешь прыгать. И когда я сидел на SVN, я именно так и писал: svn checkout branchAddress, и постоянно приходилось лезть и смотреть какое там название бранча, особенно если там всякие подчеркивания и числа, то проще вообще скопировать. Но это время. Цитата Астарот @ Так не считай - тут только ты этим занят. Это говорит мне человек, для которого несколько секунд - это Дооолго, и комит в 10 секунд - ужастноооо дооолго. |
Сообщ.
#65
,
|
|
|
Цитата Астарот @ А что с ним? Вроде тот же гит, вид сбоку... Смотри начало темы |
Сообщ.
#66
,
|
|
|
Цитата OpenGL @ Смотри начало темы А! Спасибо! Там аж прям крик души |
Сообщ.
#67
,
|
|
|
Цитата Астарот @ Цитата negram @ Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю А что с ним? Вроде тот же гит, вид сбоку... У меня сложилось ощущение, что это SVN с примесями DCVS |
Сообщ.
#68
,
|
|
|
Цитата negram @ У меня сложилось ощущение, что это SVN с примесями DCVS |
Сообщ.
#69
,
|
|
|
Цитата negram @ Я и сейчас работаю в консоли в git и hg а также в гуе hg (потому что для git вменяемого гуя не существует) и у меня строго обратные впечатления. Лично мне не нравится, что в git легко поломать локальную репу и нужно курить маны для элементарных вещей. А что тебе не нравится в hg? Очень мало (всего год) работал с гуями обоих, но поработав hg годик, совсем не хочется добровольно возвращаться туда Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю |
Сообщ.
#70
,
|
|
|
Цитата applegame @ потому что для git вменяемого гуя не существует GitExtension вроде б ничего, нет? Плюс этот... как его... SourceTree что ли. Правда этот сорстри руководствуясь черт знает чем умудрился сделать коммит, хотя я у него этого и не просил, после чего был снесен нах, но многим нравится. Цитата applegame @ в git легко поломать локальную репу Ну, не так уж и легко... |
Сообщ.
#71
,
|
|
|
Цитата applegame @ Цитата negram @ Я и сейчас работаю в консоли в git и hg а также в гуе hg (потому что для git вменяемого гуя не существует) и у меня строго обратные впечатления. Лично мне не нравится, что в git легко поломать локальную репу и нужно курить маны для элементарных вещей. А что тебе не нравится в hg?Очень мало (всего год) работал с гуями обоих, но поработав hg годик, совсем не хочется добровольно возвращаться туда Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я ч>не понимаю Как в git поломать локальную репу? По поводу hg -- это я год назад что-то мог внятное сказать. Пока пользовался, постоянно вылезало - то одно он не умеет, то другое. Как только вернулся на git сразу все неудобства исчезли и совсем не хочется их вспоминать . Навскидку, не хватало подключения нескольких удалённых репозиториев, git add -p (hg record -- сильно урезанный вариант), ну и неторопливость работы напрягала. |
Сообщ.
#72
,
|
|
|
Цитата negram @ Как в git поломать локальную репу? Оторвать у ветки голову При этом она, зараза, временами отрывается сама, словно ей больше заняться нечем, и начинается брейк с выковыриванием всего и вся из полудохлого состояния. Еще можно на мерже провалится в богомерзкий kdiff3, выйти из него, и обнаружить, что файлы сырцов испогенены диффами. Да много чего можно, что б жизнь медом не казалась Другое дело, что гит тут вовсе не исключение... |
Сообщ.
#73
,
|
|
|
Цитата negram @ git add -p (hg record -- сильно урезанный вариант) Этот разве что патчи не умеет редактировать. Но в остальном в гуях - вполне себе аналог. Цитата negram @ Навскидку, не хватало подключения нескольких удалённых репозиториев Это про paths в hgrc? |
Сообщ.
#74
,
|
|
|
Цитата Астарот @ ой-ой-ой, выкинь эту какашку Еще можно на мерже провалится в богомерзкий kdiff3 Цитата Астарот @ И как это выглядит? При этом она, зараза, временами отрывается сама Цитата OpenGL @ А там можно в одну репу запушить один набор веток, в другую -- другой?Это про paths в hgrc? Цитата OpenGL @ Ну в гуях может быть Но в остальном в гуях - вполне себе аналог. |
Сообщ.
#75
,
|
|
|
Цитата negram @ ой-ой-ой, выкинь эту какашку А есть что-то более вменяемое для трехстороннего мержа? Хочу! Очень надо, дайте! Под винду... Цитата negram @ И как это выглядит? Ну, как... Хреново это выглядит Из гуя может выглядеть, как ветка без имени, а то и просто ветка берет и исчезает. Или голова начинает указывать на предпоследнюю ревизию, и приходится шаманить с ее переустановкой на головную ревизию руками. Как правило прежде чем понимаешь, что что-то пошло не так, успеваешь что-то куда-то смержить, и окончательно похерить зыбкие шансы вернуть утраченное |
Сообщ.
#76
,
|
|
|
Цитата negram @ И как это выглядит? Да чё там, вот тебе скрин с моего проекта! Прикреплённая картинка
Курсор как раз стоит на ветке, которая никуда не слита, но у которой нет имени. Тег есть, а имени нету Как они так умудрились без меня, я не знаю, но факт об лицо. Добавлено При этом git branch --contains sha1 дает ровно нихрена |
Сообщ.
#77
,
|
|
|
Цитата Астарот @ Таки интересно как такое получилось и какое из этого следствие.Курсор как раз стоит на ветке, которая никуда не слита, но у которой нет имени. Тег есть, а имени нету Как они так умудрились без меня, я не знаю, но факт об лицо. Цитата Астарот @ Всегда конфликты в vim-е разруливаю. Уже давно не помню, чтоб были проблемы... А есть что-то более вменяемое для трехстороннего мержа? |
Сообщ.
#78
,
|
|
|
Цитата negram @ А там можно в одну репу запушить один набор веток, в другую -- другой? Можно при пуше и пуле указывать, какую именно ветку ты хочешь отправить или получить. Просто при пуше ветки всё равно пойдут все родительские, поэтому если ветка, которую ты пушишь, выросла из той, которую ты пушить не хочешь, то вторая ветка запушится до ревизии, где произошло разделение. Насколько я понимаю, в гите не так только потому, что в нём ветки - просто метки на коммитах (которые при пуше другой ветки вполне себе могут не уходить), а не последовательность коммитов, как в hg. |
Сообщ.
#79
,
|
|
|
Цитата negram @ Таки интересно как такое получилось Насколько я понял это были какие-то эксперименты на тимсити, связанные со сборкой, а уж что конкретно пошло не так я хз. Но такие кунштюки гит выделывает периодически, я уже не удивляюсь. Цитата negram @ и какое из этого следствие. Да понять-то его, царь-надежа, не мудрено... (с) В смысле следствие простое - прежде чем начинать какие-то эксперименты с репозиторием в целом, лучше его физически скопировать насторону, и в случае чего просто восстановить методом прогрессивного копирования Цитата negram @ Всегда конфликты в vim-е разруливаю. Уже давно не помню, чтоб были проблемы... И как это выглядит? Добавлено Цитата OpenGL @ в гите не так только потому, что в нём ветки - просто метки на коммитах Ветки в гите и правда нихрена не ветки. Я бы их назвал "именованная голова", что полностью описывает их суть. |
Сообщ.
#80
,
|
|
|
Сообщ.
#81
,
|
|
|
Цитата negram @ Меня бесили случайно отцепленные головы, после которых либо фперед курить маны либо тупо заново клонировать удаленную репу.Как в git поломать локальную репу? Цитата negram @ Хз, может ты изначально предвзято относился к mercurial? Потому что в mercurial можно подключить несколько реп. Что касается git add -p, то хотелось бы знать для чего именно ты его применял и почему hg record показался тебе сильно урезанным (чего не хватало).По поводу hg -- это я год назад что-то мог внятное сказать. Пока пользовался, постоянно вылезало - то одно он не умеет, то другое. Как только вернулся на git сразу все неудобства исчезли и совсем не хочется их вспоминать . Навскидку, не хватало подключения нескольких удалённых репозиториев, git add -p (hg record -- сильно урезанный вариант), ну и неторопливость работы напрягала. Дело в том, что недостаток функциональности mercurial на поверку оказывается просто незнанием. |
Сообщ.
#82
,
|
|
|
Нда, а сколько пиара то про этот гит А на деле башню сносит, у меня как то не было такого, тем чем я пользовался
Вот например сейчас открыл проект, и прямо в студии - вижу какие файлы уже кем то были изменены, т.е. мне нужно работать с файлом Xxx.cpp, он в студии помечен как устаревший(т.е. кто то его уже закомитил, и у меня старая версия) - я его тут же обновил в 2 клика сырцы, все - теперь у меня свежий проект. И даже конфликтных ситуаций из за этого возникает меньше при коммите. |
Сообщ.
#83
,
|
|
|
Цитата Астарот @ Аналог в mercurial - букмарки. Для фичебранчей - самое оно.Ветки в гите и правда нихрена не ветки. Я бы их назвал "именованная голова", что полностью описывает их суть. Кстати, в TortoiseHG есть shelve куда можно засунуть, то что НЕ хочешь коммитить, в частности можно выбрать отдельные чанки. Staging area совсем не обязателен, те же задачи можно решить и другими способами. Добавлено Цитата KILLER @ Git изначально создавался для разработчиков ядра линупса и под их workflow. Зачастую гитофаны полагают, что других workflow существовать не может.Нда, а сколько пиара то про этот гит Пишешь новую фичу в opensource проект, делаешь пулл-реквест и начинается: склей коммиты в один, сделай ребейз. То есть с одной стороны возможность отслеживать историю разработки при помощи системы контроля версий, а с другой стороны эта странная любовь гитофанов к фальсификации этой самой истории. Пусть история липовая, зато дерево выглядит красяво. Впрочем, моя основная претензия к git - кривые доки и перегруженность редкоиспользуемым обычными разработчиками функционалом. |
Сообщ.
#84
,
|
|
|
Цитата applegame @ Ммм. Нет. Если по пунктам:Хз, может ты изначально предвзято относился к mercurial? Потому что в mercurial можно подключить несколько реп. Что касается git add -p, то хотелось бы знать для чего именно ты его применял и почему hg record показался тебе сильно урезанным (чего не хватало). Дело в том, что недостаток функциональности mercurial на поверку оказывается просто незнанием. - нет, предвзятого отношения не было совсем. Скорее наоборот, слышал, что о нём хорошо отзываются, и по началу даже было интересно попробовать. - про подключение нескольких реп в прошлом году в этот же тред я получил ответ: Цитата Так вот, мне были важны как-раз не полные копии репозиториев (вообще, с моей точки зрения, брезовая затея), а именно часть общая, часть различная. Так-что либо не я один Hg не знаю, либо там что-то изменилось за это время.То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно. - hg record: в git есть понятие staging. Соответственно, git add -p добавляет чанк в стейджинг, который потом можно закоммитить. И я постоянно, делаю это в несколько приходов; либо по файлам, а иногда возникает необходимость остановиться и посмотреть целиком diff, чтобы понять нужно ли вот это конкретное изменение в коммите или нет. Так вот, при использовании `hg record' можно либо довести операцию до финала (до коммита), либо отменить целиком (и потом всё по новой). Если измений много, то это напрягает. Добавлено Цитата applegame @ Ибо нафиг не нужен мусор из слабо связанных между собой коммитов. Потом задалбаешься собирать - где что произошло Пишешь новую фичу в opensource проект, делаешь пулл-реквест и начинается: склей коммиты в один, сделай ребейз. Добавлено Цитата applegame @ История самая, что ни на есть настоящая без конвульсий, происходящих в голове разработчика. Пусть история липовая, зато дерево выглядит красяво. |
Сообщ.
#85
,
|
|
|
Цитата negram @ - про подключение нескольких реп в прошлом году в этот же тред я получил ответ: Эм Тот диалог был про выкачивание конкретных веток, и я тогда не знал, как оно делается А указывать репу при пуше - базовая фича любой DVCS, я считаю. |
Сообщ.
#86
,
|
|
|
Цитата OpenGL @ В прошлый раз я получил ответ и от тебя и от гугла, что такое невозможно. Сейчас проверять не сильно хочется Тот диалог был про выкачивание конкретных веток, и я тогда не знал, как оно делается |
Сообщ.
#87
,
|
|
|
Цитата negram @ Для этого есть shelve. Там наоборот, указываешь что не хочешь коммитить.- hg record: в git есть понятие staging. Соответственно, git add -p добавляет чанк в стейджинг, который потом можно закоммитить. И я постоянно, делаю это в несколько приходов; либо по файлам, а иногда возникает необходимость остановиться и посмотреть целиком diff, чтобы понять нужно ли вот это конкретное изменение в коммите или нет. Так вот, при использовании `hg record' можно либо довести операцию до финала (до коммита), либо отменить целиком (и потом всё по новой). Если измений много, то это напрягает. Цитата negram @ Ибо нафиг не нужен мусор из слабо связанных между собой коммитов. Потом задалбаешься собирать - где что произошло Цитата negram @ Эти конвульсии и есть настоящая история, а не то что выглядит красиво. Впрочем, тут скорее дело вкуса. Так что спорить не буду. История самая, что ни на есть настоящая без конвульсий, происходящих в голове разработчика. Добавлено Цитата negram @ Что именно невозможно? Клонировать не всю репу, а отдельный бранч? Это как раз можно. В прошлый раз я получил ответ и от тебя и от гугла, что такое невозможно. Сейчас проверять не сильно хочется |
Сообщ.
#88
,
|
|
|
Цитата applegame @ Что именно невозможно? Клонировать не всю репу, а отдельный бранч? Это как раз можно. Это не совсем то, что он хочет. Добавлено Правда, возможно, что с букмарками можно сделать то, что ему надо. В конце-концов они даже в документации называются аналогом гитовских "веток". |
Сообщ.
#89
,
|
|
|
Цитата negram @ Как в git поломать локальную репу? кстати, да. на самом деле вообще ничего не нужно делать! есть один проектец, в котором я ничего не меняю, но иногда сую нос обновить xsd-схемы. почти всегда не удается, бгг, из-за тонны локальных изменений, с которыми из носу кровь надо что-то сделать, иначе не обновиться. что за придурь, не знаю, уничтожаю репу и клоню заново |
Сообщ.
#90
,
|
|
|
Цитата wind @ Вот уж действительно, откуда взяться локальным изменениям, если изменяется только одна xsd-схема?но иногда сую нос обновить xsd-схемы. почти всегда не удается, бгг, из-за тонны локальных изменений, с которыми из носу кровь надо что-то сделать, иначе не обновиться обновиться, при локальных изменениях как-раз просто: git stash git pull git stash pop |
Сообщ.
#91
,
|
|
|
Так git же сам пишет в таких случаях, что для того, чтобы он мог сделать pull надо на выбор сделать или commit или stash
|
Сообщ.
#92
,
|
|
|
Цитата git format-patch --stdout > lol.patch |
Сообщ.
#93
,
|
|
|
Цитата negram @ git stash Цитата amk @ надо на выбор сделать или commit или stash Цитата wind @ ничего не меняю "ничего не меняю" - это значит, что у меня нет никаких локальных изменений |
Сообщ.
#94
,
|
|
|
Цитата wind @ Значит ты чего-то не договариваешь. Если нет изменений, git pull проходит всегда и без вопросов. "ничего не меняю" - это значит, что у меня нет никаких локальных изменений |
Сообщ.
#95
,
|
|
|
Цитата wind @ "ничего не меняю" - это значит, что у меня нет никаких локальных изменений Включая форматирование кода, которое в некоторых средах происходит автоматически? То есть ты ничего не менял, но Цитата f() { ... } превратилось в Цитата f(){ ... } С твоей точки зрения ничего не изменилось, а с точки зрения гита ты весь файл перелопатил. Других идей пока что нет... |
Сообщ.
#96
,
|
|
|
ничего - это ничего, абсолютно, от слов никак, нигде и никоим образом и такая петрушка из раз эдак пяти-шести, когда я в этот репозиторий заглядывал, случилась два раза
Добавлено Цитата Астарот @ форматирование кода, которое в некоторых средах происходит автоматически а за такое склонен вообще расстреливать, уж точно не страдаю |
Сообщ.
#97
,
|
|
|
Цитата wind @ не-прав-да ничего - это ничего, абсолютно, от слов никак, нигде и никоим образом |
Сообщ.
#98
,
|
|
|
Цитата wind @ ничего - это ничего, абсолютно, от слов никак, нигде и никоим образом и такая петрушка из раз эдак пяти-шести, когда я в этот репозиторий заглядывал, случилась два раза Учитывая, что гит используют тысячи прогеров по всему миру, и учитывая, что описанный баг сводит ценность системы к нулю... В общем, думаю, ты заблуждаешься, и таки что-то все же происходит. Дифф различия показать ведь должен? Хотя бы изменившиеся переводы строк, что может быть совершенно не очевидно! Цитата wind @ а за такое склонен вообще расстреливать, уж точно не страдаю Я просто предположил. Еще из вариантов изменившиеся переводы строк. Или покорравтившиеся русскоящычные фразы - у меня пару раз было так, что какая-то какашка умудрилась превратить русский текст в файле в кракозябры совершенно неожиданным образом, оставив по себе только вопрос: "Какая сука бросила валенок на пульт?!" |
Сообщ.
#99
,
|
|
|
Цитата Астарот @ Дифф различия показать ведь должен? Хотя бы изменившиеся переводы строк, что может быть совершенно не очевидно! различий море, серьезных таких простыней и в куче файлов. о том и речь. что на самом деле изменений не было ни единого. чейндждэйты нетронуты, есичо. клоню репозиторий, месяц-другой к нему не прикасаюсь, пытаюсь обновить, - вуаля. через недельку всё ок, еще через недельку снова всё ок, два месяца не трогал, лезу обновляться - тадам. э? Добавлено Цитата Астарот @ сводит ценность системы к нулю... оно и так к нулю близко, по крайней мере с свн был один гемор - меееееееееедленно, а тут столько всего нового и всё не в кассу. я только 2 раза в жизни видел, как переходили от одной скв к другой действительно по какой-то причине, а не из-за того, что это модно, первый раз cvs->starteam из-за транзакций (сетка нестабильная), другой раз cvs->svn из-за трафика (не знаю, не проверял, говорили, что svn сильно меньше кушал). а еще бесконечно радует в гите необходимость обновлять локал (хотя мне категорически не надо обновляться!) в случае, когда я поменял файлик a, а в удаленном репозитории поменялись b и c. вот дальше никак, <вц>, апдейт жизненно необходим! |
Сообщ.
#100
,
|
|
|
Цитата wind @ различий море, серьезных таких простыней и в куче файлов. о том и речь. Так это не гит виноват. Ровно то же самое будет с другой vcs. |
Сообщ.
#101
,
|
|
|
Цитата OpenGL @ Ровно то же самое будет с другой vcs. расскажи, как такое сотворить, к примеру, с svn |
Сообщ.
#102
,
|
|
|
Судя по тому, что ты рассказал - точно так же
|
Сообщ.
#103
,
|
|
|
Цитата OpenGL @ Судя по тому, что ты рассказал - точно так же ну, ежели не знаешь, зачем тогда пургу мести? точно так же не получится, выкачанное из svn, как ни странно, не "протухает" |
Сообщ.
#104
,
|
|
|
wind, то есть ты считаешь, что файлы в локальной репе кем то изменяются, даже при не запущенном git?
|
Сообщ.
#105
,
|
|
|
Цитата wind @ точно так же не получится, выкачанное из svn, как ни странно, не "протухает" Ок, давай по другому - если у тебя меняются файлы в стиле "я ничего не трогала - оно само сломалось" - ищи причины где угодно, но не в гите. Он в данной ситуации - наименее вероятный виновник происходящего. Гит, конечно, та ещё какашка в плане юзабилити, но в плане надёжности он весьма неплох, и сам по себе файлы не портит. Добавлено Да и откуда ты знаешь, что svn на этом же проекте не портит? У тебя есть текущая копия этого же проекта в svn? |
Сообщ.
#106
,
|
|
|
А какова вероятность следующего сценария?
wind клонирует репу, после чего приходит negram и |
Сообщ.
#107
,
|
|
|
1. Нулевая negram никогда не изменяет то, что запушено, потому-что это плохо. Нормальный разраб тоже, как минимум, потому что просто это не делается.
2. Хватит уже завидовать |
Сообщ.
#108
,
|
|
|
Цитата negram @ 1. Ну это может быть у форумного negram, а у описаного мной может быть и ненулявая. Правда, в любом случае, git тут явно не причем.1. Нулевая negram никогда не изменяет то, что запушено, потому-что это плохо. Нормальный разраб тоже, как минимум, потому что просто это не делается. 2. Хватит уже завидовать 2. А чему я, по-твоему, завидую? Править историю можно и в mercurial, но я не люблю это делать. И когда меня заставляют это делать в git я раздражаюсь. |
Сообщ.
#109
,
|
|
|
Цитата OpenGL @ Да и откуда ты знаешь, что svn на этом же проекте не портит? заколдованный проект? а что, отличная версия Добавлено Цитата applegame @ А какова вероятность следующего сценария? wind клонирует репу, после чего приходит negram и сопстна да, сильно похоже на порчу истории в удалёнке, хз что там творят. но вот вопрос - это вообще скв? с такими возможностями? чем оно лучше расшаренной папки тогда? |
Сообщ.
#110
,
|
|
|
Цитата wind @ Да, скв. Рассчитывающая на то, что оператор понимает что делает. Ну лично для меня естественно, что СКВ пользуются программисты и обезьян среди них быть не должно. Конкретно про push --force, это отключается на раз два, хотя если это действительно кто-то использовал, он должен как минимум объяснить свои серьёзные основания для этого. Если такое использовали не раз, то это повод сделать предположение, что что-то не в порядке.но вот вопрос - это вообще скв? с такими возможностями? А сама возможность редактирования истории - чрезвычайно полезная. Локальной истории, разумеется. |
Сообщ.
#111
,
|
|
|
Цитата negram @ А сама возможность редактирования истории - чрезвычайно полезная. Локальной истории, разумеется. А что означает фраза: " сама возможность редактирования истории" ? Я просто не понимаю что такое история в гите или еще где то? Это как? Типа сначала сделал, выложил, потом спустя некоторое время что то поправил в дескрипшине? Или как? |
Сообщ.
#112
,
|
|
|
Цитата negram @ Ну лично для меня естественно, что СКВ пользуются программисты и обезьян среди них быть не должно. бгг, скв для того и существуют, чтобы не надо было трястись о том, чтобы никто не перекинул коллеге гранату без чеки. любое действо должно оставить след, не должно быть никаких способов этот след изгладить, всегда должна быть возможность вернуться к любому из этапов развития проекта. так что этот ваш гит и не скв вовсе, а хрень какая-то, которую суют не в то гнездо |
Сообщ.
#113
,
|
|
|
Цитата negram @ Нихрена не локальной. Когда меня просят сделать squash и rebase, мне приходится это делать не в локальной истории, а в моем форке на гихабе. Пока они там чешут репу по поводу моего пулл-реквеста, я успеваю добавить еще какие-то изменения для своих целей. Тут опа, давай-ка чувак, правь свою историю, и заверте... оторванные бошки, курение мануалов, проклятия в сторону git. В конечном итоге я пришел к известному методу: скопируй все свои изменения, похерь локальную копию, похерь форк, сделай форк заново, клонируй его к себе, скопируй свои изменения, коммит, пуш, пулл-реквест, профит. Локальной истории, разумеется. |
Сообщ.
#114
,
|
|
|
Цитата applegame @ я делаю ветку новую и переношу туда изменения конечном итоге я пришел к известному методу: скопируй все свои изменения, похерь локальную копию, похерь форк, сделай форк заново, клонируй его к себе, скопируй свои изменения, коммит, пуш, пулл-реквест, профит. Добавлено Цитата wind @ Если бы я не знал, что это говорит опытный, я бы подумал, что это говорит новичок-максималист.любое действо должно оставить след, не должно быть никаких способов этот след изгладить, всегда должна быть возможность вернуться к любому из этапов развития проекта Как минимум два раза в моей практике бывали случаи, когда в репозитории оказывалось то, чего там не должно было быть ни в коем случае и как-раз для таких случаев есть возможность rebase, push --force. То, что ваши админы ниасилили запретить такую операцию всем подряд говорит лишь об их квалификации. Впрочем, что именно у вас там было таки никакой информации не поступило, только "аааа, оно мне всё сломало". Добавлено Цитата KILLER @ Ну, можно поправить commit-message, можно объединить несколько коммитов, можно добавить что-нибудь в последний коммит, либо вырезать коммит нахрен.ипа сначала сделал, выложил, потом спустя некоторое время что то поправил в дескрипшине? Все эти действия делаются легко, если коммиты не были отправлены в общий репозиторий. При очень острой необходимости, есть возможность это сделать и в удалённом, только делать это строжайше запрещается. |
Сообщ.
#115
,
|
|
|
Цитата negram @ Новая ветка это само собой. Для пулл-реквеста приходится форк делать. Дпугих способов я не знаю. я делаю ветку новую и переношу туда изменения |
Сообщ.
#116
,
|
|
|
Цитата applegame @ Это-то да. Но зачем предыдущий форк херить? Для пулл-реквеста приходится форк делать. |
Сообщ.
#117
,
|
|
|
Цитата negram @ Если бы я не знал, что это говорит опытный, я бы подумал, что это говорит новичок-максималист. ы. даже не знаю, что добавить. я описал опыт взаимодействия с цвс/свн тащемта. у них есть недостатки, но там хотя бы нет штатных функций из разряда "привет, геморрой", которыми, в силу уж не знаю каких причин, люди почему-то вынуждены пользоваться. |
Сообщ.
#118
,
|
|
|
У нас с git-ом такая схема.
Есть master ветка. Каждый, кто хочет девелопить - отстреливает себе ветку. Свою. Личную. Персональную. Никто туда больше не чирикает. В мастер ничего не мерджится просто так. Через gt stash. Создается пул реквест, ревьюеры должны поглядеть на чейндж и если все ок - approve. Или reject. В этом же gt stash оно мерджится. Очень удобный инструмент. |
Сообщ.
#119
,
|
|
|
Цитата Бобёр @ У нас вообще отдельный бот в мастер маржит, который сначала тесты прогоняет, конфликты проверяет В мастер ничего не мерджится просто так. |
Сообщ.
#120
,
|
|
|
Автоматика. Ну, правда, с конфликтами в gt stash ты тоже не замерджишь, это факт. А вот тесты у нас только билд сервер работает, т.е. уже после мерджа.
|
Сообщ.
#121
,
|
|
|
Вообще надо автоматизировать до состояния "пул реквест реджектится если code coverage после работы теста меньше 100%"
|
Сообщ.
#122
,
|
|
|
Ну не , это уже близко к клиническому состоянию... Тогда очень скоро тесты будут писать так, чтоб бот отъвязался.
У нас сейчас пилится "реджект, если это самое покрытие упало", ну плюс там всякие условия. |
Сообщ.
#123
,
|
|
|
Я не читал всю тему - слишком много и скучно.
Я по работе использую TFS. В общем TFS - отстой. Знаю, что по работе AQL использует GIT - тоже отстой. Я люблю Меркуриал. К сожалению, он не так распространен, поэтому у него сложная интеграция. Вокруг него мало интеграционных продуктов. У ГИТа ветки не настоящие ветки - всего-лишь теги. И мои коллеги теряли ветки просто потому-что у них терялись головные Чекины. А у меркуриала настоящие ветки, доступ к которым всегда можно получить. И чисто субъективно меркуриал дифф делает обоснованнее |
Сообщ.
#124
,
|
|
|
Цитата Leprecon @ Я люблю Меркуриал. Меркуриал тема. Я на прошлой работе его познал, лично для себя. У нас был SVN, но у себя на машине я юзал Mercurial, мне он тоже понравился. |
Сообщ.
#125
,
|
|
|
Цитата Leprecon @ В общем TFS - отстой. Обоснуй Я пока что не видел ничего удобнее. Хотя, признаю, начиная с VS2012 мелкомягкие перемудрили и стало хуже. Никак не могу привыкнуть с новому Team Explorer'у |
Сообщ.
#126
,
|
|
|
Цитата Leprecon @ Причем у меркуриала кроме насточщих веток есть и аналог гитовских псевдоветок - букмарки. У ГИТа ветки не настоящие ветки - всего-лишь теги. И мои коллеги теряли ветки просто потому-что у них терялись головные Чекины. А у меркуриала настоящие ветки, доступ к которым всегда можно получить. |