Пал последний оплот Mercurial (hg)

в битбакете же нет меркуриала уже лет этак 5?

Ну и выкинь ты нахрен эти rpm и демьян. Они бесполезны. Тебе гитлаб поднять надо или на rpm дрочить?

так они есть, лол:

baseurl=https://packages.gitlab.com/gitlab/gitlab-ce/el/8/$basearch

в битбакете же нет меркуриала уже лет этак 5?

Мы не про меркуриал говорим.

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

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

И он отлично работает как DVCS. Хоть через почту, хоть через гитлаб.

Итить, а те же самые пакеты, завёрнутые в RPM, будут одобрены.

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

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

Я может еще одну Америку открою, но образы можно тянуть НЕ ТОЛЬКО с докер-хаба. Можно их оттуда вообще не тянуть.

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

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

щитоа

Импортозамещение ответственности, так и запишем.

Никто ни за что не отвечают, и все ищут, на кого её спихнуть.

«Сертифицированные» дистрибутивы из гигабайт чужих сорцов без ревью.

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

Ну, например, чтобы узнать для чего(и когда) был влеплен вот в это место вот этот занятный костыль?

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

Тебе кажется. В Git нет понятия «сервера».

ну это не значит, что две локальных рабочих копии можно смержить мимо git+ssh://, но надо проверить как оно сейчас

ну это не значит, что две локальных рабочих копии можно смержить мимо git+ssh://

Это значит именно это. Оно всегда так было :)))

Stack overflow от 2012 года: https://stackoverflow.com/questions/10603671/how-to-add-a-local-repo-and-treat-it-as-a-remote-repo

Критики git примерно так же разбираются в git, как критики systemd - в systemd.

не подходит для финальных_правок_гггг_мм_дд_вася_точно!!1_23_fix.rar

не подходит для финальных_правок_гггг_мм_дд_вася_точно!!1_23_fix.rar

Да мы уже поняли что ты лалка анскильная, заканчивай этот цирк.

Тут давеча чувак в systemd блобы нашел. Вы не в одной команде работаете?

в бинарных логах пади?

Бэкапы? Нет, не слышали. Но виноват, конечно же, SVN.

Бэкапы? Нет, не слышали. Но виноват, конечно же, SVN.

Прелесть Git в том что у тебя любая актуальная репа – бекап.

Преимущества Mercurial (лично для меня)

1. Более понятное и внятное описание команд. Например, есть команда hg update -r..., которая просто обновляет файлы до выбранной ревизии. В git для этого я использую git checkout, при этом он пишет какую-то неведомую хрень про отсоединённую голову... Некоторые действия в git документированы настолько фигово, что проще залезть в интернет, чтобы найти, например, как отменить все изменения в выбранном файле. Но это, конечно, вкусовщина и дело привычки...

2. Более прикольная и удобная вещь — челвекочитаемый номер ревизии. Да, я в курсе, что он может быть разным в разных клонах репозитория, но если я работаю только со своим клоном, проще писать hg update -r 322. Это реально удобная вещь, которой не хватает в git

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

4. В hg есть «вечно живущие» ветки и букмарки (аналог гитовских веток). Можно долго спорить, как правильно и не лучше ли один вариант, но в любом случае наличие возможностей лучше их отсутствия.

5. Mercurial написан на божественном Питоне Ладно, этот пункт мы пропустим.

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

7. Тут я не придумал, что написать, поэтому напишу своё резюме. В целом, в настоящее время каких-либо киллер-фич у меркуриала по сравнению с гитом нет, недостатки и определённые достоинства имеются. Я им пользуюсь, поскольку более привычен. Гит писался гиками для гиков.

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

Дальше читай, там написано.

Просто прочитать код и понять как работает уже не?

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

Прочитал FAQ, всё равно не понял. Более того, там написано, что если ты не понимаешь, зачем оно нужно, то оно тебе не нужно.

В git для этого я использую git checkout

А надо git reset.

Бэкапы? Нет, не слышали. Но виноват, конечно же, SVN.

