TFS vs Git vs Mercurial vs SVN vs ... , что лучше?

кто что думает?

Сообщение отредактировано: OpenGL - 08.07.15, 10:52

git канеш. Если уж не технологиями, то хотя бы наличием github

Алло, народ! Изделие Микрософта противопоставляется детищу Линуса! Где холивар???

Это как сравнивать тёплое с мягким. Одно используется только в студии, другое - почти что стандарт вообще любого опенсорсного проекта (начиная с линуксов, заканчивая какими-нибудь Unreal Engine 4), и некоторых проприетарных.

Добавлено 07.07.15, 17:15
Так что никаких холиваров, тут уже известный победитель.

Тем более в новых студиях есть поддержка git из коробки.
Если уж нужен холивар, то давайте git vs hg. Лично я не понимаю, почему все выбирают первый. Неужели только из-за популярности?

Цитата OpenGL @ 07.07.15, 17:23

Если уж нужен холивар, то давайте git vs hg.

ну создавай =)

Цитата OpenGL @ 07.07.15, 17:23

Неужели только из-за популярности?

да

Цитата OpenGL @ 07.07.15, 17:23

Лично я не понимаю, почему все выбирают первый.

Не все.

Цитата OpenGL @ 07.07.15, 17:23

Лично я не понимаю, почему все выбирают первый.

уже почти год использую второй как рабочий инструмент (в смысле, приходится по работе). Вердикт:
Из хорошего могу назвать только лучшую интеграцию с 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 -- сколько угодно, но не надо это другим впаривать)

Добавлено 08.07.15, 08:03

Цитата Serafim @ 07.07.15, 18:34

Цитата OpenGL @ 07.07.15, 17:23

Неужели только из-за популярности?

да

нет

Сообщение отредактировано: negram - 08.07.15, 08:05

negram, это вот устарело?
http://habrahabr.ru/post/123700/

хм. непомню подобных проблем на практике. надо осилить опус...

Цитата negram @ 08.07.15, 08:02

нет

наверное

Неправильная постановка вопроса.
TFS - это Team Foundation Server. И в качестве системы контроля версий он предлагает на выбор Git либо TSVC ( Team Foundation Version Control).
Т.е. если и имеет смысл сравнивать, то Git и TSVC в рамках работы с TFS.

negram, а как насчет черезжопной уродской системы команд git? http://habrahabr.ru/post/175943/
Короче, hg хорош, если вы НЕ знаете толк в извращениях и никто в команде не пытается прострелить ногу репозитария.

Сообщение отредактировано: applegame - 08.07.15, 09:17

Цитата negram @ 08.07.15, 08:02

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

Что именно надо делать, чтобы медленность "ощутить"?
Проект, если что:
Total Physical Source Lines of Code (SLOC) = 310,135

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

Цитата DarkEld3r @ 08.07.15, 09:11

Что именно надо делать, чтобы медленность "ощутить"?

Наверное что-нибудь в районе kernel.org

Цитата applegame @ 08.07.15, 06:28

Не все.

Велик и могуч русский язык - иногда в нём "все" означает "большинство"

Цитата negram @ 08.07.15, 08:02

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

Не знаю. В целом скорость устраивает. Вероятно, потому, что я исключительно через гуй работаю. Так что ок, запишем в плюс гиту.

Цитата negram @ 08.07.15, 08:02

- удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую.

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

Цитата negram @ 08.07.15, 08:02

- git add -p ужасно не хватает.

А что это? Беглый гуглинг не помог.

Цитата negram @ 08.07.15, 08:02

и вообще разделения за committed/staged/unstaged.

А под этим что понимается? Ручное задание этих пометок файлам что ли?

Цитата negram @ 08.07.15, 08:02

hg record -- урезанный
-- конкретно урезанно:
-- нельзя перейти в режим редактирования патча
-- нельзя разбить патч на более мелкие части
-- нельзя временно пропустить патч, чтоб посмотреть что ещё в этом файле изменилось, чтоб принять решение по данному чанку

В консоли - может быть. В TortoiseHG при коммите разве что сами патчи нельзя редактировать. Но коммитить только часть патча и смотреть всё, что поменялось в файле вполне можно.

Цитата negram @ 08.07.15, 08:02

- git stash порой тоже не хватает. приходится делать hg diff > patch && some shit && patch -p1 < patch

Есть же shelve. В гуе это так вообще мегаудобно делается.

Цитата negram @ 08.07.15, 08:02

- откатить можно только последний коммит

Ты про hg rollback? Имхо, нафиг не надо - проще просто обновиться к нужной ревизии, а все ошибочные коммиты удалить или пометить секретными.

Цитата applegame @ 08.07.15, 09:07

а как насчет черезжопной уродской системы команд git? http://habrahabr.ru/post/175943/

Или постоянные "шозанах", стандартное объяснение которых сводится к "это не баг - это фича". Например, вот. Ну и на том же хабре в статьях-комментах периодически проскакивают советы "как надо делать нечто, чтобы не сломать репозиторий". Для hg таких советов я не припомню, да и вообще слабо представляю, как его можно сломать случайно.

Цитата

Total Physical Source Lines of Code (SLOC) = 310,135

Это - маленький. Едва приближается к среднему.

M

Поменял название темы

Цитата Бобёр @ 08.07.15, 10:49

Это - маленький. Едва приближается к среднему.

Дык, речь шла о "сравнительно небольших". Ну посмотрим через годик будут ли заметны тормоза.

Чем мне нравится в hg, так это то, что его завел и работаешь над проектом без головной боли, а в git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx.
Нет у меня желания углубляться в тонкости "как оно работает". git меня заставляет углубляться, hg нет. А так в целом git - няшка, особенно github.

Сообщение отредактировано: applegame - 08.07.15, 11:42

Цитата applegame @ 08.07.15, 08:19

negram, это вот устарело?
http://habrahabr.ru/post/123700/

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

Цитата applegame @ 08.07.15, 09:07

negram, а как насчет черезжопной уродской системы команд git?

Всё ж не стоит использовать худ.литературу как мануал
Пока я вижу, что hg достаточно далёк от функционала git-а. Причём, это касается именно повседневной работы, уже не говоря о таких извращениях как например rerere

Цитата DarkEld3r @ 08.07.15, 09:11

Что именно надо делать, чтобы медленность "ощутить"?

push? Хотя, у меня чаще тормозит pull (обе эти команды занимают 5-20 секунд). На той неделе много раз пришлось клонировать репу, так это занимало по нескольку минут. А репозиторий-то -- всего 500K строк в сумме.

Добавлено 09.07.15, 07:35

