1. Введение
SQLite не использует Git. Вместо этого у нас работает система управления версиями Fossil, специально разработанная и написанная для поддержки SQLite.
Люди иногда спрашивают, почему SQLite не использует Git, как все остальные. В статье мы попробуем ответить на этот вопрос. Кроме того, в третьем разделе приводятся советы для пользователей Git, как легко получить доступ к исходному коду SQLite.
1.1. Правки
Статья несколько раз пересматривалась, чтобы внести ясность, ответить на опасения и тревоги, а также исправить ошибки, выявленные на Hacker News, Reddit и Lobsters. Полная история редактирования здесь.
2. Несколько причин, почему SQLite не использует Git
Все причины, по которым SQLite не использует систему Git, можно выразить одним предложением: ведущий разработчик SQLite считает это неприемлемым. Если вам нравится Git и вы хотите использовать её, то отлично. Я же не люблю Git и предпочел бы что-то получше, на мой взгляд.
Ниже приведены некоторые причины, почему мне не нравится Git:
2.1. Git затрудняет поиск потомков после коммита
Git позволяет легко вернуться назад во времени. Учитывая последний коммит (check-in) в ветке, Git показывает всех его предков. Но движение в другом направлении затруднено. Если взять какой-то прошлый коммит, то в Git довольно сложно узнать, что последовало дальше. Это можно сделать, но достаточно сложно, так что люди редко пользуются такой возможностью. Популярные интерфейсы для Git, такие как GitHub, не поддерживают эту функцию.
Да, в Git есть возможность найти потомков. Просто это сложно. Например, на этой странице StackOverflow описана последовательность команд под Unix для поиска потомков:
git rev-list --all --parents | grep ".\{40\}.*.*" | awk '{print $1}'Такую последовательность команд трудно запомнить и долго набирать (можно создать bash-алиас или маленький shell скрипт, если команда часто используется). Но это не совсем то. Такая команда даёт список потомков без важной для понимания структуры ветвлений. Для сравнения, Fossil предлагает такое отображение. Это огромное подспорье при анализе последствий сделанных изменений.
И дело не только в том, чтобы время от времени находить потомков после возврата. Сам факт их легкодоступности в Fossil означает, что информация автоматически попадает на веб-страницы, которые выдаёт Fossil. Один пример: на каждой странице Fossil с информацией о коммите (пример) есть маленький график «Контекст» с указанием непосредственного предка и потомков. Это помогает для лучшей ситуационной осведомлённости, а также даёт разные полезные возможности, такие как возможность перейти к следующему коммиту в последовательности. Другой пример: Fossil легко показывает контекст возле конкретного коммита (пример), что опять же помогает повысить ситуационную осведомленность и более глубоко понять, что происходит в коде.
Всё вышеперечисленное возможно и с Git, если использовать правильные расширения, инструменты и правильные команды. Но это не так просто, и поэтому делается редко. Следовательно, разработчики меньше осведомлены о том, что происходит в коде.
2.2. Ментальная модель Git излишне сложна
Сложность Git отвлекает внимание от разработки программного обеспечения. Пользователь Git должен всегда держать в уме:
- Рабочий каталог.
- «Индекс» или область подготовки (staging area).
- Локальный заголовок (HEAD).
- Локальная копия удалённого заголовка.
- Реальный удалённый заголовок.
В Git есть команды (или опции команд) для перемещения и сравнения контента между всеми этими локациями.
Для сравнения, пользователи Fossil думают только о своём рабочем каталоге и о том коде, над которым работают. Это на 60% меньше отвлечений. Рабочая память любого разработчика ограничена. Fossil требует меньше рабочей памяти, освобождая интеллектуальные ресурсы непосредственно для программирования.
Один пользователь Git и Fossil написал в HN:
«Fossil даёт душевный покой и ощущение, что всё в порядке… синхронизируется с сервером одной командой… Такого душевного спокойствия никогда не было с Git».
2.3. Git не отслеживает исторические названия ветвей
Git сохраняет полный DAG последовательности коммитов. Но теги ветвей — это локальная информация, которая не синхронизируется и не сохраняется после закрытия ветви. Это делает утомительным анализ старых ветвей.
Сравним отображение одной исторической ветки SQLite в GitHub и в Fossil.
Fossil ясно показывает, что ветвь в конечном итоге влилась обратно. Чётко обозначено её начало и видно два случая, когда в ветку влились изменения из транка. GitHub ничего этого не показывает. На самом деле отображение GitHub практически никак не помогает выяснить, что произошло.
Многие читатели рекомендовали различные сторонние GUI для Git, которые лучше показывают историю разработки. Возможно, некоторые из них работают лучше, чем родной Git и/или GitHub, но все они будут страдать из-за того, что Git не сохраняет исторические названия ветвей при синхронизации. И даже если они действительно помогают, сам факт необходимости использовать сторонние инструменты говорит не в пользу базовой системы.
2.4. Git требует дополнительной административной поддержки
Git — это сложное программное обеспечение. Для установки Git на компьютер разработчика или для обновления требуется какой-либо инсталлятор. Настройка сервера Git нетривиальна. Можно было бы использовать GitHub, но это вводит ещё одну стороннюю зависимость, а централизованная служба устраняет ключевое преимущество Git, которое заключается в «распределённости». Существуют различные бесплатные альтернативы вроде GitLab, но там тоже много зависимостей и требуется серьёзная настройка сервера.
В отличие от них, Fossil — это один отдельный бинарник, который устанавливается путём размещения в $PATH. Этот единственный бинарник содержит всю функциональность Git, а также и GitHub и/или GitLab. Он управляет сервером сообщества с вики и баг-трекером, обеспечивает пакетную загрузку для пользователей, управление авторизацией и прочее — без дополнительных программ.
Меньше администрирования — это значит, что программисты больше времени тратят на разработку ПО (в данном случае SQLite) и меньше — на суету с системой управления версиями.
2.5. Git неудобен в использовании
Эта карикатура — преувеличение, но бьёт почти в цель:
— Это Git. Он отслеживает совместную работу над проектами с помощью прекрасной распределённой модели деревьев из теории графов.
— Классно. Как её использовать?
— Без понятия. Просто запомни эти команды шелла. Вводи их, когда нужно синхронизироваться. Если выскочит ошибка, сохрани где-нибудь свою работу, удали проект и скачай свежую копию.
Будем реалистами. Мало кто спорит, что у Git неоптимальный пользовательский интерфейс. Он настолько плох, что есть даже пародийный сайт, который генерирует страницы фейкового мануала git.
Проектировать ПО сложно. Это требует большой концентрации. Хорошая система управления версиями должна помогать разработчику, а не огорчать его. За последнее десятилетие Git стал лучше в этом отношении, но предстоит пройти ещё долгий путь. До тех пор разработчики SQLite продолжат использовать другую систему управления версиями.
3. Руководство пользователя Git по доступу к исходному коду SQLite
Если вы преданный пользователь Git, вы всё равно можете легко получить доступ к SQLite. В этом разделе приведены некоторые советы.
3.1. Зеркала на GitHub
Есть зеркало дерева исходного кода SQLite на GitHub. Его поддерживает пользователь mackyle, который не связан с командой разработчиков SQLite и неизвестен нам. Мы не знаем Маккайла, но видим его потрясающую работу по поддержанию зеркала в актуальном состоянии. Поэтому если хотите получить доступ к исходному коду SQLite на GitHub, то его зеркало — рекомендуемый источник.
3.2. Доступ через веб
Репозиторий SQLite Fossil содержит ссылки для скачивания Tarball, ZIP или архива SQLite для любой версии SQLite. URL-адреса простые, так что скачивание версий легко автоматизировать. Формат такой:
https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz Просто замените VERSION на номер загружаемой версии. Это может быть префикс криптографического хэша определенного включения или имя ветви (в таком случае выбирается последняя версия ветви), или тег для конкретного билда, например, “version-3.23.1”:
https://sqlite.org/src/tarball/version-3.23.1/sqlite.tar.gz Чтобы скачать последний релиз, используйте “release” вместо VERSION:
https://sqlite.org/src/tarball/release/sqlite.tar.gzЧтобы получить последний возврат транка, используйте “trunk” вместо VERSION:
https://sqlite.org/src/tarball/trunk/sqlite.tar.gz И так далее. Для архивов ZIP и SQLite просто измените элемент “/tarball/” или на “/zip/”, или на “/sqlar/”, а таже можете изменить имя скачиваемого файла на “.zip” или “.sqlar”.
3.3. Доступ через Fossil
Fossil прост в установке и использовании. Вот пошаговая инструкция под Unix (под Windows инструкция похожа).
- Загрузите автономный исполняемый файл Fossil с этой страницы и поместите его где-нибудь в $PATH.
mkdir ~/fossilsfossil clone https://sqlite.org/src ~/fossils/sqlite.fossilmkdir ~/sqlite; cd ~/sqlitefossil open ~/fossils/sqlite.fossil
Теперь вы готовы набрать
./configure; make (или в Windows с MSVC nmake /f Makefile.msc).Чтобы обновиться на другую версию Fossil, используйте команду
update:fossil update VERSIONИспользуйте “trunk” для последней версии SQLite. Как вариант — префикс криптографического хэша, имя какой-либо ветви или тега. См. вики для дополнительной информации, какие имена можно использовать для VERSION.
Команда
fossil ui в ~/sqLite поднимает локальную копию веб-сайта.Дополнительную документацию по Fossil см. здесь.
Не бойтесь исследовать и экспериментировать. Без авторизации вы не сможете запушить никакие изменения, так что не повредите проекту.
4. Дополнительно
Вот ещё несколько страниц, где обсуждаются Fossil и Git:
Комментарии (143)
olegy
17.04.2018 15:38+1Часто наблюдал такое у embeded разработчиков — нежелание осваивать чужой инструмент.
Такие себе крестьяне единоличники — построят свой домик, огородятся забором и даже свою систему контроля версий изобретут ;)
PS:
Торнвальдса это тоже касается с гитом :)
nsinreal
18.04.2018 01:38Ну, соблазн большой. Довольно трудно отказаться от своего глючного велосипеда в пользу чужого глючного велосипеда
neumond
18.04.2018 07:45До гита ядро разрабатывалось с помощью BitKeeper. Там точно история не о нежелании осваивать.
nikialeksey
17.04.2018 15:51Я полностью согласен с картинкой в этой статье про использование гита. Однако я еще ни разу не попадал в нерешаемые ситуации, и не тратил много времени на гит. Наверное, в моих проектах был всегда строгий флоу
DancingOnWater
17.04.2018 15:52+1«Индекс» или область подготовки (staging area).
Локальный заголовок.
Локальная копия удалённого заголовка.
Реальный удалённый заголовок.
Вот это что я сейчас прочитал? Какой заголовок. Это о чем? о локальной копии удаленной ветки?
farcaller
17.04.2018 16:09+2я тоже задумался. Это HEAD же :-)
DancingOnWater
17.04.2018 16:44По идее да. Но нафига программисту помнить о HEAD его ветки, если он начинает слияние. Ведь это то, что у него в каталоге.
Зачем ему помнить о хеде его локальной копии удаленно ветки. По идее, он может ее тронуть только в экстремальной ситуации.
Иными я словами, я не понимаю что у них вызывает проблемы.
k12th
17.04.2018 17:21+6Ожидал более обоснованной критики...
С 2007 юзаю системы контроля версий (git где-то с 2011), никогда не приходилось искать потомок коммита.
История веток видна, если делатьgit merge <feature-branch> --no-ff(ну ок, это, возможно фича гитхаба/битбакета/гитлаба, тем не менее это не проблема).
Вот дофигалиард странных суб-команд и странных опций это да, валидный аргумент. Но, как справедливо указывает Рэндолл Мунро, в повседневной работе достаточно ~5 команд, всё остальное — для исключительных случаев и продвинутых пользователей.
Тем не менее, fossil выглядит достаточно интересно. Но для личных проектов лень возиться с инфраструктурой и разворачивать на сервере какие-то бинарники (тем более через, прости господи, CGI), а SaaS решений c Fossil я не видел.
Barafu
17.04.2018 18:25+1Вся критика сводится к: у людей была система контроля версий и был workflow, заточенный под её косяки. Теперь они смотрят на git, но не хотят ничего менять в workflow. А git не заточен под косяки чуждого workflow, что ему и ставится в вину.
MacIn
17.04.2018 18:42+5Если git заточен под свои (другие) косяки, то зачем им, в sqlite, перенимать эти чужие? Если уж при их разработке преимущества git'а не используются.
ApeCoder
18.04.2018 13:31Все нераспространенное имеет крупный недостаток по сравнению со всем распротранненным — оно не поддерживается сторонними разработчиками. Есть этот FOSSIL для Idea, VS code, VS, Eclipse и прочего?
MacIn
18.04.2018 13:35Не знаю. Никогда не пользуюсь СКВ, встроенными в IDE. Лично для меня СКВ — всегда отдельный инструмент.
awesomer
18.04.2018 13:49Есть этот FOSSIL для Idea, VS code, VS, Eclipse и прочего?
М?
Зачем до такой степени то лениться?ApeCoder
18.04.2018 13:53Зачем до такой степени то лениться?
Просто мне есть чем заняться кроме плясок вокруг системы контроля версий. Само по себе набирание командочек мне неинтересно. Для меня лучшая СКВ, которой нет.
awesomer
18.04.2018 16:21Просто мне есть чем заняться кроме плясок вокруг системы контроля версий. Само по себе набирание командочек мне неинтересно. Для меня лучшая СКВ, которой нет.
В статье расписано — почему именно они выбрали другую.
Как раз потому, что с ней проще. Что она экономит время. По их мнению.
ApeCoder
18.04.2018 16:59Так в статье рссмотренны недостатки гит, но не рассмотрены преимущества. Может они не обо всех знают. Вопрос в том, стоило ли оно для них. Разумеется любимое детище кажется им ближе
k12th
17.04.2018 20:35+1Насколько я помню, git примерно так и появился, заточенный под косяки предыдущего воркфлоу (убей не помню, как называлась VCS которую они использовали до того).
k12th
17.04.2018 20:42Насколько я помню, git примерно так и появился, заточенный под косяки предыдущего воркфлоу (убей не помню, как называлась VCS которую они использовали до того).
Xitsa
18.04.2018 09:52Но для личных проектов лень возиться с инфраструктурой и разворачивать на сервере какие-то бинарники (тем более через, прости господи, CGI), а SaaS решений c Fossil я не видел.
Я как раз для личных проектов использую fossil, так как не хочу возиться с инфраструктурой и разворачиванием чего-либо на сервере.
Репозиторий в fossil — это один файл его можно хранить, например, в dropbox'е, бинарник тоже один, причём устанавливать его не нужно, достаточно при необходимости скачать.k12th
18.04.2018 11:52Помимо "скачать", его нужно запустить, обеспечить запуск после ребута (он же в режиме демона пуши принимает, не так ли?) настроить права доступа, настроить в nginx поддомен или путь. Вот это мне всё лень:)
А зачем хранить репозиторий в дропбоксе, я вот не очень понял. В качестве дополнительного бэкапа?
Xitsa
19.04.2018 07:52Нет :), как раз этого всего делать не надо.
Скачивание репозитория — это фактически его клонирование, после этого можно с ним работать локально. Ничего ставить не надо, всё уже есть в приложении, его можно запускать без дополнительной настройки.
В дропбоксе я держу клоны репозиториев, чтобы при необходимости иметь к ним доступ со стороны.k12th
19.04.2018 10:06Я говорю про сервер, а не рабочие машины. Ну если вы через дропбокс синхронизируетесь, тогда понятно.
semmaxim
17.04.2018 18:52+3Часть проблем решена в Mercurial + TortoiseHg
PavelMSTU
17.04.2018 20:54+1Ждем пост «Почему SQLite не использует Mercurial»
:))
Ну а если честно, лично мне тоже больше нравиться Mercurial. Он проще, понятнее. Git слишком перегружен. Но… Git самый популярный, поэтому если ты идёшь на новый проект, то с вероятностью 95% там гит.
Wolf4D
17.04.2018 21:12Как человек, пересевший при присоединении к крупному проекту с Mercurial на Git — могу сказать, что именно степень недружелюбности Git-а к начинающему (что консольного, что GUI) после простого, понятного и наглядного TortoiseHg стала для меня шоком. В Mercurial я «сел и поехал» во многом именно благодаря хорошему «изкоробочному» GUI, а вот вникание в Git было затруднительным. Был бы внятнее пользовательский интерфейс — переход прошёл бы гораздо легче.
Мне очень помог на первых порах SmartGit — по сути, это аналог TortoiseHg, только существенно более продуманный. Идеи Tortoise получили своё развитие — например, возможность в интерактивном режиме делать этакий микро-diff, просматривая в небольшом окошке текущие изменения в проекте, отмечая для себя важные изменения, перенося или удаляя незакомиченные правки — это чудесное изобретение! Можно также смотреть, что за команда передаётся непосредственно бинарнику git при совершении того или иного действия. Да сложную Гит-магию в SmartGit сделать затруднительно, но для 90% простых задач обращаться к консоли, по сути, и не приходится.Gemorroj
17.04.2018 22:46+3Git, имхо, взлетел потому что github, а не потому что сам git такой хороший.
С hg помню проблемы с юникодом были (давно правда, лет 5 назад).
artemisia_borealis
18.04.2018 00:02да, тоже считаю, что hub в этих шести буквах важнее.
Но нужно добавить, что ведь есть ещё svnhub.com, т.е. фактически поддержка subversion со стороны github. Т.е. была (и есть) возможность содержать свои проекты на svnhub и/или импортировать их в git. Это тоже добавило очков git'у.
wert_lex
18.04.2018 09:59у hg была "проблема" (надеюсь починили давно) с тем, что в нём нельзя отслеживать удалённые ветки из других репозиториев. Только репозитории целиком.
Для home brew разработки это ни разу не проблема, а вот для более взрослой — уже сложнее.
Опять же, были некие костыли которые решали проблему, но уже не помню деталей.
Хотя Mercurial нежно люблю за его человеко-ориентированный интерфейс :)
Bonart
18.04.2018 07:33SmartGit как "существенно более продуманный" аналог TortoiseHg — очень хорошая шутка.
Платный, тормозной, некостистентный, с древним дизайном, с кучей неотключаемых модальных окон — это все SmartGit, и smart в его названии — явный сарказм. Если кто подскажет gui-клиент, умеющий в split commit, то я с удовольствием выкину smartGit и забуду как страшный сон.
Deosis
18.04.2018 09:22Для разделения коммита я использую стандартный git for windows.
В GUI выбрать опцию amend, потом разнести изменения по нескольким коммитам.
Если надо разделить не последний коммит, то добавляется пара команд из консоли.Bonart
18.04.2018 09:39Если надо разделить не последний коммит, то добавляется пара команд из консоли.
Я не против консоли для редких вариантов использования, а также случаев, когда GUI недоступен.
Но в рамках принятого текущим работодателем процесса разделение коммита (не последнего) — вариант типовой.
mayorovp
18.04.2018 09:34Если кто подскажет gui-клиент, умеющий в split commit
Git Extensions. Напрямую кнопки сделать split commit там нет — но можно сделать mixed reset после чего накатить коммиты по частям, для чего есть удобное окно где можно делать Stage/Unstage отдельным строкам из диффа.
Bonart
18.04.2018 09:41Это все я делал, по объективным результатам и субъективным ощущениям — худший сорт того же самого.
mayorovp
18.04.2018 09:43А если не секрет, откуда вообще берутся коммиты которые потом приходится разбивать?
Bonart
18.04.2018 09:49Необходимость разбиения возникает из доведенных до предела требований к атомарности коммитов: одно и только одно логическое изменение на коммит.
Miron11
18.04.2018 13:50Не знаю… у меня все эти «атомарности» в одном месте зудят.
У Гит не существует «атомарного» древа. Оно или весь репозиторий, или ничего. И когда три разработчика работают над общим проэктом, а «common» репозиторий в любом проэкте приличного размера это больше половины веса ПО, то получается невообразимая чехарда, из — за которой проэкт приходится перекраивать под возможности хранилища текстовых исходников.
wildvampir
18.04.2018 09:43+1SourceTree?
Bonart
19.04.2018 21:24Не умеет в Split Commit. В его трекере эта фича уже три года, приоритет низкий, никому не назначена.
Killy
19.04.2018 00:57Я какое-то время использовал SourceTree параллельно с GitHub Desktop.
В гитхабовом клиенте, пожалуй, самый удобный split commit.
Но в итоге, устав от разных других недостатков обоих клиентов, перешёл на GitKraken.
Самый продуманный клиент git под Windows. Впервые после TortoiseHg не страшно за каждый шаг, и всё как на ладони.
Split commit тут вполне сносный (показывает изменения чанками, но строки тоже можно выделять).
Из недостатков — запускается долго и тот же выбор строк в стедж подтормаживает на больших файлах. Ну и free for personal use только.
В VSCode тоже теперь можно построчно стейджить изменения. Если бы не GitKraken, на данный момент предпочёл бы VScode + GitLens другим клиентам.
michael_vostrikov
19.04.2018 14:28Если кто подскажет gui-клиент, умеющий в split commit
Ну так TortoiseGit. В диалоге интерактивного rebase, если для коммита поставить "Edit", то после запуска процесс на нем останавливается и появляется галочка "Edit/Split commit".
reskator
20.04.2018 11:45Клиент, умеющий в split commit — SouceTree, от Atlassian.
Bonart
20.04.2018 12:25Интересно, как именно?
Согласно трекеру, такой функциональности в SourceTree нет
jira.atlassian.com/browse/SRCTREE-3036
netch80
18.04.2018 13:41Вот почему-то у меня получилась полностью противоположная вкусовщина.
Сначала RCS (ещё в мохнатые 90-е), CVS. Попытка SVN, Arch — не зашли. Mercurial — не пошёл, всё типа понятно, но «не то» (а уж диверсии типа множественных голов...); что в итоге не так — описал 1, 2, 3, 4 и так далее. Git — после минимального освоения и разумной централизации, где нужно — устаканился идеально. (После этого, когда рассказывают, мол, SVN и Mercurial после CVS заходят идеально, а для Git надо что-то выламывать в голове — скептически ухмыляюсь.)
chersanya
17.04.2018 22:55+1Да, вот уж по удобству использования меркуриал реально намного выше гита. Жаль, что гит по факту победил.
Bonart
18.04.2018 09:35Победил не гит, а гитхаб.
А вместе с гитхабом я использую меркуриал, подключаясь с помощью расширения hg-git
К сожалению, все косяки дизайна гита так не исправить.wert_lex
18.04.2018 10:04Кстати, про косяки дизайна гита. У меня тоже был исключительно положительный опыт с Mercurial, пока не случилось так, что пришлось пользоваться гитом. Мыши плакали, кололись, а потом почитали инструкцию и немного о том, как он внутри устроен. И косяки дизайна уже не выглядят такими уж и косяками. WAT-ов конечно хватает, но не так всё страшно на самом деле ( кроме
git checkout -bразумеется :) )Bonart
18.04.2018 10:26-1Я инструкцию читал с самого начала, но ряд косяков так и остались косяками:
- В гите нет веток, а ветками называют именованные головы.
- В гите нельзя закрыть ветку — только удалить.
- В гите нет перемещения и переименования файлов.
- В гите черри-пик не знает, откуда его скопировали.
Deosis
18.04.2018 12:47- Сначала дайте определение ветки.
- Что значит закрыть ветку? В гите это просто указатель на коммит.
- Это не проблема гита. Внешние инструменты, вычислив разницу между коммитами, могут сказать, что файл был перемещен, на основании % совпадения содержимого файла
- Гит хранит историю состояний рабочего каталога. Есть хоть одна ФС, которая хранит, откуда скопирован файл?
sumanai
18.04.2018 12:57Что значит закрыть ветку? В гите это просто указатель на коммит.
В этом и проблема, информация о ветке теряется.
Это не проблема гита. Внешние инструменты, вычислив разницу между коммитами, могут сказать, что файл был перемещен, на основании % совпадения содержимого файла
Это проблема гита. Внешние инструменты не могут повлиять на разрешение конфликтов при мерже, к примеру.
Bonart
18.04.2018 13:17Сначала дайте определение ветки.
Для систем контроля версий — подграф взаимосвязанных коммитов, которому можно дать имя. Это вполне соответствует веткам для математического дерева или даже обычного живого дерева.
И только в гите ветка — это всего лишь именованный мутабельный указатель на коммит и не более.
Что значит закрыть ветку? В гите это просто указатель на коммит.
Самая обычная вещь: я не хочу больше изменять ветку (и видеть ее как опцию для соответствующих команд), но хочу, чтобы коммиты по-прежнему ей принадлежали. Так обычно поступают с ветками для закрытых задач. В гите ее приходится удалять, а принадлежность коммитов маркировать другими средствами.
Это не проблема гита.
Это проблема гита. Перемещение и переименование для всех есть, а для гита нет. Его приходится угадывать с помощью костылей с переменным успехом. Забавно смотреть, как меняется видимая история файла, в зависимости от настройки чувствительности поиска. Обычно приходится разбивать коммит с перемещениями-переименованиями на два — в одном менять содержимое файлов, в другом перемещать-переименовывать.
Гит хранит историю состояний рабочего каталога. Есть хоть одна ФС, которая хранит, откуда скопирован файл?
Этот вопрос нерелевантен проблеме и отсылает к ФС, которая в контроль версий не умеет от слова совсем.
А в системе контроля версий обычно полезно знать, из какой ветки взят коммит, выполненный командой cherry pick. В гите для этого есть возможность указать в сообщении хеш оригинального коммита. Но сам гит про это ничего не знает, нигде не хранит и никак не показывает, в отличие, например, от меркуриала.
saboteur_kiev
19.04.2018 02:20Мало кто использует гит в чистом виде.
Пользуются гитхабом, битбакетом, герритом — а через них можно настроить дополнительные фичи, типа закрыть ветку.
git mv file1 file2 — что не так?Bonart
19.04.2018 02:47можно настроить дополнительные фичи, типа закрыть ветку
И как будет выглядеть закрытая ветка гита в моей локальной репе? И чему соответствовать в удаленной?
git mv file1 file2 — что не так?
Строго по документации: работает в точности как добавление файла на новом месте и удаление в старом. Никакого перемещения на уровне истории не добавляет.
saboteur_kiev
19.04.2018 10:44И как будет выглядеть закрытая ветка гита в моей локальной репе? И чему соответствовать в удаленной?
Вы не сможете ничего запушить в удаленную ветку.
Соответствовать будет ветке с таким же именем. Собственно в чем проблема? Это активно используется.Bonart
20.04.2018 13:39Вы не сможете ничего запушить в удаленную ветку.
Этого мало. Я не должен видеть эту ветку в списке тех, в которые пушить можно.
И мне интересно, как это будет работать, если
- на сервере инструмент над гитом один,
- у меня локально — другой,
- вся связь между ними — только через гит
- сами инструменты друг о друге не в курсе.
Akon32
18.04.2018 14:09Автодетект перемещений файлов мне наоборот всегда казался более удобным, чем необходимость дополнительно отмечать каждое перемещение/переименование в других VCS.
sumanai
18.04.2018 14:14Дело не в автоматике, которая, бесспорно, удобнее, а в том, может ли система контроля версий использовать эту информацию в будущем.
Bonart
18.04.2018 15:00В других VCS необходимости нет точно так же: удаление и добавление файлов поддерживается везде.
Зато есть возможность указать правильное переименование/перемещение (определив его в том числе автодетектом) и сохранить в истории.
Гит же вынужден гадать всегда: у него в истории такой информации нет.Miron11
18.04.2018 15:46-1Вообще — то это файловая система тоже не хранит записи о переименовании того или иного файла. Во всех без исключения репозиториях эти детали являются частью протокола изменения имени/переноса файла, который создан человеком, и интерпретируется в свою очередь, графическим приложением-клиентом не из той или иной «команды», но из определенного набора шагов, с определенными комментариями или тегами, которые автоматически поддерживает графическое приложение.
Что Гит не может вообще, это сделать древо из изменения имени одного файла. Ему нужно сделать древо из всего репозитория. И поэтому перед любым коммитом в группе разработчиков первое это «merge», которое может окончиться (не)известно чем. Поэтому «стандартный протокол» это
1. создать резервную копию
2. если повезет быстренько все что нужно закоммитить или продолжить к 3.
3. восстанавливай резервную копию, выполняй пункт 2
Miron11
18.04.2018 14:25-3Помню давний разговор с админом «почему мы перешли на Гит». Говорит умные люди решили. Говорит: «Поиск текста в старых ревизиях медленно работает.»
Спустя 5 лет выяснилось…
Кстати, как — то проходил интервью в одной фирме, обслуживающей адвокатов. Они свои документы в какой — то момент в ГитХаб закачали. Вроде бы удобно. Особенно в командировках. А потом в один прекрасный день пришлось восстановить все с резервной копии. И потеряли все «папки» процесса, который был в суде. Кипишь был… Ну потом построили то, что надо, и считалочку «не бывает плохого ПО, бывают ленивые разработчики, которые не любят осваивать новые пакеты» в туалетах со стен вытерли.
А так… вроде продукт есть. Вроде бы бесплатно… Ну и там в разных компаниях любят присылать вопрос «пришлите URL с вашим прортфолио на ГитХаб».
Как Оби-Ван-Кенуби с лазерным мечиком. Индастрил Лит Унт Мазик. Хлоп — он есть, хлоп — его нету. Передовое общество воодушевлено иллюзией, пока одинокий интеллигентный человек не оказывается вечером на мосту, один на один с маленьким и очень фотогеничным мальчиком, предлагающим купить кирпич, или попрыгать на майдане.mayorovp
18.04.2018 15:19+1Ну и как они умудрились их потерять в гите? Ваша история явно неполная без технических подробностей.
Miron11
18.04.2018 15:52GPL перечитайте. Она начинается со слов «не несет никакой ответственности и не дает никаких гарантий».
Miron11
18.04.2018 16:07-2И даже не в этом дело. Мы ведь здесь на хабре, отдела кадров у Вас нет. И я могу Вам сказать прямо, в чем проблема. Есть такое понятие, описываемое английским словом liability. По — русски его переводят «ответственность». В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт. От слова вообще.
awesomer
18.04.2018 16:30+2В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт.
GPL перечитайте. Она начинается со слов «не несет никакой ответственности и не дает никаких гарантий».
git с ее GPL — это всего лишь программа.
а ГитХаб — уже услуга.
наверняка документы для судебного процесса размещались не в бесплатных открытых репах ГитХаба.
а в оплачиваемых закрытых.
а это — коммерческая услуга. получил деньги — будь добр отвечай за некачественно предоставленные услуги по хранению.
уже кто кто, а адвокатская контора, о которой идет речь — уж смогла бы отсудить.
так что что-то вы не договаривайте.
но любая услуга по хранению должна быть обязательно дублирована в другом месте. бэкапы она не отменяет, да.Miron11
18.04.2018 16:52-4Я ничего не недоговариваю. Все как есть и как было. Гит не несет ответственности. Вообще ни за что. Кроме одного. Прибыль владельца. Единственная корпорация с полной ответственностью за все владения каждого человека в истории человечества была и будет СССР.
У Вас иллюзия с лазерным мечиком, а не интеллект.ApeCoder
18.04.2018 17:23Кстати, как — то проходил интервью в одной фирме, обслуживающей адвокатов.
насколько я понял в ситуации вы детально не разбирались, а просто услышали историю на интервью?
Miron11
18.04.2018 17:29-3«История на интервью» или «дядя купи киприч».
Бугая сзади нету, фотогеничный мальчик.
sumanai
18.04.2018 19:56В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт. От слова вообще.
Назовите мне компании, которые несут хоть какую-то ответственность. Практически везде прописан отказ от неё. Если винда угробит все файлы на ней, максимум, что вы можете получить, это возмещение её стоимости. С макос не знаю, не встречал случаев, уверен, что тоже самое. Linux тоже на GPL. По вашему, в общем, нигде нет гарантий. И так оно и есть, просто нужны бекапы. Всегда и везде. На независимые накопители, с историей, и шифрованным дубликатом в географически разделённое место, и проверкой его восстанавливаемости.staticlab
18.04.2018 22:37С макос не знаю, не встречал случаев, уверен, что тоже самое.
Да, то же самое: мы ни при чём и ни за что не отвечаем, пользуйтесь на свой страх и риск. В крайнем случае мы вам максимум $50 вернём.
Miron11
19.04.2018 18:56-2«Назовите мне...»
***
Экий Вы п-п-п-п-простачек, от английского слова «новичок».
С такими п-п-п-простачками заикой стать можно. У компании Microsoft в контракте с пользователем записан «indemnification clause». Ищите перевод.
Господи, что делать с дилетантами. Они же все и всех убьют и скажут, что действовали во благо человечества. Чем они успешно и занимаются по всему миру.
staticlab
19.04.2018 09:17Они свои документы в какой — то момент в ГитХаб закачали. Вроде бы удобно. Особенно в командировках. А потом в один прекрасный день пришлось восстановить все с резервной копии. И потеряли все «папки» процесса, который был в суде.
Git — распределённая система. Неужели ни у кого не было рабочей копии? И причём тут гит? С таким же успехом Bitbucket мог бы откатить реп на меркуриале, а условный FossilHub откатил реп фоссила.
Akon32
19.04.2018 12:14+2Если кто-то сумел утерять документы, хранимые в git'е (в то время как миллионы разработчиков его успешно используют), это не значит, что git плохой. Это скорее всего означает, что у кого-то руки кривые и растут не из плеч.
Схема, когда кто-то несёт ответственность, по-своему хороша. Но в мире ПО вы не часто её встретите. Бэкапы никто не отменял.
И вообще-то, git хранит полную историю изменений (все версии всех файлов) у каждого пользователя, кто клонировал и обновлял репозиторий. Это значит, что у вас обычно есть как минимум десяток бэкапов, даже если их не делать. Если контора не использовала стандартный, описанный в инструкции, процесс работы с git; или же после сбоя не смогла найти у себя файлы, это говорит о невысоком уровне компьютерной грамотности у её пользователей.
splav_asv
19.04.2018 13:31Скорее всего github использовался без локального клонирования вообще. Исключительно через веб-интерфейс (как оказалось — так тоже можно какой-то степени жить, интерфейс довольно много всего позволяет делать). Однажды такое видел — минут десять в себя приходил…
mayorovp
19.04.2018 14:34Но через веб-интерфейс нельзя сделать никаких разрушительных изменений, вроде git push -f, так что все равно не понятно…
svr_91
19.04.2018 16:35Не знаю, как сейчас, но по крайней мере года 2 назад потерять коммит в гит можно было довольно просто:
1) Создать репозиторий
2) Подключить репозиторий как субмодуль к другому репозиторию
3) Зайти в этот субмодуль и внести изменения
4) Закоммитить
5) Где коммит???
Вроде такая была схема, но точно не помню.
Понятно, что скорее всего коммит где-нибудь сохранился, но искать его — это то еще удовольствиеAkon32
19.04.2018 16:505) Где коммит???
Там, куда его закоммитили в п.4 ?
В git есть много способов потерять данные, делая что-либо неправильно. Но базового понимания работы git и знания (и соблюдения) типичных последовательностей действий (типа commit-pull-push) достаточно, чтобы неправильно не делать. И тогда вы вряд ли что-либо потеряете.
Недружелюбность к неопытным пользователям — есть такой минус в git, но он со всеми его недостатками таки стал де-факто стандартом.
svr_91
19.04.2018 17:15А куда я его закоммитил? Я его закоммитил в субмодуль. Там он и должен быть.
Фишка в том, что если коммитить в обычный репозиторий, то гит даст закоммитить в reference HEAD, или как он там называется (то бишь, последний коммит в ветке). Но если переключиться git checkout-ом в определенный коммит, то гит закоммитить уже не даст. Но для субмодулей эта проверка почему-то не работает (по крайней мере, так было некоторое время назад), и если субмодуль смотрит не на последний коммит, а на какой-то промежуточный (что довольно часто при обновлении субмодулей и репозиториев), то есть возможность потерять коммит
Я уже в точности не помню всю последовательность действий, может я где-то и наврал, но сам я так несколько раз терял коммитыmayorovp
19.04.2018 17:24Но ссылка на этот коммит остается во внешнем репозитории, и изменения все еще доступны из него…
PS лично я бы просто организационно запретил коммиты в сабмодули. Просто потому что разделяемый код не должен зависеть от тех проектов где он используется. Иначе получится как с нашим внутренним форком одной библиотеки, где большая часть коммитов — это добавления рандомных конфигураций в файлы проектов.
Akon32
20.04.2018 12:30Ну да — есть такая "особенность": submodule update делает checkout ревизии, а не ветки. Поэтому перед коммитом в сабмодуль нужно переключаться в нём на ветку. Дико неудобно, но, если использовать gui-клиент, ошибки допустить сложнее.
Aytuar
17.04.2018 19:20+3Блин карикатура точно соответствует реальности, у меня оно так и получается. :-(
govage
17.04.2018 19:20Лучше бы написали, почему Git не использует SQLite
Akon32
18.04.2018 12:16Так и знал, что на самом деле SQLite не использует git, потому что git не использует SQLite. Fossil — использует.
Но если копнуть глубже, то окажется, что реализации файловых систем (ext4, btrfs, xfs) используют git.
Забавно.
awesomer
17.04.2018 19:20Народ, а кто-то реально уже использует пихуль (pijul)?
Автор так расписывают, так расписывают.
Мол, основан на крутейших концепциях из хаскелевского darcs, но написан на быстром и безопасном Rust и пр. и пр.
youngmysteriouslight
17.04.2018 20:04У самого руки не доходят пересесть с darcs на pijul, но на канале зашло обсуждение и ряд со-разработчиков darcs высказали положительные отзывы о pijul, назвав его модель более строгой и теоретически обоснованной.
Xitsa
19.04.2018 08:22Я слежу за их блогом и мне кажется, что они живут в каком-то отдельном мире: например, в рамках разработки pijul они разрабатывают свою реализацию ssh.
awesomer
19.04.2018 09:03Полагаю они реализовали библиотеку на Rust для своих целей. Скажем, чтобы к тому же pijul-серверу подключаться чисто через клиентский бинарник, не используя внешних утилит.
А ssh-клиент — уже как почти бесплатная добавка к библиотеке, чисто ради фана.
Paskin
17.04.2018 20:43В области отображения дерева коммитов, удобства интеграции и работы со сложными проектами мне очень нравилась ClearCase от Rational/IBM. Но она не распределенная (как минимум не была когда я работал) и требует выделенного специалиста для написания сценариев рабочего пространства.
Есть ли что-то подобное открытое — позволяющее собрать версию из разных компонент со своими репозиториями?
KvanTTT
18.04.2018 01:14Все недостатки из статьи нивелируются хорошим GUI под Git, например GitExtensions. В нем можно делать даже интерактивный Rebase, не говоря уже о более простых вещах. Также он рисует наглядное и красивое представление.
После освобения, концепции гита выглядят очень логичными — сложностей практически нет, зато есть гибкость.
KvanTTT
18.04.2018 01:17Что касается самой SQLite, то порой в ней самой не хватает дифа или возможности загрузки данных в текстовом формате.
dataman
18.04.2018 11:26+1Что касается самой SQLite, то порой в ней самой не хватает дифа
Уже есть sqldiff и расширение Session, правда, с рядом ограничений.
возможности загрузки данных в текстовом формате
Есть CSV Virtual Table.
technont64
18.04.2018 18:502.4. Git требует дополнительной административной поддержки
В отличие от них, Fossil — это один отдельный бинарник, который устанавливается путём размещения в $PATH. Этот единственный бинарник содержит всю функциональность Git, а также и GitHub и/или GitLab. Он управляет сервером сообщества с вики и баг-трекером, обеспечивает пакетную загрузку для пользователей, управление авторизацией и прочее — без дополнительных программ.
Есть такие же реализации для Git, например Gitea
johnfound
19.04.2018 17:51Кстати, fossil позволяет открыть несколько рабочих директорий (checkouts) и работать одновременно в них.
Поправьте если не прав, но мне кажется, что в git для этого надо клонировать репозиторий каждый раз отдельно.
А я постоянно так работаю — для каждую открытую ветку разработки, создаю рабочую директорию, которую закрываю только после слияния с транком и закрытием ветки.
discopalevo
19.04.2018 18:46+1johnfound
19.04.2018 20:38Значит и в git можно. Но очень как то сложно все:
With git worktree add a new working tree is associated with the repository. This new working tree is called a "linked working tree" as opposed to the "main working tree" prepared by "git init" or "git clone". A repository has one main working tree (if it’s not a bare repository) and zero or more linked working trees.
Зачем так сложно? В чем разница и почему она должна быть??? В fossil все делается одинаково:
mkdir MyProjTrunk cd MyProjTrunk fossil open ~/repos/MySuperRepo.fossil trunk cd .. mkdir MyProjTest cd MyProjTest fossil open ~/repos/MySuperRepo.fossil testsplav_asv
19.04.2018 20:45Те же яйца, только в профиль. Тут само репозиторий, если я правильно понимаю, лежит в ~/repos/MySuperRepo.fossil. А в git внутри каталога главного рабочего дерева (main working tree).
mayorovp
19.04.2018 20:53А этот самый ~/repos/MySuperRepo.fossil у вас откуда взялся? Самозародился что ли?
В гите точно так же можно создать репу без рабочей копии (git clone --bare), а потом добавлять ей рабочие копии через git worktree.johnfound
19.04.2018 21:18А этот самый ~/repos/MySuperRepo.fossil у вас откуда взялся? Самозародился что ли?
Он появляется в результате клонирования или создания нового репозитория. Например:
fossil clone https://asm32.info/fossil/repo/asmbb ~/repos/MySuperRepo.fossil
Но клонирование репозитория, просто клонирует его. Рабочие директории к этому отношение не имеют. И мне кажется что это вполне естественно. Зачем учить и использовать разные опции (--bare) чтобы сделать то, что естественно?
А в git почти всегда так – самые простые вещи делаются сложно и неинтуитивно.
Кстати, заметили, что в мои примеры, нет ни одного символа "--"?
PavelVainerman
19.04.2018 21:29Т.е. по Вашему
fossil clone xxx
это нормально, а
git clone xxx
«сложно и неинтуитивно»?johnfound
19.04.2018 21:42Но
git clone xxx --bare
уже неинтуитивно. Ведь я хочу клонировать репозиторий, а не делать чекаут. Тем более на master бранч.
PavelVainerman
19.04.2018 21:56-1Если Вы хотите склонировать репозиторий то «git clone» это и делает.
Никаких --bare Вам не надо.
Не совсем понял что такое у Вас потом «fossil repo open»,
но предполагаю, что это и есть «checkout».
Вообщем мне кажется Вы «немного» преувеличили «сложность и неинтуитивность». Максимум я вижу «я так привык».johnfound
19.04.2018 22:13open не checkout.
fossil open REPO VERSIONозначает: Хочу чтобы здесь была рабочая директория проекта "REPO" и чтобы восстановилась из репозитория версия VERSION.
Потом, версию (checkin) можно менять через
fossil co VERSIONили синонимfossil update VERSION.
А VERSION может быть код версии, имя ветки, присвоенный tag и т.д.
P.S. И опять ни одной опции через '--'. :D Вообще опции в fossil очень мало и используются только чтобы сделать что-то противоестественное. Например переключить на другую версию, но не восстанавливать файлы из репозитория.
mayorovp
19.04.2018 22:19P.S. И опять ни одной опции через '--'. :D Вообще опции в fossil очень мало и используются только чтобы сделать что-то противоестественное
Иными словами, регламентирован один-единственный workflow разработки, а все остальные объявлены противоестественными :-)
johnfound
19.04.2018 22:29-1Workflow может быть каким угодно, а опции используются только когда надо ломать обычный порядок. По моему так и должно быть. А ведь git (и все другие) тоже продвигает "правильный" workflow:
Просто запомни эти команды шелла. Вводи их, когда нужно синхронизироваться. Если выскочит ошибка, сохрани где-нибудь свою работу, удали проект и скачай свежую копию.
:-D
michael_vostrikov
20.04.2018 08:26fossil open REPO VERSION означает: Хочу чтобы здесь была рабочая директория проекта "REPO" и чтобы восстановилась из репозитория версия VERSION.
Потом, версию (checkin) можно менять через fossil co VERSION или синоним fossil update VERSION.Итак, для начала работы над веткой в новом репозитории надо сделать:
# fossil fossil clone URL ~/repos/MySuperRepo.fossil mkdir MyProjTrunk cd MyProjTrunk fossil open ~/repos/MySuperRepo.fossil trunk # git git clone URL MyProjTrunk -b trunk cd MyProjTrunk
Для переключения на другую ветку:
# fossil fossil co VERSION # git git checkout VERSION
Для параллельной работы:
# fossil mkdir ../MyProjTest cd ../MyProjTest fossil open ~/repos/MySuperRepo.fossil test # git git worktree add ../MyProjTest test cd ../MyProjTest
Принципиальной разницы нет, только Fossil более многословный.
johnfound
20.04.2018 09:16-1Принципиальной разницы нет, только Fossil более многословный.
Может быть, но просто посмотрите на команды. У fossil все команды совершенно ясные и прямолинейные. Там вопросы не возникают, даже у человека незнакомого с fossil. Точно можно сказать зачем та или иная команда пишется и что она делает.
А в git это не так. Человек должен знать что есть такую команду как worktree, а откуда он может узнать если рабочая директория создается автоматически. Держу пари, что 90% git потребителей просто клонируют репозиторий каждый раз.
michael_vostrikov
20.04.2018 10:1190% git потребителей просто переключаются между ветками. Клонирование делается один раз для нового проекта.
KvanTTT
20.04.2018 10:19+1Переключаться не всегда удобно, т.к. порой желательно еще и Clean Working Directory делать и перекомпилировать. А бывает удобно заниматься разными задачами в разных ветвях, например фиксить баги в релизе и заниматься какой-нибудь фичей.
KvanTTT
20.04.2018 10:17Держу пари, что 90% git потребителей просто клонируют репозиторий каждый раз.
Каюсь, делал так. Однако заметил что в GitExtensions есть такая функция — теперь буду ее использовать.
mayorovp
19.04.2018 21:37А вы никогда не замечали что первое что вы делаете после fossil clone — это fossil open? :-)
johnfound
19.04.2018 21:47Нет, не замечал, потому что
fossil cloneя делал несколько лет назад, аfossil openделаю всегда, когда захочу открыть еще одну рабочую директорию.
Ведь fossil не git и "fresh copy" никогда не приходится делать. :D
mayorovp
19.04.2018 21:53Наверное, вы над очень маленьким числом проектов работаете...
johnfound
19.04.2018 22:01Нет, я просто работаю и поддерживаю долгосрочными проектами. Да и причем здесь число проектов?
Или карикатура все таки права и
cloneэто основная команда git?mayorovp
19.04.2018 22:14Притом, что я вот git clone делал совсем недавно просто потому что новый проект вручили...
А переключаться между ветками обычно все-таки удобнее через checkout, а не через создание новой рабочей копии.
johnfound
19.04.2018 22:36А переключаться между ветками обычно все-таки удобнее через checkout, а не через создание новой рабочей копии.
В fossil команда checkout (синонимы: checko, check, chec, che, co) тоже имеется и используется широко. Только я привык работать одновременно над нескольких задачах в рамках проекта и тогда гораздо более удобно иметь раздельные директории. Вообще я новые ветки создаю постоянно. Примерно 10 активные ветки не предел.
KvanTTT
20.04.2018 02:41На странице сравнения возможностей написано что Fossil помимо файлов поддерживает трекинг тикетов, вики, записок (видимо сниппетов). Интересно, как это сделано? На гитхабе и гитлабе можно использовать отдельные репозитории с вики, однако все же они получаются несколько оторванными друг от друга.
Было бы удобно видеть как единую историю непересекающихся репозиториев, так и историю по отдельности (фильтры). Так и историю тикетов можно было бы хранить. Т.е. это деревья, которые нелья мержить друг с другом, и которые можно отключать. Как лес с переплетенными ветвями :) Думаю что в гите такое не поддерживается.
kaljan
Когда не смог в гит и алиасы
nikialeksey
Не думаю, что разработчики SQLite не смогли в гит
Gemorroj
сложность — это не преимущество, а недостаток.
kalininmr
да не. про ветки все правильно. можно ещё и всадника без головы получить запросто.