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

Цитата 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