Анонсирована система управления репозиториями Kallithea

Это при том, что драйверы в ядре со времен 2.6.31, но няшка git не видит, что они переименованы.

Так в git просто нет переименования и копирования. git mv просто удаляет старый и добавляет новый.

Так в git просто нет переименования и копирования

Я знаю. Но в нем заявлено автоматическое распознавание переименований.

О, про gogs я тоже не знал. Мерси, добавил.

Про аутентификацию мне кажется там в целом вариантов не особо много - либо её нет вообще, либо встроенный push-сервер, использующий встроенную БД и ключики, либо внешняя БД типа LDAP. Но фактически второй вариант - это только Gitprep, все остальные LDAP умеют, даже Indefero...

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

По мне единственный плюс hg - это более похожая на cvs/svn система команд, соответственно, более удобная для тех кто перешёл с оных. Сам юзал долгое время именно hg, но потом всё равно перешёл на git, т.к. он всё равно удобнее. И ветки перманентные нах не нужны (т.к. потом всё это говно древнее - bug1837, bug92817, bug281... так и торчит и никуда его не денешь), и не дай бог коммит исправишь - потом из репозиториев по всей Москве нужно выкашивать старые коммиты т.к. они при следующем push пересоздадутся, и дедупликации там же нет вроде т.к. формат репозитория наркоманский - по 2 файла на хранимый файл. А в гите отлично, внутри граф да и всё)

в нем заявлено автоматическое распознавание переименований.

А его включать нужно опцией -M50

И это я тоже знаю. См. выше о git log на драйвере LL TEMAC.

Аа. Ну логика в этом есть - ты же попросил лог по файлам в drivers/net/ethernet/xilinx. Файлы, которые были раньше - были в drivers/net, вот он тебе их и не показывает.

Плюс там есть опция --follow, но работает только с одинарными файлами.

Ну логика в этом есть - ты же попросил лог по файлам в drivers/net/ethernet/xilinx

А что надо было просить?

Плюс там есть опция --follow, но работает только с одинарными файлами.

...причем с --follow указание v2.6.32..v3.15 работает. Всё же какое беспомощное говно стало дефолтной опенсорсной VCS :/

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

Некоторый минус гита - это только то, что он написан на смеси разных скриптов, но это минус только для виндузятников, у них же хрен чего поставишь в систему нормально - например, git-svn хрен соберёшь, т.к. он на перле, значит нужно чтобы перловый XS был собран тем же компилятором, что svn, а svn хрен соберёшь под mingw, а perl не факт что соберёшь под студией... Я вот попробовал собрать и обломался, т.к. serf собирается скунсом (scons), а оному под mingw рвёт крышу. Хотя serf простенький, может надо было просто руками makefile написать.

Кстати, я вот в hg букмарки особо не пробовал - они хотя бы идентично гитовским веткам работают? Т.е. там origin/master всякие и т.п.

...причем с --follow указание v2.6.32..v3.15 работает.

А это-то чем плохо?

Ой, да переименование - это фигня

Мог бы просто сказать «не нужно».

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

дедупликация

Гитовская «дедупликация» полезна только для переименованных файлов.

я вот в hg букмарки особо не пробовал - они хотя бы идентично гитовским веткам работают? Т.е. там origin/master всякие и т.п.

Я тоже с ними не работал (ИМХО, все эти хитровыделанные схемы бранчей нужны для проектов масштаба ядра или для того, чтобы косплеить Линуса).

...причем с --follow указание v2.6.32..v3.15 работает.

А это-то чем плохо?

Это хорошо. Но несколько противоречит высказыванию

vitalif> логика в этом есть - ты же попросил лог по файлам в drivers/net/ethernet/xilinx. Файлы, которые были раньше - были в drivers/net

Под «логика в этом есть» - я не имел ввиду что это хорошо, я только имел ввиду, что понятно, почему это так =)

Гитовская «дедупликация» полезна только для переименованных файлов.

Хрена с два. Она для всего полезна, т.к. вообще никогда не хранит одно и то же содержимое файла дважды. Банально если человек файл сначала скопирует в рабочей копии, а потом добавит в репозиторий - гит всё равно данные дважды хранить не станет.