Цитата OpenGL @ 08.07.15, 10:43

Цитата negram @ 08.07.15, 08:02

- удалённые репозитории: можно сделать только точную один-в-один копию репозитория. Нельзя вести в одной репе одну ветку, в другой -- другую.

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

Мне вот как-раз такое и надо было: есть несколько проектов, с одной кодовой базой, но иногда разными плюшками и разной релизовой жизнью. Вот тут совсем ненужно было пихать репу во все места, зато надо было иметь собственные теги в каждой репе. Пока-что решили это делать через то самое место :-\

Сообщение отредактировано: negram - 09.07.15, 07:35

Цитата negram @ 09.07.15, 07:31

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

Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать.

Цитата OpenGL @ 08.07.15, 10:43

Цитата negram @ 08.07.15, 08:02

- git add -p ужасно не хватает.

А что это? Беглый гуглинг не помог.

Цитата negram @ 08.07.15, 08:02

и вообще разделения за committed/staged/unstaged.

А под этим что понимается? Ручное задание этих пометок файлам что ли?

Ответ сразу на оба вопроса картинкой, ибо расписывать долго. В кратце: изменения в коммит можно набирать в несколько этапов. Причём не файлами, а отдельными патчами. Алсо помогает при мерже, если произошли конфликты: всё, что нормально смержилось сразу добавляется в коммит (staged), остальное предлагается поправить и добавить.

Добавлено 09.07.15, 07:57

Цитата OpenGL @ 08.07.15, 10:43

Есть же shelve.

Ммм.. по описанию, похоже что надо... Попробую...

Цитата OpenGL @ 08.07.15, 10:43

В гуе это так вообще мегаудобно делается.

Эх Даже если отбросить то, что гуй не всегда доступен, есть такой момент: сколько я этих гуёв видел, обычно всё какое-то урезанное. (TortoiseSVN, TortoiseGit, плагины к разным IDE -- практически всё не пригодно к использованию). TortoiseHg поэтому даже не пытался смотреть. Думаешь, стоит попробовать?

Добавлено 09.07.15, 07:59

Цитата OpenGL @ 09.07.15, 07:47

Цитата negram @ 09.07.15, 07:31

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

Так в чём проблема-то разных репозиториев? А теги вполне можно локальными делать.

Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна, во вторых:

Цитата

A local tag is a convenience identifier that is not revision controlled, does not propagate with other changes, and lives in the

looks like not an option.

Добавлено 09.07.15, 08:06

Цитата applegame @ 08.07.15, 11:39

git вместо собственно кодинга ковыряешься в гуглах в поисках как сделать xxx.

Вот только если в гите, скорее всего, таки можно нагуглить как что-то сделать, в hg упираешься в то, что -- низя

Сообщение отредактировано: negram - 09.07.15, 14:16

Прикреплённая картинка

Цитата negram @ 09.07.15, 07:54

остальное предлагается поправить и добавить.

Не совсем понимаю "поправить". Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()? Если да, то в thg такого не сделать. Но выбрать для коммита отдельные части diff-а (например, менял пятую и двадцатую строки, а коммитить решил только пятую) я могу.

Цитата negram @ 09.07.15, 07:54

Думаешь, стоит попробовать?

Не знаю. Я гуй считаю априори более удобным для большинства задач, ты, скорей всего, наоборот. По крайней мере в thg можно удобно сделать большинство из того, что ты записал в минусы hg record. А окно shelve выглядит как на скриншоте - перемещаешь файлы или их части направо в выбранный shelve или наоборот.

Прикреплённая картинка

Цитата negram @ 09.07.15, 07:54

Ну, во-первых, в "дочерних" проектах вся простыня из веток и коммитов не нужна

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

Цитата OpenGL @ 09.07.15, 10:21

Это примерно так - в файле я поменял foo() на bar(), но при коммите решил, что надо вписать qwe()?

Ага. Редко требуется, конечно, но бывает.

Цитата OpenGL @ 09.07.15, 10:21

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

Ошибаешься, у меня нет априоных установок на этот счёт. Diff я к примеру в 95% случаев смотрю в kompare и не понимаю соседей которые делают ревью с помощью hg diff. Просто я после нескольких лет сидения на TortoiseSVN перешел на консольный SVN-клиент. И внезапно он реально оказался более послушным. Хотя, судя по скриншотам, у тебя система в которой отсутствует автодополнение и подсветка в консоле, так-что наверное там просто выбора нет.

Цитата OpenGL @ 09.07.15, 10:21

Всё равно не вижу проблемы. Ну есть ревизии в репе, и что?

Ну я не нашел оправдания тому, чтоб во все проекты пихать баги-фичи всех проектов (к тому же их ещё и клиент видит; ну специфика у нас такая).

А не спорьте! Fossil лучше всех. Все достоинства в одном файле и никаких недостатков.

А у нас на работе щас Perforce стоит. До этого работал с Mercurial и SVN. Поначалу вообще в этом Перфорсе непривычно, сейчас немного уже привык в нем.

Вообще то, perforce, во первых стоит деньги, во вторых закрытая система, да и еще клиент-сервер.

А fossil открытая, бесплатная и распределённая. При этом, в отличии от тот же git у fossil все преимущества клиент-сервер архитектуры сохраняются.

Во, хороший холивор.
Я все еще с удовольствием держу свои проекты в mercurial. И все также сильно страдаю, когда приходится работать с чужими гитхабовскими репами. Особо бесит оторванная башка (detached head), при малейшем отклонении от свежепрочитанного мануала.

Сообщение отредактировано: applegame - 26.07.16, 15:46

cvsnt! дцать лет по мере перехода к svn, затем к git (модно), работать с скв становится всё сложнее, сами они всё медленнее, а функционал всё паршивее

Цитата wind @ 31.07.16, 00:37

сами они всё медленнее, а функционал всё паршивее

Тормознее SVN я ничего не встречал.

Цитата applegame @ 31.07.16, 06:19

Тормознее SVN я ничего не встречал.

zip архивчики медленнее

Цитата

TFS vs Git vs Mercurial vs SVN vs ...,

папочки с проектами рулят (шутка)

Сообщение отредактировано: Besha - 31.07.16, 17:06

Цитата Serafim @ 31.07.16, 12:55

zip архивчики медленнее

Ви таки считаете, что SVN - это формат архивирования?

Ну тормоза за SVN я не замечал, если честно, проработал с ним где то года 3-4. Причем я бы не сказал что маленький проект, около 1000 сотрудников. Проект очень масштабный был.
Тормозов не замечал

Цитата KILLER @ 31.07.16, 21:10

