Здравствуйте, vdimas, Вы писали:
V>>>А мне никогда не нравился svn, хотя я признаю удобство НЕКОТОРЫХ сценариев с ним. V>>>Git мне нравится больше, хотя я признаю его неудобство для НЕКОТОРЫХ сценариев. V>·>Эти сценарии либо чрезвычайно специфичны, либо показывают о серьёзных проблемах в организации разработки, которые надо фиксить. V>На этом воображение заканчивается? V>Маловато привёл вариантов.
А больше особо и нет.
V>Просто надо понимать некоторую ортогональность принципов хранения данных в системе vs поддерживаемых "изкаробки" сценариев инструмента-клиента. Одно не обязательно следует из другого. Но ты регулярно используешь первое как "аргумент" в пользу каких-то особенностей второго, что нехило доставляет. Выходит, плохо понимаешь связь первого со вторым.
Модель хранения данных лучше описывает моделируемую сущность — контроль версий файлов проекта. Понятно, что можно и другую модель натянуть, но это будет сложнее.
V>·>А по поводу того сценария апдейта файла я так и не понял что в нём такого, что git не умеет или какие хитрые приседания ты имел в виду? V>Я имел ввиду сценарий, когда один разработчик в один клик закидывает только один файл, а другой в один клик его же забирает. V>Ну или в одну команду. V>Разумеется, это можно повторить и в git сразу несколькими способами, но не в один клик или одну команду.
Ну да, в две. Ибо там сохранение и публикация коммита разнесены (правда всё равно обычно IDE пользуюсь, там это в удобные диалоги завёрнуто).
V>·>"checkout -p" позволяет мержить нужное, вплоть до отдельной строки. V>Для простоты пойдёт и git checkout -f [<tree-ish>] [--] <pathspec>. V>В любом случае это не будет первой командой в списке их для реализации описанного сценария.
Второй и последней.
V>Да еще надо помнить точное название удалённой (в смысле remote) ветки внутри собственного клона.
Если это не @{u} или накрайняк не FETCH_HEAD, то это уже не типичный сценарий. А даже если и так, то tab-complete работает как обычно.
V>·>Но так делать всё равно не надо (по крайней мере в описанной тобой ситуации), ибо нефиг. V>Ибо тебя забыли спросить, как надо делать, а как не надо.
Ну вот видишь, всё просто, как оказалось. В следующий раз обязательно спрашивайте.
V>>>По-сути, мне пришлось поменять принципы разработки, чтобы подстроиться под специфику git. V>·>Поменять в лучшую сторону. V>Опять оценочные суждения даже без минимальных критериев?
Ну, имхо, вполне очевидно — исходный код и процесс внесения в него изменений становится более выразительным, контролируемым и предсказуемым. Примерно как когда ты студентом переходишь из написания программ с переменными a1,a2,ii к осмысленным именам.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Модель хранения данных лучше описывает моделируемую сущность — контроль версий файлов проекта.
Модель — это статика, сценарии — динамика.
Одна и та же динамика может быть реализована через разные способы хранения данных и наоборот тоже верно — над одной и той же структурой данных можно реализовать различные сценарии. Азы, как бэ.
V>>>>По-сути, мне пришлось поменять принципы разработки, чтобы подстроиться под специфику git. V>>·>Поменять в лучшую сторону. V>>Опять оценочные суждения даже без минимальных критериев? ·>Ну, имхо, вполне очевидно — исходный код и процесс внесения в него изменений становится более выразительным, контролируемым и предсказуемым.
Осталось объяснить как оперативный обмен изменениями м/у коллегами делает этот процесс менее контроллируемым.
Типа, если требуется больше приседаний, то больше контроль, что-ле? ))
Это до боли знакомая разновидность мастурбации на некие самопридуманные догмы.
·>Примерно как когда ты студентом переходишь из написания программ с переменными a1,a2,ii к осмысленным именам.
Это ты с чего ты решил?
Для реализаций операторов сравнения и вообще любых операторов, где порядок аргументов не важен, у меня вполне входу идентификаторы a, b. ))
Осмысленность — это соответствие принятых решений конкретной задаче.
Всё остальное — дилетанство.
Часто это дилетанство пытаются скрыть за строгим следованием неким догмам, но дилетанство от этого не перестаёт быть дилетанством.
Если человек не в состоянии сформулировать проблематику, как ты здесь каждый божий раз демонстрируешь, то никакие догмы его не спасут.
Он так и будет тыкаться как слепой котёнок, двигаясь на ощупь, искренне веря при этом, что делает всё правильно.
Здравствуйте, Vain, Вы писали:
V>>>Зачем ты выделенное удалил. Опять прикидываешься? V>·>"одновременно разрабатываться." — это что-ли? Я не знаю что это означает для тебя. Могу немного подробнее рассказать. У нас несколько сотен приложений (что-то типа soa архитектуры), которые постоянно меняются. Скажем, в прошлом году были изменения для MiFID II и это затронуло практически каждое приложение. А ещё плюс тут же всяческие тесты, конфиги и т.п. вот 25к и набежало. V>Набежать может за много много лет, но одновременно разрабатывается какой-то мелкий процент.
Ради интереса посмотрел — за последний год изменено 6к файлов (24%), за последние 3 года — 15к файлов (60%). Это одновременно? Это мелкий процент?
И да, я знаю, у нас там есть мусор, который надо бы почистить... Но пока не сильно мешает, вот и некому взяться.
V>>>Ставишь TortoiseSVN и проверяешь. Чем не эквивалент? V>·>Ты мне толком скажи. Я привёл точную команду "git commit -am wip & git push" всё. А ты мне что-то невнятное мычишь про клики мышой, да "ставишь и проверяешь". V>Я использую гуйню для выбора того из чего надо сделать патч. Это быстро и удобно.
Типично для бэкапа выбирать ничего не надо — бэкапится обычно всё. Зачем что-то выбирать? Так что давай рассмотрим именно этот сценарий который обсуждаем изначально.
V>Как ты будешь выбирать какие файлы добавлять в патч через консоль? Мисье извращенец?
Диалоги сравнивать будет несколько сложнее в рамках форума, но в gui это тоже делается элементарно.
Да и выбирать какие файлы/строки добавлять в патч в консоли тоже просто, не svn же.
V>·>Нет. Ты заявил "Он и лучше гита работает." бездоказательно. Какое доказательство и с чего это вдруг ты с меня требуешь — для меня тайна. V>Я уже тебе доказал это количеством команд, которое надо запоминать. Пезупречно лучше по этому параметру.
Это субъективный параметр. Кому надо, кому не надо...
V>>>Публичность этому не мешает и даже помогает. А вот при закрытой форме можно нагородить такой огород, что никакой мерж не справиться. V>·>Каким образом помогает? Никто просто не будет заглядывать в эти ветки и городи что хочешь. V>Как раз заглядывают.
В команде из нескольких десятков девов таких веток будут тысячи после пары лет.
V>·>А от "никакой мерж не справится" — мержся почаще и будет тебе щастьё. V>Всех со всеми через глубокие деревья которые ты по ссылкам приводил? Неа, спасибо.
Что? Не понял что ты имеешь в виду.
V>>>Такое что это практическая необходимость исправить и дополнить комментарий. Ты будешь ещё с этим спорить? V>·>А в киеве дядька. Практическая необходимость это, конечно, круто. Но зачем ты её ввернул в разговор о воркфлоу? Как обычно, с темы съехать? V>Потому-что это часть процесса коммита. Что ты всё дурачком прикидываешься?
_исправление_ комментария существующего коммита?! Это часть воркфлоу?! Ну ладно, сдаюсь. Надеюсь в реальности такое никогда не увижу.
V>>>Не не даёт потому-что сразу ругается на непустой каталог. V>·>Ну задай другой каталог или удали тот, который мешается. В чём вопрос-то? V>
Ах, ты вопрос забыл.
V>·>То что не относится к теме обсуждения — да, стараюсь игнорировать, чтобы не поддаваться на провокации сведения темы в говно. V>Нет, ты игнорируешь факты, чтобы не пришлось отдуваться за overbloat гит.
Да я и не собирался отдуваться ни за что. Я пытался отвечать на вопросы. Если у тебя вопросов больше нет, можно закругяться.
V>>>Я ничего не придумывал. Это устаявшая практика в версии продукта писать номер билда или коммита. V>·>Пусть, и что? Какое это имеет отношение к обсуждаемой теме? Опять съезжаешь в сторону? V>Сначало ты спихнул тему на то, что я что-то там придумал. Теперь "пускай так". Это имеет прямое отношение. Ещё раз для слепых и глухих повторяю: по номеру билда/коммита локализуется место в исходниках без всяких бисектов.
А... понял. Ты почему-то решил, что клиент полностью тестирует каждый билд. Часто это не так (а вообще такое бывает?). Клиент может обнаружить конкретное изменение поведения приложения на очень разных версиях.
V>>>Ещё как относятся. Приходит отчёт с ошибкой связанной именно с версией у пользователя, по-которому ищется тот самый билд или коммит, как минимум чтобы воспроизвести проблему. V>·>Ок. Проблему воспроизвели. В версии X проблема воспроизводится, в версии Y — не воспроизводится. Между версиями X и Y — тысячи коммитов, тысячи изменённых файлов. Дальше что? V>Место нашли, але. Какой нафик Y?
Место чего нашли?
V>>>·>Я тебе уже объяснял про чужие ключи. Попробуй описать модель атаки с уводом чужих клучей и сравни с тем что я описал. V>>>Зачем мене ещё что-то описывать? Я как оппонент заявлю: "хакеры могут всё", этого достаточно. V>·>Верно, достаточно чтобы свести обсуждение в говно. Собственно, как я понял, у тебя это и есть цель дискуссии. V>
·>Воинствующее мракобесие.
V>
·>Чем доказал, тем что его на помоечку отправляют?
V>
·>Балабол.·>Балабол.·>Балабол.
V>Зеркало не мешает?
А ты приведи свои предыдущие реплики, на которые я так отвечал... чисто для полноты картины.
V>>>Сначала объясни что ты делал. V>·>Да я уж объяснял — правил старые коммиты (не с целью хака, конечно, к сожалению, а чтобы историю мержей и правок сделать чуть более вменяемой) путём отката до нужной ревизии и перепроигрывания чуть подправленных коммитов. Но это был самый первый способ что я нашел. Если повнимательнее покопаться в формате V>И ты решал что хакеры могут использовать это во зло, я угадал? А чего ты взял что можно закоммитить туда какой-то бакдор?
С того, что уже были прецеденты.
V>·>Ты просто не читаешь что тебе пишут. Я пишу _коммиты_ защищены от _модификации_. Коммит в конец блокчейна не может никак модифицировать уже существующий коммит. Коммит в конце блокчейна окажется под тщательным анализом, в отличие от незаметной модификации каких-то уже давно забытых. V>Приведи пример модификации на обычной базе из 3х коммитов.
Ну самое тупое (не самое эффективное и незаметное, конечно) это сделать копию через svnadmin dump-ы по revision ranges, поправить там средний коммит как душе угодно, потом исправить .svn/db/current в "1" и залить два коммита из поправленных дампов. В итоге у тебя будет репо с теми же тремя коммитами, но 2й коммит с другим содержимым.
V>>>Само существование git-svn с жуткими кастылями доказывает обратное. V>·>Доказывает что именно? С какими именно костылями? V>https://public-inbox.org/git/1187166615.20170604023631@inbox.ru/t/ V>* одна команда несовместима с другой V>* реализация пустых каталогов через Ж, вместо того чтобы сделать пустые каталоги частью дизайна (постоянно кучу каких то пустых варнингов выдает) V>* невозможность клонировать часть репы с теми же хешами
Я это сообщение вообще не понял. Что там чувак пытался сделать такое? Судя по ответам — фигню какую-то.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>В итоге, чтобы суметь в git работать совместно и при этом оперативно, как в svn, надо будет создавать примерно 5-7 подветок в день и коллеги должны тянуть друг у друга конкретные эти подветки, что само по себе является идиотизмом. ·>Я понимаю, с т.з. svn 5 веток это кашмар и ужас. Но в git это тривиальные pull requests, changesets, etc.
Пропустил твой очередной залёт. ))
pull request не имеет к git никакого отношения.
V>>Собсно, на твою близорукость в этом вопросе (и не только на твою) я уже указывал — git НЕ предназначен для организации коллективной realtime-разработки. Он заточен ровно наоборот — на неспешную независимую offline-разработку. Да еще и желательно над разными частями системы. А м/у этими сценариями пропасть, неужели сам не видишь? ·>Бред. Факты показывают обратное.
Факты у каждого свои.
Особенно у тех, кто уже путает git с github-ом.
V>>Имено поэтому Mercurial популярен до сих пор в некоторых активно развивающихся проектах — ведь он умеет быть и как svn и как git в самых популярных сценариях разработки. ·>Потому что слезть дорого.
Опять популярный залёт во всей красе.
Любое действие должно давать профит.
Ели смена hg на git профитов не даёт, то топить за git можно лишь от упоротости.
Здравствуйте, vdimas, Вы писали:
V>>>В итоге, чтобы суметь в git работать совместно и при этом оперативно, как в svn, надо будет создавать примерно 5-7 подветок в день и коллеги должны тянуть друг у друга конкретные эти подветки, что само по себе является идиотизмом. V>·>Я понимаю, с т.з. svn 5 веток это кашмар и ужас. Но в git это тривиальные pull requests, changesets, etc. V>Пропустил твой очередной залёт. )) V>pull request не имеет к git никакого отношения. git help request-pull
V>>>Собсно, на твою близорукость в этом вопросе (и не только на твою) я уже указывал — git НЕ предназначен для организации коллективной realtime-разработки. Он заточен ровно наоборот — на неспешную независимую offline-разработку. Да еще и желательно над разными частями системы. А м/у этими сценариями пропасть, неужели сам не видишь? V>·>Бред. Факты показывают обратное. V>Факты у каждого свои. V>Особенно у тех, кто уже путает git с github-ом.
Иногда лучше молчать.
V>>>Имено поэтому Mercurial популярен до сих пор в некоторых активно развивающихся проектах — ведь он умеет быть и как svn и как git в самых популярных сценариях разработки. V>·>Потому что слезть дорого. V>Опять популярный залёт во всей красе. V>Любое действие должно давать профит. V>Ели смена hg на git профитов не даёт, то топить за git можно лишь от упоротости.
Даёт, конечно, но профит этот не всегда превышает затраты. Иначе бы столько переездов hg->git бы не было (обратных, кстати, я не припомню).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>В итоге, чтобы суметь в git работать совместно и при этом оперативно, как в svn, надо будет создавать примерно 5-7 подветок в день и коллеги должны тянуть друг у друга конкретные эти подветки, что само по себе является идиотизмом. V>>·>Я понимаю, с т.з. svn 5 веток это кашмар и ужас. Но в git это тривиальные pull requests, changesets, etc. V>>Пропустил твой очередной залёт. )) V>>pull request не имеет к git никакого отношения. ·> git help request-pull
Не надоело залетать?
rbt post
что я только что написал?
Работает со времен CVS и svn.
Более-менее пытаются исправить ситуацию Reggit и интерфейс Bitbucket, но до полноценной review board еще не дотянули.
По-лоховски и там и там, а в gihub и вовсе кошмар уровня наколенных поделок я-ля середина 2000-х.
Если любопытно — могу разложить по полочкам "фатальный недостаток" git в этом плане.
Причём, недостаток легко излечимый при желании.
Но у разработчиков git такого желания НЕТ, потому что при разработке ядра Linux изменения проходят многостадийную проверку, где эта "многостадийность" вынесена за рамки ответственности собсно git и управляется внутренней бюрократией вручную.
Поэтому, им похрен на всех вас.
Не для вас этот git был писан, поэтому вы не можете заглядывать этому даренному коню в зубы.
Хотите — берите.
Нет — свободны.
Такова философия git.
V>>·>Бред. Факты показывают обратное. V>>Факты у каждого свои. V>>Особенно у тех, кто уже путает git с github-ом. ·>Иногда лучше молчать.
Тебе лучше спрашивать.
V>>Опять популярный залёт во всей красе. V>>Любое действие должно давать профит. V>>Ели смена hg на git профитов не даёт, то топить за git можно лишь от упоротости. ·>Даёт, конечно
Тебя уже больше года пытали насчёт профитов — ты ни одного так и не родил.
Всё время упускаешь из виду, что Mercurial легче расширяем, чем git.
В этом плане Mercurial близок к svn.
Под него можно накатать и уже есть накатанные кучи плагинов.
А в плане гит — лопай что дают.
А меню, увы, очень скромное.
·>но профит этот не всегда превышает затраты.
Затратами в данном случае будут являться самописные тулзы, чтобы покрыть отсутствующую в git функциональность.
Причём, для git писать тулзы сложно, а иногда невозможно — например для серверной стороны, т.к. для git это будет связано с дискредитацией безопасности аккаунтов.
·>Иначе бы столько переездов hg->git бы не было (обратных, кстати, я не припомню).
Это был переезд не hg->git, а hg->github.
Опять ты их путаешь.
Здравствуйте, ·, Вы писали:
V>>>>Суть операции rebase — она банально в автоматическом применении merge при изменении порядка коммиттов. V>>·>Вообще, более точно надо говорить, не merge, а applying patches. V>>Еще и поучить решил как "правильно говорить". V>>Правильно говорить merge, потому что такова суть происходящего — слияние наработок от нескольких источников. ·>Нет. Открой доку в конце концов: "git-rebase — Reapply commits on top of another base tip" — вот суть rebase. Никаких "слияний наработок" и прочего словоблудия.
Да, в плане небольшого ликбеза.
1. Основные реализации клиентов и серверов git сейчас сидят поверх вот этой либы: https://github.com/libgit2
Эта либа от гитахаба, сам он на ней тоже сидит, ес-но.
2. Никаких скриптов, всё выполняется нейтивно.
Все диффы, apply и прочие операции.
Практически всегда через операцию merge.
По крайней мере в обсуждаемом сценарии синхронизации с серваком git pull --rebase — достоверно.
Не через мерж эта операция происходит лишь в тех уникальных случаях, когда некий узел-коммит "копируется" без изменения родителя, например, при последовательном выполнении cherry-pick из другой ветки, где та имеет роддителем текущий коммит в нынешней. Во всех остальных случаях — merge.
Далее, посмотри внимательней там же рядом на этот merge. Он не сводится к простому apply patch. Он из нескольких патчей делает один, отличающийся от обоих исходных, кроме того уникального случая, когда склеиваемые коммиты содержат в точности идентичные изменения.
Здравствуйте, vdimas, Вы писали:
V>>>Пропустил твой очередной залёт. )) V>>>pull request не имеет к git никакого отношения. V>·> git help request-pull V>Не надоело залетать? V>
V>rbt post
V>
V>что я только что написал?
Понятия не имею. Только это не pull requests.
V>Работает со времен CVS и svn. https://en.wikipedia.org/wiki/Review_Board Initial release: May 17, 2007; 10 years ago — несколько лет спустя после git request-pull
V>Подобная ф-сть прекрасно окучена в mercurial. V>Но в git эта функциональность самая бедная из всех возможных: V>http://www.bitsnbites.eu/github-pull-request-code-review/
V>Более-менее пытаются исправить ситуацию Reggit и интерфейс Bitbucket, но до полноценной review board еще не дотянули. V>По-лоховски и там и там, а в gihub и вовсе кошмар уровня наколенных поделок я-ля середина 2000-х.
Если тебе хочется web review tool, рекомендую посмотреть gerrit.
V>·>Даёт, конечно V>Тебя уже больше года пытали насчёт профитов — ты ни одного так и не родил.
Я уже как-то детально сравнивал hg и git, если хочешь, поищи флейм по этому поводу где-то год-два назад. В кратце, git имеет оригинальную организацию хранилища, благодаря этому большинство фич ложится как родное. Hg имеет традиционный delta-log (или как оно там зовётся), модель которого тянется с допотопных времён и плохо масштабируется, особенно на распределённую разработку..
V>Под него можно накатать и уже есть накатанные кучи плагинов. V>А в плане гит — лопай что дают. V>А меню, увы, очень скромное.
Зато оно всё вместе работает. Тогда как все эти плагины — сбокуручки, которые друг-с-другом никак не взаимодействуют. Попробуй, например, сделай diff содержимого stash с веткой до rebase.
V>·>но профит этот не всегда превышает затраты. V>Затратами в данном случае будут являться самописные тулзы, чтобы покрыть отсутствующую в git функциональность. V>Причём, для git писать тулзы сложно, а иногда невозможно — например для серверной стороны, т.к. для git это будет связано с дискредитацией безопасности аккаунтов.
Примеры.
V>·>Иначе бы столько переездов hg->git бы не было (обратных, кстати, я не припомню). V>Это был переезд не hg->git, а hg->github. V>Опять ты их путаешь.
Нет, некоторые на gitlab и т.п. переезжают.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
* git request-pull появился не сразу
* rbtools — лишь один из примеров данной технологии, просто одна из самых популярных на прямо сейчас, а так-то полно альтернатив, где самые старые из них ведут отчёт с конца 90-х. По крайней мере мы применяли эту технологию уже в 98-м году поверх CVS.
V>>Более-менее пытаются исправить ситуацию Reggit и интерфейс Bitbucket, но до полноценной review board еще не дотянули. V>>По-лоховски и там и там, а в gihub и вовсе кошмар уровня наколенных поделок я-ля середина 2000-х. ·>Если тебе хочется web review tool, рекомендую посмотреть gerrit.
Я его и имел ввиду, очепятался.
Ф-сть ограничена.
V>>·>Даёт, конечно V>>Тебя уже больше года пытали насчёт профитов — ты ни одного так и не родил. ·>Я уже как-то детально сравнивал hg и git, если хочешь, поищи флейм по этому поводу где-то год-два назад. В кратце, git имеет оригинальную организацию хранилища, благодаря этому большинство фич ложится как родное. Hg имеет традиционный delta-log (или как оно там зовётся), модель которого тянется с допотопных времён и плохо масштабируется, особенно на распределённую разработку..
Мде. ))
В обеих системах данные образуют направленный ациклический граф.
Соответственно, потенциальный набор операций над этим графом идентичный.
Что же касается тонкостей хранения, то mercurial хранит данные более эффективно для 99.99% сценариев работы с системой контроля версий.
Данные хранятся более компактно, по ним быстрее происходит поиск, а так же протокол обмена получается более эффективным.
Это известные медицинские факты.
Более эффективной модель git будет примерно в таком гипотетическом сценарии — когда необходимо удалить из графа некий очень древний коммит, т.е. после которого были уже многие десятки или сотни других коммитов.
В итоге, "преимуществом" является лёгкость управления историей давних коммитов.
То бишь, легко что-то портить задним числом, как два пальца об асфальт.
Можно запросто создать некий коммит прямо сейчас, а потом переместить его (в логическом смысле, чтобы ты опять не придирался) куда-нить далеко в прошлое и т.д.
Подобные практики дурные, разумеется. ))
Во-первых, они дают возможность что-то необратимо потерять (если вовремя не обнаружить ошибку и сделать push, то "сиротские" коммиты будут подобраны сборщиком мусора).
Во-вторых, провоцируют на грязь (типа если что — потом почистим) и даже на прямой обман (можно перекорёжить историю и сделать вид, что так и было).
ИМХО, у git есть только одно преимущество, и то, не столь давнее — это хорошее окучивание всевозможных сценариев "изкаробки".
Изначально git был беднее.
Но на сейчас для hg есть плагины на все случаи жизни или их несложно написать.
Написать же плагин для git — сложно.
До разработки gitlib2 — практически невозможно (в том смысле, что слишком трудозатратно).
V>>Под него можно накатать и уже есть накатанные кучи плагинов. V>>А в плане гит — лопай что дают. V>>А меню, увы, очень скромное. ·>Зато оно всё вместе работает. Тогда как все эти плагины — сбокуручки, которые друг-с-другом никак не взаимодействуют. Попробуй, например, сделай diff содержимого stash с веткой до rebase.
Этот же сценарий можно реализовать вообще без stash.
Это тоже разновидность дурного сценария — прятать свои изменения, накатывать какие-то левые, а потом возвращать свои.
Это тот самый источник потенциальных ошибок, т.к. есть вероятность затереть важные чужие изменения банально из-за невнимательности.
Никакой diff тебя не спасёт.
Почему бы не сделать наоборот — сначала закоммитить свои изменения?
При последующем мерже во время rebase в любом случае одинаковые изменения "схлопнутся", а разные или конфликтующие будут видны.
И точно так же можно посмотреть diff перед этим rebase-merge.
V>>·>но профит этот не всегда превышает затраты. V>>Затратами в данном случае будут являться самописные тулзы, чтобы покрыть отсутствующую в git функциональность. V>>Причём, для git писать тулзы сложно, а иногда невозможно — например для серверной стороны, т.к. для git это будет связано с дискредитацией безопасности аккаунтов. ·>Примеры.
Пример простой — чтобы сделать на стороне сервера "что-то еще", что не покрывается протоколом git, потребуется создать другую линию связи до своей серверной утилиты, и обеспечить по этой линии идентификацию того же самого автора, т.к. изменения на серваке не могут происходить от имени сервака, они могут происходить только от имени конкретного пользователя.
V>>·>Иначе бы столько переездов hg->git бы не было (обратных, кстати, я не припомню). V>>Это был переезд не hg->git, а hg->github. V>>Опять ты их путаешь. ·>Нет, некоторые на gitlab и т.п. переезжают.
В исключительных случаях, когда ценовая политика для коммерческого хостинга получается лучше для gitlab (маленькая команда, но очень много проектов — это совсем редкий случай).
Просто сам по себе github — это же был нонсенс в своё время.
Он дал абсолютно нахаляву для опенсорса или для собственных нужд хостинг VCS-системы натурально коммерческого уровня (по тем временам), убив сразу более десятка конкурентов. ))
В итоге, github задал тон всей индустрии в этой области, поэтому, выжили только те, кто смог себе позволить аналогичную щедрость.
Я хорошо помню, как github "зашел" в своё время — сразу с мощным вебом, с одной из самых лучших (на тот момент) GUI-утилитой для git(hub исключительно, ы-ы-ы), куча халявы по управлению проектами и даже для коммерческого хостинга недорого.
Я был впечатлён угу. Это же кто-то вложился нихрена себе! ))
Здравствуйте, vdimas, Вы писали:
V>>>Работает со времен CVS и svn. V>·>https://en.wikipedia.org/wiki/Review_Board Initial release: May 17, 2007; 10 years ago — несколько лет спустя после git request-pull
V>* git request-pull появился не сразу
Примерно 13 лет назад, месяца через 3 после начала проекта git. Гхм... ну да, не сразу.
V>* rbtools — лишь один из примеров данной технологии, просто одна из самых популярных на прямо сейчас, а так-то полно альтернатив, где самые старые из них ведут отчёт с конца 90-х. По крайней мере мы применяли эту технологию уже в 98-м году поверх CVS.
Не надо путать web review и pull requests. Pull requests в первую очередь не про code review, а про distributed разработку. Web review — по определению для централизованнй разработки. Поэтому причём тут cvs/svn — для меня загадка.
V>>>Более-менее пытаются исправить ситуацию Reggit и интерфейс Bitbucket, но до полноценной review board еще не дотянули. V>>>По-лоховски и там и там, а в gihub и вовсе кошмар уровня наколенных поделок я-ля середина 2000-х. V>·>Если тебе хочется web review tool, рекомендую посмотреть gerrit. V>Я его и имел ввиду, очепятался. V>Ф-сть ограничена.
Она не ограничена, она другая. Использовать gerrit можно и совместно с github.
V>>>Тебя уже больше года пытали насчёт профитов — ты ни одного так и не родил. V>·>Я уже как-то детально сравнивал hg и git, если хочешь, поищи флейм по этому поводу где-то год-два назад. В кратце, git имеет оригинальную организацию хранилища, благодаря этому большинство фич ложится как родное. Hg имеет традиционный delta-log (или как оно там зовётся), модель которого тянется с допотопных времён и плохо масштабируется, особенно на распределённую разработку.. V>Мде. )) V>В обеих системах данные образуют направленный ациклический граф.
Я не это имею в виду. в git это ассоциативная база данных, хранилище объектов. В hg хранится дельта-лог для каждого файла (как в старом добром sccs или даже раньше). Может в последнее время ситуацию и улучшили, но когда шли войны hg vs git — это сыграло решающую роль.
V>Соответственно, потенциальный набор операций над этим графом идентичный.
Теоретически, а как дело доходит до практики...
V>Что же касается тонкостей хранения, то mercurial хранит данные более эффективно для 99.99% сценариев работы с системой контроля версий.
Точнее ограничивает сценарии, иначе всё становится неэффективно.
V>То бишь, легко что-то портить задним числом, как два пальца об асфальт.
Ну да. И ещё оно полезно при таком редком гипотетическом сценарии который никому никогда не нужен — процесс code review.
V>До разработки gitlib2 — практически невозможно (в том смысле, что слишком трудозатратно).
Я же говорю, что суть не в самом git/libgit/egit/etc — а в структуре хранилища. Слишком много тонких моментов, да ещё и опять непонятки с интерпретацией, не хочу углубляться.
V>>>А меню, увы, очень скромное. V>·>Зато оно всё вместе работает. Тогда как все эти плагины — сбокуручки, которые друг-с-другом никак не взаимодействуют. Попробуй, например, сделай diff содержимого stash с веткой до rebase. V>Этот же сценарий можно реализовать вообще без stash.
Можно и без stash, можно и со stash — пофиг, каждый делает так как ему больше нравится. И то и то одинаково эффективно и удобно работает. В отличие от hg, который дал тебе "99.99% сценариев работы" — и жри что дают, чуть шаг в сторону — расстрел на месте.
V>И точно так же можно посмотреть diff перед этим rebase-merge.
А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git.
V>>>Затратами в данном случае будут являться самописные тулзы, чтобы покрыть отсутствующую в git функциональность. V>>>Причём, для git писать тулзы сложно, а иногда невозможно — например для серверной стороны, т.к. для git это будет связано с дискредитацией безопасности аккаунтов. V>·>Примеры. V>Пример простой — чтобы сделать на стороне сервера "что-то еще", что не покрывается протоколом git, потребуется создать другую линию связи до своей серверной утилиты, и обеспечить по этой линии идентификацию того же самого автора, т.к. изменения на серваке не могут происходить от имени сервака, они могут происходить только от имени конкретного пользователя.
А подробнее? На что хуков не хватает?
V>>>Это был переезд не hg->git, а hg->github. V>>>Опять ты их путаешь. V>·>Нет, некоторые на gitlab и т.п. переезжают. V>В исключительных случаях, когда ценовая политика для коммерческого хостинга получается лучше для gitlab (маленькая команда, но очень много проектов — это совсем редкий случай).
Пусть так. Главное git->hg никто не переезжает.
V>Я был впечатлён угу. Это же кто-то вложился нихрена себе! ))
Вот ведь гады! Исследовали рынок и дали то что рынку надо! Вот уроды, а могли бы тупо какую-нибудь херню выкатить и радоваться жизни.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>* rbtools — лишь один из примеров данной технологии, просто одна из самых популярных на прямо сейчас, а так-то полно альтернатив, где самые старые из них ведут отчёт с конца 90-х. По крайней мере мы применяли эту технологию уже в 98-м году поверх CVS. ·>Не надо путать web review и pull requests. Pull requests в первую очередь не про code review, а про distributed разработку.
Pull requests — это исключительно и только про code review.
·>Web review — по определению для централизованнй разработки. Поэтому причём тут cvs/svn — для меня загадка.
Откуда ты взял "централизованной"?
Это просто инструмент.
Он работает с произвольными бранчами и произвольными репозиториями.
V>>·>Если тебе хочется web review tool, рекомендую посмотреть gerrit. V>>Я его и имел ввиду, очепятался. V>>Ф-сть ограничена. ·>Она не ограничена, она другая. Использовать gerrit можно и совместно с github.
Она не другая, а ровно та же.
Просто не вся, что уже накоплена в том же rbtools, а примерно 20%-30% её в сочетании с ужасным GUI.
Таков опен-сорс, смирись.
Со временем нагонят, просто подожди еще десяток-другой лет и всё будет ОК.
V>>В обеих системах данные образуют направленный ациклический граф. ·>Я не это имею в виду. в git это ассоциативная база данных, хранилище объектов.
Не только. В git хранятся в том числе revlog-и, для целей экономии места.
·>В hg хранится дельта-лог для каждого файла (как в старом добром sccs или даже раньше). Может в последнее время ситуацию и улучшили
Отродясь хранили не только revlog-и, но и объекты целиком.
Есть некий порог изменений, выше которого объект хранится не в виде разницы, а в виде значения.
·>но когда шли войны hg vs git — это сыграло решающую роль.
Решающую роль сыграл github.
Ничего подобного халявного для mercurial не было.
V>>Что же касается тонкостей хранения, то mercurial хранит данные более эффективно для 99.99% сценариев работы с системой контроля версий. ·>Точнее ограничивает сценарии, иначе всё становится неэффективно.
Можно сказать "заточен под определённые сценарии".
V>>То бишь, легко что-то портить задним числом, как два пальца об асфальт. ·>Ну да. И ещё оно полезно при таком редком гипотетическом сценарии который никому никогда не нужен — процесс code review.
Не вижу проблем, когда code review добавляет инкрементальные изменения.
Не надо стесняться быть иcправленным! ))
А вот когда что-то меняется задним числом — вижу тут сразу несколько проблем.
В первую очередь это вероятность прохождения волны конфликтов при обновлении коммитов (в логическом их смысле, ага).
V>>И точно так же можно посмотреть diff перед этим rebase-merge. ·>А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git.
А чем hg revert не устраивает? Или hg rollback?
V>>Пример простой — чтобы сделать на стороне сервера "что-то еще", что не покрывается протоколом git, потребуется создать другую линию связи до своей серверной утилиты, и обеспечить по этой линии идентификацию того же самого автора, т.к. изменения на серваке не могут происходить от имени сервака, они могут происходить только от имени конкретного пользователя. ·>А подробнее? На что хуков не хватает?
Выделил жирным.
Собсно, даже функциональность как в github, когда можно комментировать/обсуждать строчки diff коммитов, равивая там целую дисскуссию — она не тривиальна. Это замах на функциональность полноценного ревью, но это сам сервак github реализует такую функциональность как часть его же git-сервера, где сам этот git-сервер у них совершенно уникальный, т.е. собственной реализации.
Но там ~800 человек работает над этим всем.
А я, скромный разработчик, который поставил уже какой-то имеющийся сервак git, хрен что сделаю.
Даже не знаю, с какой стороны подступиться. ))
V>>Я был впечатлён угу. Это же кто-то вложился нихрена себе! )) ·>Вот ведь гады! Исследовали рынок и дали то что рынку надо! Вот уроды, а могли бы тупо какую-нибудь херню выкатить и радоваться жизни.
Дело в том, что это попахивает альтруизмом, то бишь вредительством.
Этот проект был создан не для зарабатывания, а для вытеснения зарабатывающих.
Вот выкатила Sun джаву задаром и здохла.
Попутно убила нейтив на долгие ~15 лет, вот, последние 7-8 лет к нему опять возвращаются.
Потому что — а куда вы все денетесь с подводной лодки? ))
Понимаешь, цена должна быть адекватна себестоимости, тогда развитие технологий будет объективным, а не исскуственно-кривым.
А то ведь потом рано или поздно любую кривизну приходится выпрямлять, но это всегда дороже, чем если бы этой кривизны вовсе не было.
Здравствуйте, vdimas, Вы писали:
V>>>* rbtools — лишь один из примеров данной технологии, просто одна из самых популярных на прямо сейчас, а так-то полно альтернатив, где самые старые из них ведут отчёт с конца 90-х. По крайней мере мы применяли эту технологию уже в 98-м году поверх CVS. V>·>Не надо путать web review и pull requests. Pull requests в первую очередь не про code review, а про distributed разработку. V>Pull requests — это исключительно и только про code review.
Нет, не только. Это в общем случае обмен contributions to a project.
V>·>Web review — по определению для централизованнй разработки. Поэтому причём тут cvs/svn — для меня загадка. V>Откуда ты взял "централизованной"? V>Это просто инструмент. V>Он работает с произвольными бранчами и произвольными репозиториями.
Без центрального веб-сервера web review как-то странно работает. Как работать с произвольными бранчами и репозиториями для cvs/svn — вообще загадка.
V>>>В обеих системах данные образуют направленный ациклический граф. V>·>Я не это имею в виду. в git это ассоциативная база данных, хранилище объектов. V>Не только. В git хранятся в том числе revlog-и, для целей экономии места.
Это что?? reflog имеешь в виду? Или delta compression ты так называешь?
V>·>В hg хранится дельта-лог для каждого файла (как в старом добром sccs или даже раньше). Может в последнее время ситуацию и улучшили V>Отродясь хранили не только revlog-и, но и объекты целиком. V>Есть некий порог изменений, выше которого объект хранится не в виде разницы, а в виде значения.
В hg/svn/cvs/etc он по дизайну append only, отсюда и беды.
V>·>но когда шли войны hg vs git — это сыграло решающую роль. V>Решающую роль сыграл github. V>Ничего подобного халявного для mercurial не было.
Почему не сделали? Много всяких сайтов, на которых были и git и другие vcs.
V>>>Что же касается тонкостей хранения, то mercurial хранит данные более эффективно для 99.99% сценариев работы с системой контроля версий. V>·>Точнее ограничивает сценарии, иначе всё становится неэффективно. V>Можно сказать "заточен под определённые сценарии".
Которых не хватает. А расширяемость модели хранилища — никакущая.
V>>>То бишь, легко что-то портить задним числом, как два пальца об асфальт. V>·>Ну да. И ещё оно полезно при таком редком гипотетическом сценарии который никому никогда не нужен — процесс code review. V>Не вижу проблем, когда code review добавляет инкрементальные изменения. V>Не надо стесняться быть иcправленным! ))
Дело вкуса.
V>А вот когда что-то меняется задним числом — вижу тут сразу несколько проблем. V>В первую очередь это вероятность прохождения волны конфликтов при обновлении коммитов (в логическом их смысле, ага).
Для куска под code review?
V>>>И точно так же можно посмотреть diff перед этим rebase-merge. V>·>А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git. V>А чем hg revert не устраивает? Или hg rollback?
Просто для того, чтобы почитать diff?? Ты серьёзно?
V>>>Пример простой — чтобы сделать на стороне сервера "что-то еще", что не покрывается протоколом git, потребуется создать другую линию связи до своей серверной утилиты, и обеспечить по этой линии идентификацию того же самого автора, т.к. изменения на серваке не могут происходить от имени сервака, они могут происходить только от имени конкретного пользователя. V>·>А подробнее? На что хуков не хватает? V>Выделил жирным. V>Собсно, даже функциональность как в github, когда можно комментировать/обсуждать строчки diff коммитов, равивая там целую дисскуссию — она не тривиальна. Это замах на функциональность полноценного ревью, но это сам сервак github реализует такую функциональность как часть его же git-сервера, где сам этот git-сервер у них совершенно уникальный, т.е. собственной реализации. V>Но там ~800 человек работает над этим всем. V>А я, скромный разработчик, который поставил уже какой-то имеющийся сервак git, хрен что сделаю. V>Даже не знаю, с какой стороны подступиться. ))
Я ничего не понял, причём тут это? А что, в hg/svn/etc это всё искаропки и их протокол всё такое поддерживает?
V>>>Я был впечатлён угу. Это же кто-то вложился нихрена себе! )) V>·>Вот ведь гады! Исследовали рынок и дали то что рынку надо! Вот уроды, а могли бы тупо какую-нибудь херню выкатить и радоваться жизни. V>Дело в том, что это попахивает альтруизмом, то бишь вредительством.
Не то что политика sf — вот уж где гениальнейший бизнес-план!
V>Этот проект был создан не для зарабатывания, а для вытеснения зарабатывающих.
Т.е. github под конец весь разорился и все умерли. Happy end.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Pull requests — это исключительно и только про code review. ·>Нет, не только. Это в общем случае обмен contributions to a project.
Обмен наработками делается через push.
А в этом сценарии через code review.
V>>·>Web review — по определению для централизованнй разработки. Поэтому причём тут cvs/svn — для меня загадка. V>>Откуда ты взял "централизованной"? V>>Это просто инструмент.
V>>Он работает с произвольными бранчами и произвольными репозиториями. ·>Без центрального веб-сервера web review как-то странно работает.
Без сервера git он не работает.
Файлового или сетевого.
Ты не можешь отправить pull request в космос, ты отправляешь его через репозиторий.
·>Как работать с произвольными бранчами и репозиториями для cvs/svn — вообще загадка.
Так же.
Существовали тулзины для синхронизации репозиториев.
У нас была самописная аналогичная когда-то, там нефик делать.
V>>Не только. В git хранятся в том числе revlog-и, для целей экономии места. ·>Это что?? reflog имеешь в виду? Или delta compression ты так называешь?
Последнее.
V>>·>но когда шли войны hg vs git — это сыграло решающую роль. V>>Решающую роль сыграл github. V>>Ничего подобного халявного для mercurial не было. ·>Почему не сделали? Много всяких сайтов, на которых были и git и другие vcs.
ИМХО, потому что mercurial больше похож на коммерческую VCS.
Собсно, услугу "коммерческой поддержки" авторы стали предлагать сразу.
Ну и коммерческих серваков на ём появилось в достатке.
А git связан кровным родством с надёжным, в плане направления исключительно опенсорса, ядром линухов.
Думаю, поэтому github взял этот протокол.
Но реализация git у github-а своя, заметь.
Уже ставшая сегодня де-факто основной для всех остальных.
Я думаю, что тру-опенсорсность git была не последним фактором.
К тому же, когда разработчики ядра его юзают в постоянной работе, это означало, что даже если в какой-нибудь конкретный момент git где-то слаб, то в перспективе его допилят до нормального состояния. Т.е. это не факт и не факт, что конкурентов не допилят, но психологический фактор тоже не из последних.
Ну и, положа руку на, способы хранения данных в VCS можно развивать от версии к версии.
Собсно, эти способы и развивались по-факту что в git, что в hg.
V>>Можно сказать "заточен под определённые сценарии". ·>Которых не хватает. А расширяемость модели хранилища — никакущая.
В опенсорсе всё работает на обратной связи.
Была бы соответствующая популярность и соответствующие запросы — давно бы всё было сделано.
Так-то гит уже относительно немолодой, но более-менее зрелым стал буквально 3-4 года назад.
Причём, больше благодаря гитхабу, которая добилась исключений из протокола и команд git некоторых анахронизмов и наоборот — протолкнула добавление/развитие имеющихся фич. Т.е., в случае надобности, всё конечно допиливается.
V>>>>То бишь, легко что-то портить задним числом, как два пальца об асфальт. V>>·>Ну да. И ещё оно полезно при таком редком гипотетическом сценарии который никому никогда не нужен — процесс code review. V>>Не вижу проблем, когда code review добавляет инкрементальные изменения. V>>Не надо стесняться быть иcправленным! )) ·>Дело вкуса.
А иногда исправление показывает на какую-нить популярную ошибку.
Ведь чаще ревью делает более опытный разработчик, чем автор (не обязательно, но очень часто именно так).
Сохранение таких исправлений само по себе является наглядным пособием и способно дать пищу для размышлений другим коллегам.
V>>А вот когда что-то меняется задним числом — вижу тут сразу несколько проблем. V>>В первую очередь это вероятность прохождения волны конфликтов при обновлении коммитов (в логическом их смысле, ага). ·>Для куска под code review?
Почему нет, если текущая ветка успела "убежать", пока у ревьювера дошли руки?
V>>>>И точно так же можно посмотреть diff перед этим rebase-merge. V>>·>А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git. V>>А чем hg revert не устраивает? Или hg rollback? ·>Просто для того, чтобы почитать diff?? Ты серьёзно?
diff можно посмотреть в любой момент м/у любыми ревизиями или для 3-хстороннего мержа.
мне вопрос показался из области "а вдруг я ошибусь с коммитом?"
·>Я ничего не понял, причём тут это? А что, в hg/svn/etc это всё искаропки и их протокол всё такое поддерживает?
Да, сам hg заточен на расширение плагинами и его протокол расширяемый как опциями компрессии, так и содержимым:
extensible for new features (required and optional)
V>>·>Вот ведь гады! Исследовали рынок и дали то что рынку надо! Вот уроды, а могли бы тупо какую-нибудь херню выкатить и радоваться жизни. V>>Дело в том, что это попахивает альтруизмом, то бишь вредительством. ·>Не то что политика sf — вот уж где гениальнейший бизнес-план!
А что не так было с политикой sf тем более в конце 90-х? ))
Поначалу это было весьма простенький сайт с поиском проектов по их названию и технологиям, на которых они сделаны.
Тогда даже еще не было такой вещи как "ключевые слова для поиска", помнится.
В общем, в sf никто никогда особо не вкладывался, это весьма недорогой в разработке и поддержке проект.
Другое дело гитхаб — это высококлассный коммерческий уровень, доступный нахаляву.
Там только на ЗП 800 человекам по самым скромным подсчётам требуется 6-8 лямов $$ ежемесячно.
В общем, понятное дело, что он переехал как танком 90% других халявных ресурсов той же направленности. ))
V>>Этот проект был создан не для зарабатывания, а для вытеснения зарабатывающих. ·>Т.е. github под конец весь разорился и все умерли. Happy end.
Зачем?
MS дала людям бесплатный IE, но ей стало после этого только лучше.
В общем, кто-то позволил себе кучу лет работать в минуса.
Проскакивали цифры за какой-то год — там что-то около 27 млн дохода за весь год до выплаты налогов, за последние года не в курсе.
А так-то:
The company, which was founded back in 2008, has now taken a total of $350 million in outside funding.
Здравствуйте, vdimas, Вы писали:
V>>>Pull requests — это исключительно и только про code review. V>·>Нет, не только. Это в общем случае обмен contributions to a project. V>Обмен наработками делается через push. V>А в этом сценарии через code review.
Чтобы сделать push — надо иметь full access repo, в отличие от pull requests. Совсем другая модель.
V>>>Он работает с произвольными бранчами и произвольными репозиториями. V>·>Без центрального веб-сервера web review как-то странно работает. V>Без сервера git он не работает. V>Файлового или сетевого. V>Ты не можешь отправить pull request в космос, ты отправляешь его через репозиторий.
Ты можешь свой репозиторий расшарить readonly. Без какого-либо центрального места куда должны ломиться все в случае того же review board, должны быть админы, которые раздают права и решают кто достоин, кто нет, кто, что и как должен делать и т.п. Всё внезапно становится centralised.
V>·>Как работать с произвольными бранчами и репозиториями для cvs/svn — вообще загадка. V>Так же. V>Существовали тулзины для синхронизации репозиториев. V>У нас была самописная аналогичная когда-то, там нефик делать.
Но это будут не произвольные бранчи/репозитории. Надо будет сделать кучу соглашений и продумать всякие сценариии, чтобы это всё не накрылось и не пришлось вручную что-то как-то восстанавливать. Понятно, что и зайца можно научить курить...
V>>>Не только. В git хранятся в том числе revlog-и, для целей экономии места. V>·>Это что?? reflog имеешь в виду? Или delta compression ты так называешь? V>Последнее.
Но delta compression не имеет практически ничего общего с revlogs.
V>·>Почему не сделали? Много всяких сайтов, на которых были и git и другие vcs. V>ИМХО, потому что mercurial больше похож на коммерческую VCS.
Почему похож? И что это вообще значит? Очередная отмаза?
Мало того. помимо mercurial были всякие bazaar, darcs и т.п.
V>Собсно, услугу "коммерческой поддержки" авторы стали предлагать сразу. V>Ну и коммерческих серваков на ём появилось в достатке.
Т.е. авторы ошиблись в оценке требований рынка, а виноват в этом гит.
V>А git связан кровным родством с надёжным, в плане направления исключительно опенсорса, ядром линухов.
А мне кажется, что наоборот — git как раз и возник с целью тянуть этот самый опенсорс линух. Другие vcs просто не справлялись, потому что их делали не из практических нужд, а чтобы что-нибудь продать "у нас крутая система плагинов и вообще питон рулит!".
V>К тому же, когда разработчики ядра его юзают в постоянной работе, это означало, что даже если в какой-нибудь конкретный момент git где-то слаб, то в перспективе его допилят до нормального состояния. Т.е. это не факт и не факт, что конкурентов не допилят, но психологический фактор тоже не из последних.
А mercurial использовать для больших популярных проектов было запрещено законодательно или что?
V>Ну и, положа руку на, способы хранения данных в VCS можно развивать от версии к версии. V>Собсно, эти способы и развивались по-факту что в git, что в hg.
Детали реализации да — улучшить алгоритмы компрессии — да, можно, но не сама основа дизайна:
Mercurial or bazaar are FILE VCS (they store versions of files), and distributed.
Git is a CONTENT VCS (it stores delta of content, not the file itself: two files with the same content will be stored only once)
V>>>Можно сказать "заточен под определённые сценарии". V>·>Которых не хватает. А расширяемость модели хранилища — никакущая. V>В опенсорсе всё работает на обратной связи. V>Была бы соответствующая популярность и соответствующие запросы — давно бы всё было сделано. V>Так-то гит уже относительно немолодой, но более-менее зрелым стал буквально 3-4 года назад.
А svn сразу был идеален? Вспомнить как оно в каждую папочку клало .svn и рабочая копия внезапно вырастала по размеру в разы... А какие красивые были success story, когда после переезда внезапно размер рабочей копии git с полной историей был в неск. раз меньше, чем svn без истории.
V>>>Не вижу проблем, когда code review добавляет инкрементальные изменения. V>>>Не надо стесняться быть иcправленным! )) V>·>Дело вкуса. V>А иногда исправление показывает на какую-нить популярную ошибку. V>Ведь чаще ревью делает более опытный разработчик, чем автор (не обязательно, но очень часто именно так). V>Сохранение таких исправлений само по себе является наглядным пособием и способно дать пищу для размышлений другим коллегам.
Логи код-ревью обычно остаются публичными. Но это не означает, что они должны засирать основную vcs историю.
V>>>А вот когда что-то меняется задним числом — вижу тут сразу несколько проблем. V>>>В первую очередь это вероятность прохождения волны конфликтов при обновлении коммитов (в логическом их смысле, ага). V>·>Для куска под code review? V>Почему нет, если текущая ветка успела "убежать", пока у ревьювера дошли руки?
_Волны_? Вот это непонятно. Ну да, куску придётся догнать убежавшую ветку, но это, как правило, не является чем-то сложным.
Волна возникает, когда на ребейзнутой ветке уже кто-то что-то успел наплодить, а потом ещё и ещё. Но так всё-таки обычно никто не делает.
V>>>>>И точно так же можно посмотреть diff перед этим rebase-merge. V>>>·>А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git. V>>>А чем hg revert не устраивает? Или hg rollback? V>·>Просто для того, чтобы почитать diff?? Ты серьёзно? V>diff можно посмотреть в любой момент м/у любыми ревизиями или для 3-хстороннего мержа.
В этом и проблема, что всякие эти плагины не делают ревизий. stash хранится где-то в стороне, и ревизий у них нет. Так же после rebase старое содержимое уходит куда-то в bundle, и ревизий опять нет (я не в курсе последних новостей, но раньше было именно так). И это всё потому, что revlog диктует свои ограничения (а delta compression вообще никак не влияет).
V>·>Я ничего не понял, причём тут это? А что, в hg/svn/etc это всё искаропки и их протокол всё такое поддерживает? V>Да, сам hg заточен на расширение плагинами и его протокол расширяемый как опциями компрессии, так и содержимым: V>
V>extensible for new features (required and optional)
Ты от вопроса не уходи. Как то что ты там понаписал выше "git не умеет" реализуется в hg на базе его супер-расширяемого супер-плагинами супер-протокола? Ну например "комментировать/обсуждать строчки diff коммитов"?
Да, кстати, в git такое делается и без всякой магической расширяемости: https://github.com/google/git-appraise
V>·>Не то что политика sf — вот уж где гениальнейший бизнес-план! V>А что не так было с политикой sf тем более в конце 90-х? )) V>Поначалу это было весьма простенький сайт с поиском проектов по их названию и технологиям, на которых они сделаны. V>Тогда даже еще не было такой вещи как "ключевые слова для поиска", помнится. V>В общем, в sf никто никогда особо не вкладывался, это весьма недорогой в разработке и поддержке проект.
Ну вначале да, а потом они решили делать деньги: In July 2013 SourceForge announced that it would provide project owners with an optional feature called DevShare, which places closed-source ad-supported content into the binary installers and gives the project part of the ad revenue. Идиоты. Результат немного предсказуем: In response to the DevShare adware many users and projects migrated to GitHub, other software hosting facilities, or self-host their software.
V>Другое дело гитхаб — это высококлассный коммерческий уровень, доступный нахаляву. V>Там только на ЗП 800 человекам по самым скромным подсчётам требуется 6-8 лямов $$ ежемесячно.
Для системы такого масштаба — неудивительно.
V>>>Этот проект был создан не для зарабатывания, а для вытеснения зарабатывающих. V>·>Т.е. github под конец весь разорился и все умерли. Happy end. V>350 лямов денег подарили...
Как же... подарили... Инвестировали.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Обмен наработками делается через push. V>>А в этом сценарии через code review. ·>Чтобы сделать push — надо иметь full access repo, в отличие от pull requests. Совсем другая модель.
Чета ржу.
Что, даже не мелькнула мысль, почему этот repo не full access?
Или почему даже при наличии доступа все-равно иногда делают pull requests?
Здравствуйте, vdimas, Вы писали:
V>>>Обмен наработками делается через push. V>>>А в этом сценарии через code review. V>·>Чтобы сделать push — надо иметь full access repo, в отличие от pull requests. Совсем другая модель. V>Чета ржу. V>Что, даже не мелькнула мысль, почему этот repo не full access? V>Или почему даже при наличии доступа все-равно иногда делают pull requests?
Я нифига не понял. Опять загадками говришь. Что сказать-то хочешь?
Потелепатирую: ты путаешь "надо иметь" и "иногда можно".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Я нифига не понял. Опять загадками говришь. Что сказать-то хочешь?
Да уже всё сказано, это ты на пятый круг заходишь, а аргументы всё смешнее. ))
·>Потелепатирую: ты путаешь "надо иметь" и "иногда можно".
Не, я путаю, когда уже "надо остановиться" и когда можно попробовать "найти истину".
Классика жанра.
Просто программисты — те еще манипуляторы.
То притворяются эдакими буквоедами, борцами за точность и придираются к мелочам, а то позволяют себе формулировки такой ширины фантазии, что только глазами хлопаешь.
В первом случае истину найти еще можно.
Во втором — можно поржать под пиво.
Но когда туда-сюда — это форменное издевательство над психикой. ))
Здравствуйте, Gradiens, Вы писали:
G>И того, что кто-то (частный случай) не может найти нормальную по его мнению (частный случай) работу — вовсе не следует, что для всех все работы ненормальны.
я так полагаю, он просто от нефиг делать сюда петросянить приходит. так сказать инвариантно к работе и ее наличию. Не знаю как у вас, у меня особого отклика креативы аффтора не находят, хотя в индустрии тоже не первый год.
А чего ты взял что можно закоммитить туда какой-то бакдор?
