LINUX.ORG.RU

Плагины для Git vs. плагины для Mercurial

 , , ,


1

2

Объясните, пожалуйста, разницу во «взглядах» Git и Mercurial на расширения.

Я не разработчик, в IT вообще не работаю. Про обе системы пока что читал, но не пользовался.

С Mercurial всё ясно - там на каждую фичу свой плагин, нравится это или нет.

А что с Гит? Насколько я понял, к нему плагины тоже есть. Например, Git Large File Storage. Но (дальше просто мое предположение) плагинов под него клепают гораздо меньше, чем под Mercurial, и ставят их очень редко, а в 99% случаев используют лишь его встроенный функционал. Все правильно или я что-то напутал / не так понял?

Deleted

в 99% случаев используют лишь его встроенный функционал

Таки да.

PS: единственные, что приходит на ум — git-flow и git-fire, но ни одно из них лично я не использую.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 2)
Ответ на: комментарий от beastie

git-annex ещё.

ТС: Git «из коробки» покрывает большинство задач. Поэтому и не пишут плагины. Они просто не нужны.

a1batross ★★★★★ ()

У меня есть ничем не подтвержденные ожидания, что плагины для Mercurial писать проще (на Python), и их легко подключать. Я и сам пользуюсь плагинами, а их из коробки ставится огромная тьма, и включаю я их простой галочкой в GUI.

I-Love-Microsoft ★★★★★ ()

Кстати, понятие «плагин Git» довольно обширное. Вот например git тянет в рот подхватывает из PATH все, что начинается на git-* и интерпретирует как собственные команды (например /usr/bin/git-clang-format можно запустить как git clang-format).

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

А еще есть имплементации Git на Java (напр. в BitBucket) и там вообще все по другому.

KennyMinigun ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

У меня есть ничем не подтвержденные ожидания, что плагины для Mercurial писать проще (на Python), и их легко подключать.

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

Однако в Git есть еще и набор впомогательных функций для Shell: /usr/lib/git-core/git-sh-setup. Еще, наверняка, где-то валяются перловые модули.

KennyMinigun ★★★★★ ()

С Mercurial всё ясно - там на каждую фичу свой плагин, нравится это или нет.

Это не совсем так. К примеру, плагины вроде color или bookmarks были вмержены в ядро. Да и с разрабатываемым в настоящее время evolve то же будет в итоге.

Насколько я понял, к нему плагины тоже есть.

Ну то есть как плагины. Git при запуске команды вроде git matryoshka balalayka пытается найти в PATH бинарь git-matryoshka и запустить его с параметрами balalayka. Всё.

В таких условиях плагинов не наклепаешь особо, даже если и хочется. Максимум обёртки вроде hub.

littlechris ★★★ ()

Всем спасибо, узнал много нового :-)

Deleted ()

С Mercurial всё ясно - там на каждую фичу свой плагин, нравится это или нет.

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

А что с Гит?

Git, в начале своего пути (12+ лет назад) официально позиционировался как plumbing, т.е. фактически библиотека для построения VCS, поверх которого будут делаться разные porcelain (уже настояшие VCS); первым из porcelain-ов был cogito, появившийся через пару месяцев после Git, потом появиляся stgit. Но, в общем, развитие Git пошло тем же путем, что и развитие Mercurial - новые фишки poreclain-ов со временем становились частью Git, так что он давно уже porcelain (хреновенький, но всё же).

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от KennyMinigun

О, раз уж тут есть знающие люди, вопрос: А можно как-то заставить гит держать объекты в репозитории, но не показывать их в основном дереве. Условно, чтобы «плагин» мог держать свои данные в самом репозитории, при этом никак не влияя на дерево исходников.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

заставить гит держать объекты в репозитории
объекты

Речь о файлах? Или таки об обьектах Git?

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

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

Если данных не много (конфигурация), то git config под своим префиксом.

KennyMinigun ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Речь о файлах? Или таки об обьектах Git?

О каких-то своих entity, которые при этом хранились бы в репозитории, но при этом не являлись частью working copy.

Если данных не много (конфигурация)

Не пойдёт, это скорее N небольших текстовых файлов.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

Не пойдёт, это скорее N небольших текстовых файлов.

Ну тогда как я написал: складывать под .git/${plugin_name}/

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

# пишем конфиг в произвольный файл
git config --file $FILE my.whatever 42

# бонус: запускаем 'git var GIT_EDITOR' на произвольном файле
git config --file $FILE --edit

KennyMinigun ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Ну тогда как я написал: складывать под .git/${plugin_name}/

Это локально получается? А если надо чтобы оно ещё и в репозиторий уезжало?

суть, чтобы я положил файл, сделал git myplugin push, оно вместе с деревом уехало на remote. git-lfs для этого свой сервер поднимает, я хочу обойтись без этого.

Dark_SavanT ★★★★★ ()
Последнее исправление: Dark_SavanT (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

Это локально получается? А если надо чтобы оно ещё и в репозиторий уезжало?

Ты ведь изначально спрашивал про первое. Если надо на сервер — то самое простое — закоммитить нормально через Git.

KennyMinigun ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Ты ведь изначально спрашивал про первое.

Значит не донёс правильно мысль.

Если надо на сервер — то самое простое — закоммитить нормально через Git.

Понятно, спасибо

Dark_SavanT ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.