Ну тормоза за SVN я не замечал, если честно, проработал с ним где то года 3-4. Причем я бы не сказал что маленький проект, около 1000 сотрудников. Проект очень масштабный был.
Тормозов не замечал

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

Цитата applegame @ 31.07.16, 21:53

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

Ну а пример можно? В чем это выражалось например? Тупило/подвисало еще что то? Сколько человек работало с проектом?

да не подвисает, просто работает очень медленно, всё делает очень медленно, катастрофически медленно, без связи с количеством клиентов
то что в/из цвс чекаутилось и комиталось секунды, выполняет в течение минут, буквально
ну и гит, канеш, значительно пошустрее, чем свн

Цитата KILLER @ 31.07.16, 22:15

Цитата applegame @ 31.07.16, 21:53

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

Ну а пример можно? В чем это выражалось например? Тупило/подвисало еще что то? Сколько человек работало с проектом?

Даже элементарные вещи делались дольше. Но основное, наверное, это тормозные ветки.

Цитата Besha @ 31.07.16, 17:04

папочки с проектами рулят (шутка)

Вот ты смеёшься, а я своими глазами в одной конторе видел систему контроля версий в виде набора папок с именами <проект>-копия (n). По-моему при мне n до 147 доходило

Добавлено 01.08.16, 06:09

Цитата D_KEY @ 01.08.16, 00:05

Даже элементарные вещи делались дольше. Но основное, наверное, это тормозные ветки.

Может быть это исключительно из-за того, что svn - централизованное хранилище? Так-то разницы в скорости между svn commit и hg commit && hg push на примерно одинаковых по размеру проектах я не замечал.

Цитата OpenGL @ 01.08.16, 06:06

Цитата Besha @ 31.07.16, 17:04

папочки с проектами рулят (шутка)

Вот ты смеёшься, а я своими глазами в одной конторе видел систему контроля версий в виде набора папок с именами <проект>-копия (n). По-моему при мне n до 147 доходило

Как-то в одном крупном банке, на собеседовании, мне сказали, что "мы просто в файлике делаем ремарку что было сделано, чейнджлог такой". Было это где-то в 2010-м. А сам банк сейчас в TOP10 по версии banki.ru

Цитата OpenGL @ 01.08.16, 06:06

Вот ты смеёшься, а я своими глазами в одной конторе видел систему контроля версий в виде набора папок с именами <проект>-копия (n). По-моему при мне n до 147 доходило

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

Цитата wind @ 31.07.16, 23:28

да не подвисает, просто работает очень медленно, всё делает очень медленно, катастрофически медленно, без связи с количеством клиентов
то что в/из цвс чекаутилось и комиталось секунды, выполняет в течение минут, буквально
ну и гит, канеш, значительно пошустрее, чем свн

Ну у меня проект чекаутился с нуля где то минут 15. Объем проекта - около 2 гигов исходных кодов/различных скриптов и т.д. Неужто гит за секунды все это выкачает?

Цитата KILLER @ 01.08.16, 08:24

Неужто гит за секунды все это выкачает?

За секунды -- нет, но при прочих равных будет ощутимо шустрее. Да чекаут с нуля - в общем-то не особо интересно сравнивать. Вот постоянные коммиты, чекауты, переключение между ветками, мерж -- вот где git вырывается в перёд по производительности, фичастости и по качесву. Правда, остаётся позади по newbie-friendly

Сообщение отредактировано: negram - 01.08.16, 08:34

Цитата negram @ 01.08.16, 08:33

Вот постоянные коммиты, чекауты, переключение между ветками, мерж -- вот где git вырывается в перёд по производительности, фичастости и по качесву. Правда, остаётся позади по newbie-friendly

Ну с чекаутом и комитами проблем в свне особых не замечал. Сейчас работаю с перфорсом, переключится между ветками - ну пара секунд, 2 раза мышкой ткнуть. получить последнюю версию ветки - тоже быстро. По крайней мере когда я месяц не выкачивал новую, у меня это заняло несколько секунд - ну может секунд 10 Ну комиты вроде тоже быстро проходят.
Единственное в Perforce - чекаут имеет другой смысл, нежели в меркуриал или свн. Я поначалу именно в этом терялся. Для меня после SVN - чекаут был равносильно получению последней версии сборки. В Perforce все не так. Там эту функцию выполняет Get Latest Revision, а checkout снимает пометку только чтение для файлов.

Добавлено 01.08.16, 08:55
Ну и плюс для перфорса есть плагин под студи.ю. Т.е. с репозиторием можно работать прямо из студии. Что в принципе напрочь перечеркивает использование гуя, если приловчится. Но я пока не на столько его освоил. Хотя в студии плагин стоит и делать чекаут могу прямо из студии.

Цитата KILLER @ 01.08.16, 08:52

переключится между ветками - ну пара секунд

Доооолго...

Цитата Астарот @ 01.08.16, 09:01

Доооолго...

А быстро это сколько? Вот я щас посчитал - у меня вышло 3 нажатия мышкой, чтобы полностью перейти на другую ветку. Возможно там можно еще сочетания клавиш настроить.

Добавлено 01.08.16, 09:09
Причем это один из методов только. Вот есть второй - в 1 нажатие мыши. Причем разными способами - перетаскиванием, либо вызовом контекстного меню. Думаю можно настроить хот кеи, тогда еще быстрее будет. Ну пол секунды.

Цитата KILLER @ 01.08.16, 09:06

А быстро это сколько? Вот я щас посчитал - у меня вышло 3 нажатия мышкой, чтобы полностью перейти на другую ветку. Возможно там можно еще сочетания клавиш настроить.

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

Цитата Астарот @ 01.08.16, 10:12

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

Ну вот смотри, прочитал твое сообщение, засек время, переключился на перфорс, и в нем перешел на другую ветку, все вместе заняло буквально секунды 3-4. Это при том, что я еще искал где там в контекстном меню Work In this stream.

Добавлено 01.08.16, 10:27
Вот например, у нас щас есть две ветки, Dev и Release, все пишется в Dev, и потом сливается в релиз, некоторые. Так вот я комичусь, тут же секунды 2-3 уходит на то, чтобы перейти в ветку релиз, беру закомиченный ченжлист, и мержу его сходу в релиз, ну единственное я там еще пишу вменяемый комментарий, какой номер бага, кроме того, что подставляет сам перфорс(аля мерж из Dev в Release). В итоге по времени у меня уходит меньше минуты чтобы закомитится и смержить все это в релиз(если не считать написание коментариев, и разруливания конфликтов при мерже, если они есть)