Это же подтверждается и сравнительными размерами репозиториев в hg и git. Например я на медиавиковском тестил пару лет назад ещё - hg раза в 2, кажется, больше занимал.

ИМХО, все эти хитровыделанные схемы бранчей

А вот это ты зря - если появляется хотя бы ДВА разных репозитория для одного проекта, непостоянные бранчи становятся ГОРАЗДО удобнее. Да и в одном на самом деле удобнее, т.к. можно не париться и каждый баг в своей ветке делать, и потом этот мусор не захламляет историю.

Гитовская «дедупликация» полезна только для переименованных файлов.

Хрена с два.

А чо только с два? Давай 100500, будет убедительнее.

Она для всего полезна, т.к. вообще никогда не хранит одно и то же содержимое файла дважды

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

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

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

Это же подтверждается и сравнительными размерами репозиториев в hg и git.

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

Например я на медиавиковском тестил пару лет назад ещё - hg раза в 2, кажется, больше занимал.

И что показал анализ, если он был?

если появляется хотя бы ДВА разных репозитория для одного проекта, непостоянные бранчи становятся ГОРАЗДО удобнее

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

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

Сомнительная тактика разработки (хотел написать «преимущество», но подумал, что букмарки давно есть и в mercurial).

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

Ну так я про это и говорил.

бранчи вообще не нужны

Сомнительная тактика разработки

O_o вообще-то не сомнительная, а очень правильная тактика разработки, feature branches называется. Так удобно жить и именно так очень многие и делают.

А если бранчи не нужны, то и DVCS не нужна.

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

Сомнительная тактика разработки

O_o вообще-то не сомнительная, а очень правильная тактика разработки, feature branches называется

Кхм. С каких пор для разработки на feature branches необходимо стирание имен бранчей? Если что, «сомнительность» заключается именно в этом.

А если бранчи не нужны, то и DVCS не нужна.

Просто для протокола - в Mercurial (и Git тоже) невоможно работать _не на бранче_.

Но я начинаю понимать, where you're coming from... времен BitKeeper ты не застал?

Кхм. С каких пор для разработки на feature branches необходимо стирание имен бранчей?

А, ты про это. Да не, не то чтобы необходимо, конечно, просто удобнее, ибо а) старые ветки дохнут и не отсвечивают б) если разработка распределённая, можно ветки из разных источников к себе подтянуть и переименовать (как раз для всяких опенсорсных проектов это как раз очень удобно).

невоможно работать _не на бранче_.

Блин, ну понятное дело. Я имею ввиду - если не нужны бранчи кроме master'а, то DVCS не нужна. Не, BitKeeper не застал.

старые ветки дохнут и не отсвечивают

Не знаю насчет Git, но в Mercurial закрырые ветки не отсвечивают (если не нужно просмотреть именно их).

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

Адепты Хаоса в треде, все в бронекостюмы!

Не, BitKeeper не застал.

Историческая справка: в BK не было бранчей, что никак не мешало успешной разработке ядра.

В BK вообще много чего не было, Кузнецов вон в интервью говорил, что там однострочный коммит полчаса занимал.

Адепты Хаоса в треде, все в бронекостюмы!

Чо хаоса-то, самый обычный кейс.

Не знаю насчет Git, но в Mercurial закрырые ветки не отсвечивают (если не нужно просмотреть именно их).

А вот забыл уже, но где-то они всё равно отсвечивали...

В BK вообще много чего не было

Например?

Кузнецов вон в интервью говорил, что там однострочный коммит полчаса занимал.

Ты будешь смеяться, но ранние версии Git тоже были очень тормозными. До такой степени, что народ массово валил на Mercurial, хотя это и означало потерю всех плюшек от использования общей VCS.

в Mercurial закрырые ветки не отсвечивают (если не нужно просмотреть именно их).

А вот забыл уже, но где-то они всё равно отсвечивали...

Если бы они не отсвечивали нигде, получился бы Git (или Mercurial с bookmarks) %)