Да, виноват SVN, он загубил множество проектов с открытым кодом, которые устарели и потеряли актуальность, а их администраторы, которые держали self-hosted решения взяли и ушли в небытие.

Там где из локальной копии Git можно было развернуться или админ прозеркалировал репозиторй на GitHub, BitBucket или Gitorious (помнит кто такой сервис, купленный GitLab’ом, на котором часто хостились Qt-проекты?), там сегодня всё целое независимо от того активен админ/создатель или нет.

А вот там где был SVN, сегодня в большинстве случаев кое-как развёрнутая тыква без истории, либо без нужных и актуальных веток кода. Далеко ходить не надо – ныне почивший Google Code, получить историю проекта с которого можно лишь если ты сотрудник Google и знаешь один трюк (я его тоже знаю).

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

Это так не работает. В коде не описана интенция.

О! Спасибо, что расписал.

Преимущества Mercurial (лично для меня)

1. Более понятное и внятное описание команд. Например, есть команда hg update -r…, которая просто обновляет файлы до выбранной ревизии. В git для этого я использую git checkout, при этом он пишет какую-то неведомую хрень про отсоединённую голову… Некоторые действия в git документированы настолько фигово, что проще залезть в интернет, чтобы найти, например, как отменить все изменения в выбранном файле. Но это, конечно, вкусовщина и дело привычки…

Есть такое. git-checkout который делает вообще всё на свете – это и правда мрак и хтонь.

2. Более прикольная и удобная вещь — челвекочитаемый номер ревизии. Да, я в курсе, что он может быть разным в разных клонах репозитория, но если я работаю только со своим клоном, проще писать hg update -r 322. Это реально удобная вещь, которой не хватает в git

Ммм… возможно. Тут у меня нет предпочтений как в одну, так и в другую сторону.

3. TortoiseHg прекрасен, все более-менее сложные операции делаю через него. Да, у гита тоже есть гуишные морды, но gitk выглядит убого, а остальные… Нет единого стиля, короче.

Гуй в VCS – это что-то странное. Как я выше писал, magit мне хватает за глаза, и то только потому что он в емаксе уже есть и не нужно открывать терминал.

4. В hg есть «вечно живущие» ветки и букмарки (аналог гитовских веток). Можно долго спорить, как правильно и не лучше ли один вариант, но в любом случае наличие возможностей лучше их отсутствия.

Если я не ошибаюсь, «ветки» в hg – это аналог тэгов в git.

5.Mercurial написан на божественном ПитонеЛадно, этот пункт мы пропустим.

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

Git ничего не удаляет в принципе, пока ты отдельно не попросишь (git gc). Все действия, которые ты делаешь (кроме git gc), только добавляют в репозитарий. Если ты случайно запорол ветку, её всегда можно достать из git reflog.

7. Тут я не придумал, что написать, поэтому напишу своё резюме. В целом, в настоящее время каких-либо киллер-фич у меркуриала по сравнению с гитом нет, недостатки и определённые достоинства имеются. Я им пользуюсь, поскольку более привычен. Гит писался гиками для гиков.

И git и hg – это попытка скопировать BitKeeper, на который в начале-середине нулевых многие подсели, включая Торовалтоса и авторов Mercurial, но – вот те раз! – он был проприетарным и за бабло, что очень сильно ограничивало список людей, готовых участвовать в проектах с ним. Там даже была история, как автор BitKeeper угрожал засудить работодателя одного из оригинальных разрабов Mercurial, потому что лицензия BK в том числе требовала не работать над конкурирующими продуктами.

Напоминает спор об архиваторах в начале 1990-х: ARJ или ZIP.

Прочитал FAQ, всё равно не понял.

https://gameoftrees.org/index.html Первая строка!!

Game of Trees (Got) is a version control system which prioritizes ease of use and simplicity over flexibility.

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

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

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

Так его и опенбсдшники осилить не могут. Их код просто никто не читает.

Гуй в VCS – это что-то странное. Как я выше писал, magit мне хватает за глаза, и то только потому что он в емаксе уже есть и не нужно открывать терминал.