Добавлено 01.08.16, 10:30
Я просто не знаю куда еще быстрее и проще У тебя есть либо графическое дерево веток, либо таблица(как ты хочешь), и по сути ты берешь выбираешь нужную ветку и говоришь - хочу в ней работать. Все, куда еще проще и быстрее то?
разве что только ты во всех сразу одновременно будешь работать - но тогда смысл в ветках напрочь теряется.

Цитата KILLER @ 01.08.16, 10:22

Вот например, у нас щас есть две ветки

И всё?

Цитата negram @ 01.08.16, 10:30

И всё?

Нет, это конкретно те, с которыми я вот прям щас работаю, а так их - 28, и это тех, для которых есть стримы. А в реале их еще больше.

Возможно, скорость из консоли будет ощущаться. В начале темы, когда шло обсуждение hg vs git, я так и не понял, почему в плюсы второго записали скорость - по субъективным ощущениям из gui первый ничуть не медленней.

Цитата OpenGL @ 01.08.16, 10:44

Возможно, скорость из консоли будет ощущаться.

Что у hg что у svn, что у perforce - у всех есть дублирующие команды. В перфорсе, когда ты что то делаешь из гуи, он прям воспроизводит эту команду в output окне, и можно посмотреть - как действие которое ты делаешь, будет выглядет ьв консоли.

Цитата KILLER @ 01.08.16, 10:22

Ну вот смотри, прочитал твое сообщение, засек время, переключился на перфорс, и в нем перешел на другую ветку, все вместе заняло буквально секунды 3-4. Это при том, что я еще искал где там в контекстном меню Work In this stream.

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

git checkout branchName

выполняется моментально.

Цитата KILLER @ 01.08.16, 10:22

Вот например, у нас щас есть две ветки, Dev и Release, все пишется в Dev, и потом сливается в релиз, некоторые. Так вот я комичусь, тут же секунды 2-3 уходит на то, чтобы перейти в ветку релиз, беру закомиченный ченжлист, и мержу его сходу в релиз, ну единственное я там еще пишу вменяемый комментарий, какой номер бага, кроме того, что подставляет сам перфорс(аля мерж из Dev в Release). В итоге по времени у меня уходит меньше минуты чтобы закомитится и смержить все это в релиз(если не считать написание коментариев, и разруливания конфликтов при мерже, если они есть)

Интересный у вас flow...

Добавлено 01.08.16, 10:50

Цитата OpenGL @ 01.08.16, 10:44

по субъективным ощущениям из gui первый ничуть не медленней.

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

Сообщение отредактировано: Астарот - 01.08.16, 10:51

Цитата Астарот @ 01.08.16, 10:49

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

Ага, вот мне дали задачу, а зафикси вот эту багу в версии 3.1 Так я щас пришел сразу и git checkout - и полез искать как branchName называется
Или ты названия всех веток наизусть помнишь?

Цитата Астарот @ 01.08.16, 10:49

Интересный у вас flow...

Обычный флоу, маленькие баги, которые точно ничего не сломают - можно выкладывать в релиз сразу. А серьезные сначало идут в Dev, потом это все тестится на Dev, и раз в две недели мержится в релиз, если все норм.

Цитата KILLER @ 01.08.16, 10:56

Ага, вот мне дали задачу, а зафикси вот эту багу в версии 3.1 Так я щас пришел сразу и git checkout - и полез искать как branchName называется
Или ты названия всех веток наизусть помнишь?

Каких - всех? Нафига мне помнить названия ВСЕХ веток? По нашему флоу есть релиз, есть девелоп, и от этого девелопа отщелкиваются фичабрэнчи, в которых делается вся работа. Уж имя бранча на котором я работаю я запомнить в состоянии, да и нафига его помнить, когда я один раз его создал, и коммичу в него, и хрен с ним как он там назван? Понадобится другая ветка - таки узнаю ее название, и сделаю чекаут. Всю дорогу миллионы программистов так делают, и ничего, не перемерли еще. Сделал работу, слил ветку в девелоп - и удалил ее нахрен, что б не мешалась.

Цитата OpenGL @ 01.08.16, 10:44

В начале темы, когда шло обсуждение hg vs git, я так и не понял, почему в плюсы второго записали скорость - по субъективным ощущениям из gui первый ничуть не медленней.

Очень мало (всего год) работал с гуями обоих, но поработав hg годик, совсем не хочется добровольно возвращаться туда
Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю

Цитата Астарот @ 01.08.16, 10:49

выполняется моментально.

Ну вот кстати аналог в перфорсе

p4 switch branchName

Цитата Астарот @ 01.08.16, 11:01

Каких - всех? Нафига мне помнить названия ВСЕХ веток? По нашему флоу есть релиз, есть девелоп, и от этого девелопа отщелкиваются фичабрэнчи, в которых делается вся работа. Уж имя бранча на котором я работаю я запомнить в состоянии, да и нафига его помнить, когда я один раз его создал, и коммичу в него, и хрен с ним как он там назван? Понадобится другая ветка - таки узнаю ее название, и сделаю чекаут. Всю дорогу миллионы программистов так делают, и ничего, не перемерли еще. Сделал работу, слил ветку в девелоп - и удалил ее нахрен, что б не мешалась.

Ааа, то есть у вас всегда 1 версия и два бренча Дев и Релиз? Или как? Я сегодня работал с одним бренчем, завтра мне сказали - вот тут нужно в другой версии, вообще в другой ветке пофиксить багу, а после завтра, вот тут вообще в левой версии для другого клиента, нужно реализовать вот такую фигушечку. И к основным веткам Dev и релиз - эти бренчи никак не относятся. Я у себя открыл в перфорсе Стримы - и вижу все которые есть. Выбрал нужный, выкачал и работаю с ним. Комитить/выкачивать новые файлы, отправлять на ревью и все остальное я могу прямо из IDE. Мне даже не нужно лезть в консоль для того что бы что то там набирать. Понимаешь?

Добавлено 01.08.16, 11:08
Более того, я даже могу все эти действия - по выбору стримов и их выкачке делать прямо из IDE.

Добавлено 01.08.16, 11:12
при прочих равных, ты набирать команду будешь даже не быстрее, чем я тоже самое буду делать в гуях. И что у меня в гуях, что у тебя в консоли - все это выполняется моментально.

Сообщение отредактировано: KILLER - 01.08.16, 11:12

Цитата negram @ 01.08.16, 11:06

Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю

А что с ним? Вроде тот же гит, вид сбоку...

Цитата KILLER @ 01.08.16, 11:07

Ааа, то есть у вас всегда 1 версия и два бренча Дев и Релиз? Или как? Я сегодня работал с одним бренчем, завтра мне сказали - вот тут нужно в другой версии, вообще в другой ветке пофиксить багу, а после завтра, вот тут вообще в левой версии для другого клиента, нужно реализовать вот такую фигушечку.

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

