Стандарт де факто — git. Давно ли?⁠⁠

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

я начинал пользоваться софтиной SmartGit еще когда она называлась SmartGitHg) и да, интерфейс был унифицирован)

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

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

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

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

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

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

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

очень жаль меркуриал. имхо он лучше. но гитхаб не оставил ему шансов

а bitbucket разве не поддерживает mercurial?

Гит насколько я помню был бесплатной альтернативой платных систем контроля версий. Собственно из-за этого он и стал так популярен.

Линус не просто пользуется, он его придумал.

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

(С самим Линуксом тоже примерно так было)

У вас какие-то неверные представления о работе гита.

Все коммиты на ветке разработчика видно после слияния, к как и сам коммит слияния. Разработчик, конечно, может перед закачиванием своей работы на сервер (push) свою ветку упростить до одного коммита, но зачем?

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

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

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

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

Гит - видим слияние и ограниченную историю (что разработчик запушил).
Меркуриал - видим всю разработку второстепенной ветки и только потом ее слияние.  Т.е. мы можем переключиться на коммит состояния у разработчика. 

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

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

По  мне причины такие:

1. github

2. git был самым быстрым из распределенных и бесплатных. Если в mercurial попадали большие бинарные файлы, становилось грустно. А разрабатывая сайтики и .т.п. картинки, pdf хотелось положить под систему контроля версий.

3. branch и merge быстр и прост

4. продвижение популярными OpenSource проектами

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

так все данные закрытые. как вообще собрать инфу например по селфхостингу гитлаба?

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

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

Есть ли вероятность появления какой-нибудь конкурентной альтернативы?

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

имхо, ci/cd гитлаба приятнее чем github actions

кажется в начале был и не только потенциал, но и по факту аудитория

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

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

Why did you create Git?

Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM’s with a passion. But then BitKeeper came along and really changed the way I viewed source control. BK got most things right and having a local copy of the repository and distributed merging was a big deal. The big thing about distributed source control is that it makes one of the main issues with SCM’s go away – the politics around “who can make changes.” BK showed that you can avoid that by just giving everybody their own source repository. But BK had its own problems, too; there were a few technical choices that caused problems (renames were painful), but the biggest downside was the fact that since it wasn’t open source, there was a lot of people who didn’t want to use it. So while we ended up having several core maintainers use BK – it was free to use for open source projects – it never got ubiquitous. So it helped kernel development, but there were still pain points.

That then came to a head when Tridge (Andrew Tridgell) started reverse-engineering the (fairly simply) BK protocol, which was against the usage rules for BK. I spent a few weeks (months? It felt that way) trying to mediate between Tridge and Larry McVoy, but in the end it clearly wasn’t working. So at some point I decided that I can’t continue using BK, but that I really didn’t want to go back to the bad old pre-BK days. Sadly, at the time, while there were some other SCM’s that kind of tried to get the whole distributed thing, none of them did it remotely well. I had performance requirements that were not even remotely satisfied by what was available, and I also worried about integrity of the code and the whole workflow, so I ended up just deciding to write my own.

Работал на америку с TortoiseSVN , насколько удобная система, что до сих пор вспоминаю каждый раз работая с git. Гит - отрыжка линуксоидов, непонятно почему он лидирует....

Why did you create Git?

Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM’s with a passion. But then BitKeeper came along and really changed the way I viewed source control. BK got most things right and having a local copy of the repository and distributed merging was a big deal. The big thing about distributed source control is that it makes one of the main issues with SCM’s go away – the politics around “who can make changes.” BK showed that you can avoid that by just giving everybody their own source repository. But BK had its own problems, too; there were a few technical choices that caused problems (renames were painful), but the biggest downside was the fact that since it wasn’t open source, there was a lot of people who didn’t want to use it. So while we ended up having several core maintainers use BK – it was free to use for open source projects – it never got ubiquitous. So it helped kernel development, but there were still pain points.

That then came to a head when Tridge (Andrew Tridgell) started reverse-engineering the (fairly simply) BK protocol, which was against the usage rules for BK. I spent a few weeks (months? It felt that way) trying to mediate between Tridge and Larry McVoy, but in the end it clearly wasn’t working. So at some point I decided that I can’t continue using BK, but that I really didn’t want to go back to the bad old pre-BK days. Sadly, at the time, while there were some other SCM’s that kind of tried to get the whole distributed thing, none of them did it remotely well. I had performance requirements that were not even remotely satisfied by what was available, and I also worried about integrity of the code and the whole workflow, so I ended up just deciding to write my own.

Автору пожелание. Если вставляете картинки, то нужно как-то позаботиться об их качестве, а то выглядит грустно

Во, нашел https://www.linuxjournal.com/content/git-origin-story для тех кому интересно узнать историю появления

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

Когда-то ртуть была наиболее удобной системой, с понятным набором команд. Гит тогда воспринимался как что-то инопланетное, совсем отличающееся от цвса/свна. Но сейчас да, гит победил.

почему-то вспомнилось далекое https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...