Почему странное, это дело удобства... Ветки подсвечивются цветом, сразу видно, что входит в коммит... Кстати, hg outgoing — ещё одна удобная штука (не знаю, какой аналог в гит, наверняка есть), показывает, что будет запушено в удалённый репозиторий

Если я не ошибаюсь, «ветки» в hg – это аналог тэгов в git.

тэги и в hg есть. Ветки (branches) — это хранимое с каждым коммитом название ветки, можно легко «восстановить» историю коммитов в каждой конкретной ветке.

Git ничего не удаляет в принципе, пока ты отдельно не попросишь (git gc). Все действия, которые ты делаешь (кроме git gc), только добавляют в репозитарий. Если ты случайно запорол ветку, её всегда можно достать из git reflog.

да, про это я слышал. Я про то, что в меркуриале все сообщения понятные, и если какое-то действие потенциально опасно, он предупреждает. А, ну и ещё есть фазы (это когда поведение немного меняется, если коммит уже запушен/запуллен в удалённый репозиторий). Не киллер-фича, но помогает не превратить репу в форшмак :)

А надо git reset.

https://git-scm.com/book/ru/v2/Инструменты-Git-Раскрытие-тайн-reset

Ну как я и писал, см. п. 1 :)

Game of Trees (Got) is a version control system which prioritizes ease of use and simplicity over flexibility.

ease of use and simplicity over flexibility

Ну так если бы это ещё подтверждалось фактами. Но заглянув в документацию я не обнаружил там ни ease of use ни simplcity. Ничем он не проще обычного гита. Так что это набор слов, которые ничего не значат.

и еще clean -fd, а вот кто не лазия в гугл помнит как убрать из коммита изменения в трекиуемом файле без использования .gitignore и не сбрасывая самих изменений?

Ну вот для этого лучше как раз использовать gui. Но предпочтительно интегрированный в твой редактор кода а не отдельный.

это понятно, но бывают случаи когда ты в консоли и кругом никого

Ты про это?

cp файл{,.bak} ; git checkout файл ; mv файл{.bak,}

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

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

Что еще придумаете?

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

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

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

git update-index --assume-unchanged app/dir/config.file

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

Гуй в VCS – это что-то странное. Как я выше писал, magit мне хватает за глаза, и то только потому что он в емаксе уже есть и не нужно открывать терминал.

Почему странное, это дело удобства… Ветки подсвечивются цветом, сразу видно, что входит в коммит…

Не, я именно про отдельностоящие гуи для VCS. Подавляющее большинство пользуются встроенными в IDE/редактор (как magit). Но т.к. hg не слишком популярен, то наверное в редакторах с этим туго. Хз.

Кстати, hg outgoing — ещё одна удобная штука (не знаю, какой аналог в гит, наверняка есть), показывает, что будет запушено в удалённый репозиторий

Кстати, нету :(

Гугл принёс мне git log --branches --not --remotes=origin, но он покажет вообще всё что есть в твоей копии, но отсутствует на сервере. Например, десяток старых веток, которые ты начал и забросил.

Если я не ошибаюсь, «ветки» в hg – это аналог тэгов в git.

тэги и в hg есть. Ветки (branches) — это хранимое с каждым коммитом название ветки, можно легко «восстановить» историю коммитов в каждой конкретной ветке.

Типа, ветка является свойством коммита? Странная тема, но так тоже можно, ок.

Git ничего не удаляет в принципе, пока ты отдельно не попросишь (git gc). Все действия, которые ты делаешь (кроме git gc), только добавляют в репозитарий. Если ты случайно запорол ветку, её всегда можно достать из git reflog.

да, про это я слышал. Я про то, что в меркуриале все сообщения понятные, и если какое-то действие потенциально опасно, он предупреждает. А, ну и ещё есть фазы (это когда поведение немного меняется, если коммит уже запушен/запуллен в удалённый репозиторий). Не киллер-фича, но помогает не превратить репу в форшмак :)

Короче, я тебя понял. В hg есть много мелких quality of life штук, которые полезно иметь.

Если оно на пихтоне сляпано, то хорошо, что померло.