Цитата KILLER @ 01.08.16, 11:07

отправлять на ревью и все остальное я могу прямо из IDE. Мне даже не нужно лезть в консоль для того что бы что то там набирать. Понимаешь?

Да все я понимаю. Это сахар, который в пределе работает с той же консолью.

Добавлено 01.08.16, 11:15

Цитата KILLER @ 01.08.16, 11:07

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

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

Сообщение отредактировано: Астарот - 01.08.16, 11:15

Цитата Астарот @ 01.08.16, 11:12

А так вообще версяия - это мерж в релизную ветку. Как смержил девелоп в релиз - так и версия.

Еще тегом с номером версии ее можно обозначить.

Цитата Астарот @ 01.08.16, 11:12

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

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

Цитата Астарот @ 01.08.16, 11:12

Да все я понимаю. Это сахар, который в пределе работает с той же консолью.

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

Цитата Kray74 @ 01.08.16, 11:16

Еще тегом с номером версии ее можно обозначить.

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

Добавлено 01.08.16, 11:20

Цитата KILLER @ 01.08.16, 11:17

Ну у нас примерно так же - каждый комит по сути новая версия.

Коммит? Ты ничего не перепутал?

Цитата KILLER @ 01.08.16, 11:17

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

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

Добавлено 01.08.16, 11:21

Цитата KILLER @ 01.08.16, 11:17

Считать миллисекунды тут бессмысленно.

Так не считай - тут только ты этим занят.

Цитата Астарот @ 01.08.16, 11:12

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

О госпади какая трагедия. Целые 10 секунд. Ты тут на форуме тратишь больше в рабочее время А по факту, смотря сколько и каких файлов ты выкладываешь. Вот я когда выкладываю штук 50 файлов по 2-3 мегабайта каждый(очень большие хмл скрипты, которые иногда подвергаются изменениям), так у меня бывает и по 20 секунд скв комит делает. Лично для меня 20 секунд не критично, я же не биоробот какой. Чтоб считать секунды.

Добавлено 01.08.16, 11:26

Цитата Астарот @ 01.08.16, 11:17

Коммит? Ты ничего не перепутал?

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

Цитата Астарот @ 01.08.16, 11:17

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

Так а зачем тогда вообще спорить - если прыгать никуда не нужно? У меня на прошлой работе вообще отдельный бранч под каждого клиента был, поэтому их стало на столько много, что их было очень тяжело контролировать ,и когда их поделили на три или четыре, их осталось всеравно много! И порой дают задачи под разных клиентов, вот тогда то и начинаешь прыгать. И когда я сидел на SVN, я именно так и писал:
svn checkout branchAddress, и постоянно приходилось лезть и смотреть какое там название бранча, особенно если там всякие подчеркивания и числа, то проще вообще скопировать. Но это время.

Цитата Астарот @ 01.08.16, 11:17

Так не считай - тут только ты этим занят.

Это говорит мне человек, для которого несколько секунд - это Дооолго, и комит в 10 секунд - ужастноооо дооолго.

Цитата Астарот @ 01.08.16, 11:12

А что с ним? Вроде тот же гит, вид сбоку...

Смотри начало темы

Цитата OpenGL @ 01.08.16, 11:28

Смотри начало темы

А! Спасибо! Там аж прям крик души

Цитата Астарот @ 01.08.16, 11:12

Цитата negram @ 01.08.16, 11:06

Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю

А что с ним? Вроде тот же гит, вид сбоку...

У меня сложилось ощущение, что это SVN с примесями DCVS

Цитата negram @ 01.08.16, 11:47

У меня сложилось ощущение, что это SVN с примесями DCVS

Цитата negram @ 01.08.16, 11:06

Очень мало (всего год) работал с гуями обоих, но поработав hg годик, совсем не хочется добровольно возвращаться туда
Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я не понимаю

Я и сейчас работаю в консоли в git и hg а также в гуе hg (потому что для git вменяемого гуя не существует) и у меня строго обратные впечатления. Лично мне не нравится, что в git легко поломать локальную репу и нужно курить маны для элементарных вещей. А что тебе не нравится в hg?

Цитата applegame @ 01.08.16, 12:42

потому что для git вменяемого гуя не существует

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

Цитата applegame @ 01.08.16, 12:42

в git легко поломать локальную репу

Ну, не так уж и легко...

Цитата applegame @ 01.08.16, 12:42

Цитата negram @ 01.08.16, 11:06

Очень мало (всего год) работал с гуями обоих, но поработав hg годик, совсем не хочется добровольно возвращаться туда
Не, конечно, если я попаду туда, где есть hg как легаси, то окей -- проживём, но вот когда на нём начинают новые проекты -- такого я ч>не понимаю

Я и сейчас работаю в консоли в git и hg а также в гуе hg (потому что для git вменяемого гуя не существует) и у меня строго обратные впечатления. Лично мне не нравится, что в git легко поломать локальную репу и нужно курить маны для элементарных вещей. А что тебе не нравится в hg?

Как в git поломать локальную репу?

По поводу hg -- это я год назад что-то мог внятное сказать. Пока пользовался, постоянно вылезало - то одно он не умеет, то другое. Как только вернулся на git сразу все неудобства исчезли и совсем не хочется их вспоминать .
Навскидку, не хватало подключения нескольких удалённых репозиториев, git add -p (hg record -- сильно урезанный вариант), ну и неторопливость работы напрягала.

Цитата negram @ 01.08.16, 12:50

Как в git поломать локальную репу?

Оторвать у ветки голову При этом она, зараза, временами отрывается сама, словно ей больше заняться нечем, и начинается брейк с выковыриванием всего и вся из полудохлого состояния. Еще можно на мерже провалится в богомерзкий kdiff3, выйти из него, и обнаружить, что файлы сырцов испогенены диффами. Да много чего можно, что б жизнь медом не казалась Другое дело, что гит тут вовсе не исключение...

Сообщение отредактировано: Астарот - 01.08.16, 12:55

Цитата negram @ 01.08.16, 12:50

git add -p (hg record -- сильно урезанный вариант)

Этот разве что патчи не умеет редактировать. Но в остальном в гуях - вполне себе аналог.

Цитата negram @ 01.08.16, 12:50

Навскидку, не хватало подключения нескольких удалённых репозиториев

Это про paths в hgrc?

Цитата Астарот @ 01.08.16, 12:55

Еще можно на мерже провалится в богомерзкий kdiff3

ой-ой-ой, выкинь эту какашку

Цитата Астарот @ 01.08.16, 12:55

