Статья наверное и хорошая, но твой бложик называется «OPENSOURCE В ЗАМЕТКАХ - Путь к пониманию», а ты убрал копирайты wordpress в футере ... не Ъ.

...с перлом в зависимостях

Мы явно что-то разное под «локальными бранчами» понимаем.

перл нужен, а пистон — нет.

> Статья наверное и хорошая, но твой бложик называется «OPENSOURCE В ЗАМЕТКАХ - Путь к пониманию», а ты убрал копирайты wordpress в футере ... не Ъ.

Вы еще скажите, что держать sshd на нестандартном порту не Ъ.

> спасибо, очень познавательно! а что такое bash, vim и emacs?

Таки доставил, чертяка.

Перл, это не зависимость. Это жизнь.

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

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

Зачем вы эти прописные истины напомнили? Что хотели доказать?

> Перл, это не зависимость. Это жизнь.

+1

вот например на нокии н800 в стандартной поставке он стоит, хотя все что можно порезано

>Да, большинство пользователей постоянно тратят кучу времени на то что элементарно автоматизируется.

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

КГ/АМ, дропбокс в разы удобнее

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

а об этом в статье нифига нет

PS: /me держит в git файлы конфигов давно, в совокупности с парой скриптов что попутно удерживают права на файлы в правильном виде

А вот резонный вопрос - SVN не сможет «существенно облегчить ваши мучения из-за копирования ваших конфигурационных файлов на новые компьютеры.» ?

а вот расскажи как ты будешь в svn держать кучу ~/.файлов? для этого у тебя весь образ /home/user должен в нем лежать и море игноров прописано

Странно, что в тред ещё не нагрянул хвостострел с ртутью и петоном.

>а чем ртуть принципиально лучше гита кроме того что на одну букву меньше чепятать в консольке?

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

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

У IBM-а появился конкурент по написанию статей школьниками-неосиляторами для школьников-неосиляторов

полностью согласен

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

Это у меня не работает

Пытался /etc запихнуть в меркуриал. Так он похоже не сохраняет нормально исхоные атрибуты. Какой то абстрактный апач не запускается после восстановления этков из репозитария...

Это как то лечится?

Я так понимаю это следствие нового тренда хранения /etc в git'е?

>а по теме - гит неплох пока используешь только 2-3 команды, когда начинается что-то посложнее, то можно все угрохать безвозвратно.
4.2, там удаленные коммиты хранятся 2 недели, можно из лога восстановить всё

+1 не нужно, есть Mercurial +10...0.. за аватар

>git ... более глобально и __значительно__ функционально
Пруфы будут? Или ты почерпнул это из статьи Why git is better than X? Приведи пример того, что умеет жид и не умеет ртуть (кроме полного отслеживания удаленных букмарков, которое сделают этим летом и которое скорей баг, чет отсутствие фичи).

Отличная идея, я для этого ваял скрипт с бэкапом по крону. Срочно беру на вооружение, спасибо.

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

Ты любую функциональность, выходящую за рамки базовой называешь костылями?

Объяснять, кажется, бесполезно. Гит скоро перегонит емакс по количеству мифов, если еще не.

Нет, а что?

Как тогда ты отличаешь костыль от некостыля? Что в данном случае было бы некостылем?

Пруфы будут? Или ты почерпнул это из статьи Why git is better than X? Приведи пример того, что умеет жид и не умеет ртуть (кроме полного отслеживания удаленных букмарков, которое сделают этим летом и которое скорей баг, чет отсутствие фичи).

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

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

> У хабра появился конкурент по написанию статей школьниками-неосиляторами для школьников-неосиляторов.

Fxd во имя Волка

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

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

Ну и доменчик у вас с имейлом...

ashep - someone who chases chickens around...

в неочевидном состоянии

Вершина или достижима из множества входных точек (бранчей и тегов) или нет, ничего неочевидного тут нет. Если вершина недостижима, то это или мусор, или кто-то накосячил. Чтобы чей-то косяк не стал фатальным, есть подушка безопасности в виде гц/рефлога. Результат таков - в гит можно творить всё что угодно, совершенно не боясь угробить данные, при этом гц/рефлог не маячат перед глазами постоянно.

очередной абстракции работающей уже выше основной сущности

Почему выше?

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

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

> Почему выше?

Потому что по смыслу это история изменения истории.

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

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

Звучит как стрельба из пушки по воробьям.

> git и hg - для убогих анацефалов, онанирующих на «распределенность», нормальные люди используют только svn.

Вы видимо явно использовали только TFS в своей жизни.

Это вам кажется.

> А детали в том, что меркурий на петоне. А жид на православном Це.

Питон вполне православен.

> Оказывается, в системах контроля версий можно хранить не только код, но еще и конфиги! Мое мировоззрение разрушено и все шаблоны разорваны.

Для пришедших с винды это открытие, между прочим.

Но зачем?? Есть же nis+, в конце концов

> Пытался /etc запихнуть в меркуриал. Так он похоже не сохраняет

нормально исхоные атрибуты. Какой то абстрактный апач не запускается

после восстановления этков из репозитария...

Это как то лечится?

metastore
http://david.hardeman.nu/software.php

Скажи как мне в hg реализовать такой workflow:

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

В git такое делается просто: git push -f

Как такое сделать в hg без костылей?

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

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

таки оставлю здесь такой вариант

Извини, что грубовато вышло, накипело.

Внедрял как раз ртуть, чтобы хомячкам в небольших проектах было проще и они сразу стартовали, хомячки встали в позу «давайте git он круче», кончилось тем что уже 2 месяца они никак не могут освоится с функционалом и подняли локальный svn для себя. А нормальная часть персонажей юзает и то и другое в зависимости от задачи и всё у них хорошо.

Буду рад услышать рассказ о необходимости функционала git для хранения конфигурационных файлов.

зачем git, если есть fossil?

Зачем boo32 если есть анонимус?