При этом она, зараза, временами отрывается сама

И как это выглядит?

Цитата OpenGL @ 01.08.16, 12:55

Это про paths в hgrc?

А там можно в одну репу запушить один набор веток, в другую -- другой?

Цитата OpenGL @ 01.08.16, 12:55

Но в остальном в гуях - вполне себе аналог.

Ну в гуях может быть

Цитата negram @ 01.08.16, 13:05

ой-ой-ой, выкинь эту какашку

А есть что-то более вменяемое для трехстороннего мержа? Хочу! Очень надо, дайте! Под винду...

Цитата negram @ 01.08.16, 13:05

И как это выглядит?

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

Цитата negram @ 01.08.16, 13:05

И как это выглядит?

Да чё там, вот тебе скрин с моего проекта!

Прикреплённая картинка

Курсор как раз стоит на ветке, которая никуда не слита, но у которой нет имени. Тег есть, а имени нету Как они так умудрились без меня, я не знаю, но факт об лицо.

Добавлено 01.08.16, 13:17
При этом

git branch --contains sha1

дает ровно нихрена

Цитата Астарот @ 01.08.16, 13:13

Курсор как раз стоит на ветке, которая никуда не слита, но у которой нет имени. Тег есть, а имени нету Как они так умудрились без меня, я не знаю, но факт об лицо.

Таки интересно как такое получилось и какое из этого следствие.

Цитата Астарот @ 01.08.16, 13:10

А есть что-то более вменяемое для трехстороннего мержа?

Всегда конфликты в vim-е разруливаю. Уже давно не помню, чтоб были проблемы...

Цитата negram @ 01.08.16, 13:05

А там можно в одну репу запушить один набор веток, в другую -- другой?

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

Цитата negram @ 01.08.16, 13:20

Таки интересно как такое получилось

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

Цитата negram @ 01.08.16, 13:20

и какое из этого следствие.

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

Цитата negram @ 01.08.16, 13:20

Всегда конфликты в vim-е разруливаю. Уже давно не помню, чтоб были проблемы...

И как это выглядит?

Добавлено 01.08.16, 13:26

Цитата OpenGL @ 01.08.16, 13:23

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

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

Цитата Астарот @ 01.08.16, 13:25

И как это выглядит?

Прикреплённая картинка

Цитата negram @ 01.08.16, 12:50

Как в git поломать локальную репу?

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

Цитата negram @ 01.08.16, 12:50

По поводу hg -- это я год назад что-то мог внятное сказать. Пока пользовался, постоянно вылезало - то одно он не умеет, то другое. Как только вернулся на git сразу все неудобства исчезли и совсем не хочется их вспоминать .
Навскидку, не хватало подключения нескольких удалённых репозиториев, git add -p (hg record -- сильно урезанный вариант), ну и неторопливость работы напрягала.

Хз, может ты изначально предвзято относился к mercurial? Потому что в mercurial можно подключить несколько реп. Что касается git add -p, то хотелось бы знать для чего именно ты его применял и почему hg record показался тебе сильно урезанным (чего не хватало).
Дело в том, что недостаток функциональности mercurial на поверку оказывается просто незнанием.

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

Цитата Астарот @ 01.08.16, 13:25

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

Аналог в mercurial - букмарки. Для фичебранчей - самое оно.

Кстати, в TortoiseHG есть shelve куда можно засунуть, то что НЕ хочешь коммитить, в частности можно выбрать отдельные чанки. Staging area совсем не обязателен, те же задачи можно решить и другими способами.

Добавлено 01.08.16, 14:19

Цитата KILLER @ 01.08.16, 14:11

Нда, а сколько пиара то про этот гит

Git изначально создавался для разработчиков ядра линупса и под их workflow. Зачастую гитофаны полагают, что других workflow существовать не может.
Пишешь новую фичу в opensource проект, делаешь пулл-реквест и начинается: склей коммиты в один, сделай ребейз. То есть с одной стороны возможность отслеживать историю разработки при помощи системы контроля версий, а с другой стороны эта странная любовь гитофанов к фальсификации этой самой истории. Пусть история липовая, зато дерево выглядит красяво.
Впрочем, моя основная претензия к git - кривые доки и перегруженность редкоиспользуемым обычными разработчиками функционалом.

Сообщение отредактировано: applegame - 01.08.16, 14:26

Цитата applegame @ 01.08.16, 14:05

Хз, может ты изначально предвзято относился к mercurial? Потому что в mercurial можно подключить несколько реп. Что касается git add -p, то хотелось бы знать для чего именно ты его применял и почему hg record показался тебе сильно урезанным (чего не хватало).
Дело в том, что недостаток функциональности mercurial на поверку оказывается просто незнанием.

Ммм. Нет. Если по пунктам:
- нет, предвзятого отношения не было совсем. Скорее наоборот, слышал, что о нём хорошо отзываются, и по началу даже было интересно попробовать.

- про подключение нескольких реп в прошлом году в этот же тред я получил ответ:

Цитата

То, что это будет две полных копии вместо только тех изменений, что нужны - не так уж и важно.

Так вот, мне были важны как-раз не полные копии репозиториев (вообще, с моей точки зрения, брезовая затея), а именно часть общая, часть различная. Так-что либо не я один Hg не знаю, либо там что-то изменилось за это время.

- hg record: в git есть понятие staging. Соответственно, git add -p добавляет чанк в стейджинг, который потом можно закоммитить. И я постоянно, делаю это в несколько приходов; либо по файлам, а иногда возникает необходимость остановиться и посмотреть целиком diff, чтобы понять нужно ли вот это конкретное изменение в коммите или нет. Так вот, при использовании `hg record' можно либо довести операцию до финала (до коммита), либо отменить целиком (и потом всё по новой). Если измений много, то это напрягает.

Добавлено 01.08.16, 14:33

Цитата applegame @ 01.08.16, 14:13

Пишешь новую фичу в opensource проект, делаешь пулл-реквест и начинается: склей коммиты в один, сделай ребейз.

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

Добавлено 01.08.16, 14:34

Цитата applegame @ 01.08.16, 14:13

Пусть история липовая, зато дерево выглядит красяво.

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

Цитата negram @ 01.08.16, 14:31

- про подключение нескольких реп в прошлом году в этот же тред я получил ответ:

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

Цитата OpenGL @ 01.08.16, 14:38

Тот диалог был про выкачивание конкретных веток, и я тогда не знал, как оно делается

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

Цитата negram @ 01.08.16, 14:31

- hg record: в git есть понятие staging. Соответственно, git add -p добавляет чанк в стейджинг, который потом можно закоммитить. И я постоянно, делаю это в несколько приходов; либо по файлам, а иногда возникает необходимость остановиться и посмотреть целиком diff, чтобы понять нужно ли вот это конкретное изменение в коммите или нет. Так вот, при использовании `hg record' можно либо довести операцию до финала (до коммита), либо отменить целиком (и потом всё по новой). Если измений много, то это напрягает.

Для этого есть shelve. Там наоборот, указываешь что не хочешь коммитить.

Цитата negram @ 01.08.16, 14:31

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

Цитата negram @ 01.08.16, 14:31

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

Эти конвульсии и есть настоящая история, а не то что выглядит красиво. Впрочем, тут скорее дело вкуса. Так что спорить не буду.

Добавлено 01.08.16, 15:15

Цитата negram @ 01.08.16, 14:40

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

Что именно невозможно? Клонировать не всю репу, а отдельный бранч? Это как раз можно.

Цитата applegame @ 01.08.16, 15:10

Что именно невозможно? Клонировать не всю репу, а отдельный бранч? Это как раз можно.

Это не совсем то, что он хочет.

Добавлено 01.08.16, 15:48
Правда, возможно, что с букмарками можно сделать то, что ему надо. В конце-концов они даже в документации называются аналогом гитовских "веток".

Цитата negram @ 01.08.16, 12:50

Как в git поломать локальную репу?

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

Цитата wind @ 01.08.16, 22:12

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

Вот уж действительно, откуда взяться локальным изменениям, если изменяется только одна xsd-схема?

обновиться, при локальных изменениях как-раз просто:
git stash
git pull
git stash pop

Так git же сам пишет в таких случаях, что для того, чтобы он мог сделать pull надо на выбор сделать или commit или stash

Цитата

git format-patch --stdout > lol.patch

Цитата negram @ 02.08.16, 06:24

git stash

Цитата amk @ 02.08.16, 13:29

надо на выбор сделать или commit или stash

Цитата wind @ 01.08.16, 22:12

ничего не меняю

"ничего не меняю" - это значит, что у меня нет никаких локальных изменений

Цитата wind @ 03.08.16, 00:00

"ничего не меняю" - это значит, что у меня нет никаких локальных изменений

Значит ты чего-то не договариваешь. Если нет изменений, git pull проходит всегда и без вопросов.

Цитата wind @ 03.08.16, 00:00

"ничего не меняю" - это значит, что у меня нет никаких локальных изменений

Включая форматирование кода, которое в некоторых средах происходит автоматически? То есть ты ничего не менял, но

Цитата

f()
{
...
}

превратилось в

Цитата

f(){
...
}

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

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

Добавлено 03.08.16, 18:03

Цитата Астарот @ 03.08.16, 06:22

форматирование кода, которое в некоторых средах происходит автоматически

а за такое склонен вообще расстреливать, уж точно не страдаю

Цитата wind @ 03.08.16, 18:02

ничего - это ничего, абсолютно, от слов никак, нигде и никоим образом

не-прав-да

Цитата wind @ 03.08.16, 18:02

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

Учитывая, что гит используют тысячи прогеров по всему миру, и учитывая, что описанный баг сводит ценность системы к нулю... В общем, думаю, ты заблуждаешься, и таки что-то все же происходит. Дифф различия показать ведь должен? Хотя бы изменившиеся переводы строк, что может быть совершенно не очевидно!

Цитата wind @ 03.08.16, 18:02

а за такое склонен вообще расстреливать, уж точно не страдаю

Я просто предположил. Еще из вариантов изменившиеся переводы строк. Или покорравтившиеся русскоящычные фразы - у меня пару раз было так, что какая-то какашка умудрилась превратить русский текст в файле в кракозябры совершенно неожиданным образом, оставив по себе только вопрос: "Какая сука бросила валенок на пульт?!"

Цитата Астарот @ 03.08.16, 18:19

Дифф различия показать ведь должен? Хотя бы изменившиеся переводы строк, что может быть совершенно не очевидно!

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

Добавлено 04.08.16, 00:10

Цитата Астарот @ 03.08.16, 18:19

сводит ценность системы к нулю...

оно и так к нулю близко, по крайней мере с свн был один гемор - меееееееееедленно, а тут столько всего нового и всё не в кассу. я только 2 раза в жизни видел, как переходили от одной скв к другой действительно по какой-то причине, а не из-за того, что это модно, первый раз cvs->starteam из-за транзакций (сетка нестабильная), другой раз cvs->svn из-за трафика (не знаю, не проверял, говорили, что svn сильно меньше кушал).

а еще бесконечно радует в гите необходимость обновлять локал (хотя мне категорически не надо обновляться!) в случае, когда я поменял файлик a, а в удаленном репозитории поменялись b и c. вот дальше никак, <вц>, апдейт жизненно необходим!

Сообщение отредактировано: wind - 04.08.16, 00:12

Цитата wind @ 04.08.16, 00:00

различий море, серьезных таких простыней и в куче файлов. о том и речь.

Так это не гит виноват. Ровно то же самое будет с другой vcs.

Цитата OpenGL @ 04.08.16, 06:18

Ровно то же самое будет с другой vcs.

расскажи, как такое сотворить, к примеру, с svn

Судя по тому, что ты рассказал - точно так же

Цитата OpenGL @ 04.08.16, 17:21

Судя по тому, что ты рассказал - точно так же

ну, ежели не знаешь, зачем тогда пургу мести? точно так же не получится, выкачанное из svn, как ни странно, не "протухает"

wind, то есть ты считаешь, что файлы в локальной репе кем то изменяются, даже при не запущенном git?

Цитата wind @ 04.08.16, 22:01

точно так же не получится, выкачанное из svn, как ни странно, не "протухает"

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

Добавлено 05.08.16, 05:44
Да и откуда ты знаешь, что svn на этом же проекте не портит? У тебя есть текущая копия этого же проекта в svn?

А какова вероятность следующего сценария?
wind клонирует репу, после чего приходит negram и изменяет историю удаляет то, что он считает "конвульсиями, происходящими в голове разработчика". После чего wind не может нормально обновиться.

Сообщение отредактировано: applegame - 05.08.16, 10:45

1. Нулевая negram никогда не изменяет то, что запушено, потому-что это плохо. Нормальный разраб тоже, как минимум, потому что просто это не делается.
2. Хватит уже завидовать

Сообщение отредактировано: negram - 05.08.16, 10:47

Цитата negram @ 05.08.16, 10:46

1. Нулевая negram никогда не изменяет то, что запушено, потому-что это плохо. Нормальный разраб тоже, как минимум, потому что просто это не делается.
2. Хватит уже завидовать

1. Ну это может быть у форумного negram, а у описаного мной может быть и ненулявая. Правда, в любом случае, git тут явно не причем.
2. А чему я, по-твоему, завидую? Править историю можно и в mercurial, но я не люблю это делать. И когда меня заставляют это делать в git я раздражаюсь.

Сообщение отредактировано: applegame - 05.08.16, 10:52

Цитата OpenGL @ 05.08.16, 05:43

Да и откуда ты знаешь, что svn на этом же проекте не портит?

заколдованный проект? а что, отличная версия

Добавлено 05.08.16, 16:19

Цитата applegame @ 05.08.16, 10:43

А какова вероятность следующего сценария?
wind клонирует репу, после чего приходит negram и изменяет историю удаляет то, что он считает "конвульсиями, происходящими в голове разработчика". После чего wind не может нормально обновиться.

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

Цитата wind @ 05.08.16, 16:16

но вот вопрос - это вообще скв? с такими возможностями?

Да, скв. Рассчитывающая на то, что оператор понимает что делает. Ну лично для меня естественно, что СКВ пользуются программисты и обезьян среди них быть не должно. Конкретно про push --force, это отключается на раз два, хотя если это действительно кто-то использовал, он должен как минимум объяснить свои серьёзные основания для этого. Если такое использовали не раз, то это повод сделать предположение, что что-то не в порядке.
А сама возможность редактирования истории - чрезвычайно полезная. Локальной истории, разумеется.

Цитата negram @ 05.08.16, 19:59

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

А что означает фраза: " сама возможность редактирования истории" ? Я просто не понимаю что такое история в гите или еще где то? Это как? Типа сначала сделал, выложил, потом спустя некоторое время что то поправил в дескрипшине? Или как?

Цитата negram @ 05.08.16, 19:59

Ну лично для меня естественно, что СКВ пользуются программисты и обезьян среди них быть не должно.

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

Цитата negram @ 05.08.16, 19:59

Локальной истории, разумеется.

Нихрена не локальной. Когда меня просят сделать squash и rebase, мне приходится это делать не в локальной истории, а в моем форке на гихабе. Пока они там чешут репу по поводу моего пулл-реквеста, я успеваю добавить еще какие-то изменения для своих целей. Тут опа, давай-ка чувак, правь свою историю, и заверте... оторванные бошки, курение мануалов, проклятия в сторону git. В конечном итоге я пришел к известному методу: скопируй все свои изменения, похерь локальную копию, похерь форк, сделай форк заново, клонируй его к себе, скопируй свои изменения, коммит, пуш, пулл-реквест, профит.

Сообщение отредактировано: applegame - 06.08.16, 06:09

Цитата applegame @ 06.08.16, 06:03

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

я делаю ветку новую и переношу туда изменения

Добавлено 06.08.16, 19:40

Цитата wind @ 05.08.16, 23:26

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

Если бы я не знал, что это говорит опытный, я бы подумал, что это говорит новичок-максималист.
Как минимум два раза в моей практике бывали случаи, когда в репозитории оказывалось то, чего там не должно было быть ни в коем случае и как-раз для таких случаев есть возможность rebase, push --force. То, что ваши админы ниасилили запретить такую операцию всем подряд говорит лишь об их квалификации. Впрочем, что именно у вас там было таки никакой информации не поступило, только "аааа, оно мне всё сломало".

Добавлено 06.08.16, 19:47

Цитата KILLER @ 05.08.16, 20:40

ипа сначала сделал, выложил, потом спустя некоторое время что то поправил в дескрипшине?

Ну, можно поправить commit-message, можно объединить несколько коммитов, можно добавить что-нибудь в последний коммит, либо вырезать коммит нахрен.
Все эти действия делаются легко, если коммиты не были отправлены в общий репозиторий. При очень острой необходимости, есть возможность это сделать и в удалённом, только делать это строжайше запрещается.

Сообщение отредактировано: negram - 06.08.16, 19:47

Цитата negram @ 06.08.16, 19:35

я делаю ветку новую и переношу туда изменения

Новая ветка это само собой. Для пулл-реквеста приходится форк делать. Дпугих способов я не знаю.

Цитата applegame @ 06.08.16, 21:12

Для пулл-реквеста приходится форк делать.

Это-то да. Но зачем предыдущий форк херить?

Цитата negram @ 06.08.16, 19:35

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

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

У нас с git-ом такая схема.
Есть master ветка.
Каждый, кто хочет девелопить - отстреливает себе ветку. Свою. Личную. Персональную. Никто туда больше не чирикает.
В мастер ничего не мерджится просто так. Через gt stash. Создается пул реквест, ревьюеры должны поглядеть на чейндж и если все ок - approve. Или reject. В этом же gt stash оно мерджится. Очень удобный инструмент.

Цитата Бобёр @ 07.08.16, 17:08

В мастер ничего не мерджится просто так.

У нас вообще отдельный бот в мастер маржит, который сначала тесты прогоняет, конфликты проверяет

Автоматика. Ну, правда, с конфликтами в gt stash ты тоже не замерджишь, это факт. А вот тесты у нас только билд сервер работает, т.е. уже после мерджа.

Вообще надо автоматизировать до состояния "пул реквест реджектится если code coverage после работы теста меньше 100%"

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

Я не читал всю тему - слишком много и скучно.

Я по работе использую TFS. В общем TFS - отстой.
Знаю, что по работе AQL использует GIT - тоже отстой.

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

У ГИТа ветки не настоящие ветки - всего-лишь теги. И мои коллеги теряли ветки просто потому-что у них терялись головные Чекины. А у меркуриала настоящие ветки, доступ к которым всегда можно получить.

И чисто субъективно меркуриал дифф делает обоснованнее

Цитата Leprecon @ 14.12.16, 21:09

Я люблю Меркуриал.

Меркуриал тема. Я на прошлой работе его познал, лично для себя. У нас был SVN, но у себя на машине я юзал Mercurial, мне он тоже понравился.

Цитата Leprecon @ 14.12.16, 21:09

В общем TFS - отстой.

Обоснуй Я пока что не видел ничего удобнее. Хотя, признаю, начиная с VS2012 мелкомягкие перемудрили и стало хуже. Никак не могу привыкнуть с новому Team Explorer'у

Цитата Leprecon @ 14.12.16, 21:09

У ГИТа ветки не настоящие ветки - всего-лишь теги. И мои коллеги теряли ветки просто потому-что у них терялись головные Чекины. А у меркуриала настоящие ветки, доступ к которым всегда можно получить.

Причем у меркуриала кроме насточщих веток есть и аналог гитовских псевдоветок - букмарки.