Почему SQLite не использует Git

https://sqlite.org/whynotgit.html
  • Перевод

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 должен всегда держать в уме:

  1. Рабочий каталог.
  2. «Индекс» или область подготовки (staging area).
  3. Локальный заголовок (HEAD).
  4. Локальная копия удалённого заголовка.
  5. Реальный удалённый заголовок.

В 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 инструкция похожа).

  1. Загрузите автономный исполняемый файл Fossil с этой страницы и поместите его где-нибудь в $PATH.
  2. mkdir ~/fossils
  3. fossil clone https://sqlite.org/src ~/fossils/sqlite.fossil
  4. mkdir ~/sqlite; cd ~/sqlite
  5. fossil 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:

Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 180
  • +6
    Когда не смог в гит и алиасы
    • +12
      Не думаю, что разработчики SQLite не смогли в гит
      • +45

        сложность — это не преимущество, а недостаток.

        • 0
          да не. про ветки все правильно. можно ещё и всадника без головы получить запросто.
        • +33
          Часто наблюдал такое у embeded разработчиков — нежелание осваивать чужой инструмент.
          Такие себе крестьяне единоличники — построят свой домик, огородятся забором и даже свою систему контроля версий изобретут ;)
          PS:
          Торнвальдса это тоже касается с гитом :)
          • 0
            Gitiny нужно им свой создать.
            • +2

              Ну, соблазн большой. Довольно трудно отказаться от своего глючного велосипеда в пользу чужого глючного велосипеда

              • +2
                До гита ядро разрабатывалось с помощью BitKeeper. Там точно история не о нежелании осваивать.
              • +1
                « Вы не любите кошек? Да Вы просто не умеете их готовить! »
                Альф (ALF)
                • +2
                  • +1
                    «фатальный недостаток»
                  • +2
                    Я полностью согласен с картинкой в этой статье про использование гита. Однако я еще ни разу не попадал в нерешаемые ситуации, и не тратил много времени на гит. Наверное, в моих проектах был всегда строгий флоу
                    • +3
                      «Индекс» или область подготовки (staging area).
                      Локальный заголовок.
                      Локальная копия удалённого заголовка.
                      Реальный удалённый заголовок.

                      Вот это что я сейчас прочитал? Какой заголовок. Это о чем? о локальной копии удаленной ветки?
                      • +4

                        я тоже задумался. Это HEAD же :-)

                        • +2
                          По идее да. Но нафига программисту помнить о HEAD его ветки, если он начинает слияние. Ведь это то, что у него в каталоге.

                          Зачем ему помнить о хеде его локальной копии удаленно ветки. По идее, он может ее тронуть только в экстремальной ситуации.

                          Иными я словами, я не понимаю что у них вызывает проблемы.
                      • 0
                        Навигация как в новых версиях p4
                        • +6

                          Ожидал более обоснованной критики...


                          С 2007 юзаю системы контроля версий (git где-то с 2011), никогда не приходилось искать потомок коммита.
                          История веток видна, если делать git merge <feature-branch> --no-ff (ну ок, это, возможно фича гитхаба/битбакета/гитлаба, тем не менее это не проблема).
                          Вот дофигалиард странных суб-команд и странных опций это да, валидный аргумент. Но, как справедливо указывает Рэндолл Мунро, в повседневной работе достаточно ~5 команд, всё остальное — для исключительных случаев и продвинутых пользователей.


                          Тем не менее, fossil выглядит достаточно интересно. Но для личных проектов лень возиться с инфраструктурой и разворачивать на сервере какие-то бинарники (тем более через, прости господи, CGI), а SaaS решений c Fossil я не видел.

                          • +1
                            Вся критика сводится к: у людей была система контроля версий и был workflow, заточенный под её косяки. Теперь они смотрят на git, но не хотят ничего менять в workflow. А git не заточен под косяки чуждого workflow, что ему и ставится в вину.
                            • +7
                              Если git заточен под свои (другие) косяки, то зачем им, в sqlite, перенимать эти чужие? Если уж при их разработке преимущества git'а не используются.
                              • 0

                                Все нераспространенное имеет крупный недостаток по сравнению со всем распротранненным — оно не поддерживается сторонними разработчиками. Есть этот FOSSIL для Idea, VS code, VS, Eclipse и прочего?

                                • 0
                                  Не знаю. Никогда не пользуюсь СКВ, встроенными в IDE. Лично для меня СКВ — всегда отдельный инструмент.
                                  • 0
                                    Есть этот FOSSIL для Idea, VS code, VS, Eclipse и прочего?


                                    М?
                                    Зачем до такой степени то лениться?
                                    • +4
                                      Зачем до такой степени то лениться?

                                      Просто мне есть чем заняться кроме плясок вокруг системы контроля версий. Само по себе набирание командочек мне неинтересно. Для меня лучшая СКВ, которой нет.

                                      • 0
                                        Просто мне есть чем заняться кроме плясок вокруг системы контроля версий. Само по себе набирание командочек мне неинтересно. Для меня лучшая СКВ, которой нет.


                                        В статье расписано — почему именно они выбрали другую.
                                        Как раз потому, что с ней проще. Что она экономит время. По их мнению.

                                        • 0

                                          Так в статье рссмотренны недостатки гит, но не рассмотрены преимущества. Может они не обо всех знают. Вопрос в том, стоило ли оно для них. Разумеется любимое детище кажется им ближе

                                • +1

                                  Насколько я помню, git примерно так и появился, заточенный под косяки предыдущего воркфлоу (убей не помню, как называлась VCS которую они использовали до того).

                                • 0

                                  Насколько я помню, git примерно так и появился, заточенный под косяки предыдущего воркфлоу (убей не помню, как называлась VCS которую они использовали до того).

                                • 0
                                  а SaaS решений c Fossil я не видел.

                                  http://chiselapp.com/ ?

                                • 0
                                  Но для личных проектов лень возиться с инфраструктурой и разворачивать на сервере какие-то бинарники (тем более через, прости господи, CGI), а SaaS решений c Fossil я не видел.

                                  Я как раз для личных проектов использую fossil, так как не хочу возиться с инфраструктурой и разворачиванием чего-либо на сервере.
                                  Репозиторий в fossil — это один файл его можно хранить, например, в dropbox'е, бинарник тоже один, причём устанавливать его не нужно, достаточно при необходимости скачать.
                                  • 0

                                    Помимо "скачать", его нужно запустить, обеспечить запуск после ребута (он же в режиме демона пуши принимает, не так ли?) настроить права доступа, настроить в nginx поддомен или путь. Вот это мне всё лень:)


                                    А зачем хранить репозиторий в дропбоксе, я вот не очень понял. В качестве дополнительного бэкапа?

                                    • 0
                                      Нет :), как раз этого всего делать не надо.
                                      Скачивание репозитория — это фактически его клонирование, после этого можно с ним работать локально. Ничего ставить не надо, всё уже есть в приложении, его можно запускать без дополнительной настройки.
                                      В дропбоксе я держу клоны репозиториев, чтобы при необходимости иметь к ним доступ со стороны.
                                      • 0

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

                                        • 0
                                          Для моих личных проектов центральный сервер избыточен, и я предпочитаю более распределённую разработку.
                                          • 0

                                            Не, мне нужна веб-морда и вот это вот всё. Поэтому я и говорил про инфраструктуру.
                                            Когда-то я тоже бэкапился через дропбокс, угу.

                                • +5
                                  Часть проблем решена в Mercurial + TortoiseHg
                                  • +4
                                    Ждем пост «Почему SQLite не использует Mercurial»
                                    :))

                                    Ну а если честно, лично мне тоже больше нравиться Mercurial. Он проще, понятнее. Git слишком перегружен. Но… Git самый популярный, поэтому если ты идёшь на новый проект, то с вероятностью 95% там гит.
                                    • +3
                                      Как человек, пересевший при присоединении к крупному проекту с Mercurial на Git — могу сказать, что именно степень недружелюбности Git-а к начинающему (что консольного, что GUI) после простого, понятного и наглядного TortoiseHg стала для меня шоком. В Mercurial я «сел и поехал» во многом именно благодаря хорошему «изкоробочному» GUI, а вот вникание в Git было затруднительным. Был бы внятнее пользовательский интерфейс — переход прошёл бы гораздо легче.
                                      Мне очень помог на первых порах SmartGit — по сути, это аналог TortoiseHg, только существенно более продуманный. Идеи Tortoise получили своё развитие — например, возможность в интерактивном режиме делать этакий микро-diff, просматривая в небольшом окошке текущие изменения в проекте, отмечая для себя важные изменения, перенося или удаляя незакомиченные правки — это чудесное изобретение! Можно также смотреть, что за команда передаётся непосредственно бинарнику git при совершении того или иного действия. Да сложную Гит-магию в SmartGit сделать затруднительно, но для 90% простых задач обращаться к консоли, по сути, и не приходится.
                                      • +10

                                        Git, имхо, взлетел потому что github, а не потому что сам git такой хороший.
                                        С hg помню проблемы с юникодом были (давно правда, лет 5 назад).

                                        • +1
                                          да, тоже считаю, что hub в этих шести буквах важнее.
                                          Но нужно добавить, что ведь есть ещё svnhub.com, т.е. фактически поддержка subversion со стороны github. Т.е. была (и есть) возможность содержать свои проекты на svnhub и/или импортировать их в git. Это тоже добавило очков git'у.
                                          • 0

                                            у hg была "проблема" (надеюсь починили давно) с тем, что в нём нельзя отслеживать удалённые ветки из других репозиториев. Только репозитории целиком.
                                            Для home brew разработки это ни разу не проблема, а вот для более взрослой — уже сложнее.


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


                                            Хотя Mercurial нежно люблю за его человеко-ориентированный интерфейс :)

                                          • +2

                                            SmartGit как "существенно более продуманный" аналог TortoiseHg — очень хорошая шутка.
                                            Платный, тормозной, некостистентный, с древним дизайном, с кучей неотключаемых модальных окон — это все SmartGit, и smart в его названии — явный сарказм. Если кто подскажет gui-клиент, умеющий в split commit, то я с удовольствием выкину smartGit и забуду как страшный сон.

                                            • 0

                                              Для разделения коммита я использую стандартный git for windows.
                                              В GUI выбрать опцию amend, потом разнести изменения по нескольким коммитам.
                                              Если надо разделить не последний коммит, то добавляется пара команд из консоли.

                                              • 0
                                                Если надо разделить не последний коммит, то добавляется пара команд из консоли.

                                                Я не против консоли для редких вариантов использования, а также случаев, когда GUI недоступен.
                                                Но в рамках принятого текущим работодателем процесса разделение коммита (не последнего) — вариант типовой.

                                              • 0
                                                Если кто подскажет gui-клиент, умеющий в split commit

                                                Git Extensions. Напрямую кнопки сделать split commit там нет — но можно сделать mixed reset после чего накатить коммиты по частям, для чего есть удобное окно где можно делать Stage/Unstage отдельным строкам из диффа.

                                                • 0

                                                  Это все я делал, по объективным результатам и субъективным ощущениям — худший сорт того же самого.

                                                  • 0

                                                    А если не секрет, откуда вообще берутся коммиты которые потом приходится разбивать?

                                                    • 0
                                                      Необходимость разбиения возникает из доведенных до предела требований к атомарности коммитов: одно и только одно логическое изменение на коммит.
                                                      • –3
                                                        Не знаю… у меня все эти «атомарности» в одном месте зудят.

                                                        У Гит не существует «атомарного» древа. Оно или весь репозиторий, или ничего. И когда три разработчика работают над общим проэктом, а «common» репозиторий в любом проэкте приличного размера это больше половины веса ПО, то получается невообразимая чехарда, из — за которой проэкт приходится перекраивать под возможности хранилища текстовых исходников.
                                                • +3

                                                  SourceTree?

                                                  • 0
                                                    Не умеет в Split Commit. В его трекере эта фича уже три года, приоритет низкий, никому не назначена.
                                                  • 0
                                                    Я какое-то время использовал SourceTree параллельно с GitHub Desktop.
                                                    В гитхабовом клиенте, пожалуй, самый удобный split commit.
                                                    Но в итоге, устав от разных других недостатков обоих клиентов, перешёл на GitKraken.
                                                    Самый продуманный клиент git под Windows. Впервые после TortoiseHg не страшно за каждый шаг, и всё как на ладони.
                                                    Split commit тут вполне сносный (показывает изменения чанками, но строки тоже можно выделять).
                                                    Из недостатков — запускается долго и тот же выбор строк в стедж подтормаживает на больших файлах. Ну и free for personal use только.

                                                    В VSCode тоже теперь можно построчно стейджить изменения. Если бы не GitKraken, на данный момент предпочёл бы VScode + GitLens другим клиентам.
                                                    • +1
                                                      Если кто подскажет gui-клиент, умеющий в split commit

                                                      Ну так TortoiseGit. В диалоге интерактивного rebase, если для коммита поставить "Edit", то после запуска процесс на нем останавливается и появляется галочка "Edit/Split commit".

                                                      • 0
                                                        Клиент, умеющий в split commit — SouceTree, от Atlassian.
                                                    • +2
                                                      А я просто использую TortoiseHg для проектов на Git через hggit.
                                                      • +3
                                                        Вот почему-то у меня получилась полностью противоположная вкусовщина.

                                                        Сначала RCS (ещё в мохнатые 90-е), CVS. Попытка SVN, Arch — не зашли. Mercurial — не пошёл, всё типа понятно, но «не то» (а уж диверсии типа множественных голов...); что в итоге не так — описал 1, 2, 3, 4 и так далее. Git — после минимального освоения и разумной централизации, где нужно — устаканился идеально. (После этого, когда рассказывают, мол, SVN и Mercurial после CVS заходят идеально, а для Git надо что-то выламывать в голове — скептически ухмыляюсь.)
                                                    • +1
                                                      Да, вот уж по удобству использования меркуриал реально намного выше гита. Жаль, что гит по факту победил.
                                                      • +3

                                                        Победил не гит, а гитхаб.
                                                        А вместе с гитхабом я использую меркуриал, подключаясь с помощью расширения hg-git
                                                        К сожалению, все косяки дизайна гита так не исправить.

                                                        • +2

                                                          Кстати, про косяки дизайна гита. У меня тоже был исключительно положительный опыт с Mercurial, пока не случилось так, что пришлось пользоваться гитом. Мыши плакали, кололись, а потом почитали инструкцию и немного о том, как он внутри устроен. И косяки дизайна уже не выглядят такими уж и косяками. WAT-ов конечно хватает, но не так всё страшно на самом деле ( кроме git checkout -b разумеется :) )

                                                          • –2

                                                            Я инструкцию читал с самого начала, но ряд косяков так и остались косяками:


                                                            1. В гите нет веток, а ветками называют именованные головы.
                                                            2. В гите нельзя закрыть ветку — только удалить.
                                                            3. В гите нет перемещения и переименования файлов.
                                                            4. В гите черри-пик не знает, откуда его скопировали.
                                                            • +1
                                                              1. Сначала дайте определение ветки.
                                                              2. Что значит закрыть ветку? В гите это просто указатель на коммит.
                                                              3. Это не проблема гита. Внешние инструменты, вычислив разницу между коммитами, могут сказать, что файл был перемещен, на основании % совпадения содержимого файла
                                                              4. Гит хранит историю состояний рабочего каталога. Есть хоть одна ФС, которая хранит, откуда скопирован файл?
                                                              • +1
                                                                Что значит закрыть ветку? В гите это просто указатель на коммит.

                                                                В этом и проблема, информация о ветке теряется.
                                                                Это не проблема гита. Внешние инструменты, вычислив разницу между коммитами, могут сказать, что файл был перемещен, на основании % совпадения содержимого файла

                                                                Это проблема гита. Внешние инструменты не могут повлиять на разрешение конфликтов при мерже, к примеру.
                                                                • +4
                                                                  Сначала дайте определение ветки.

                                                                  Для систем контроля версий — подграф взаимосвязанных коммитов, которому можно дать имя. Это вполне соответствует веткам для математического дерева или даже обычного живого дерева.
                                                                  И только в гите ветка — это всего лишь именованный мутабельный указатель на коммит и не более.


                                                                  Что значит закрыть ветку? В гите это просто указатель на коммит.

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


                                                                  Это не проблема гита.

                                                                  Это проблема гита. Перемещение и переименование для всех есть, а для гита нет. Его приходится угадывать с помощью костылей с переменным успехом. Забавно смотреть, как меняется видимая история файла, в зависимости от настройки чувствительности поиска. Обычно приходится разбивать коммит с перемещениями-переименованиями на два — в одном менять содержимое файлов, в другом перемещать-переименовывать.


                                                                  Гит хранит историю состояний рабочего каталога. Есть хоть одна ФС, которая хранит, откуда скопирован файл?

                                                                  Этот вопрос нерелевантен проблеме и отсылает к ФС, которая в контроль версий не умеет от слова совсем.
                                                                  А в системе контроля версий обычно полезно знать, из какой ветки взят коммит, выполненный командой cherry pick. В гите для этого есть возможность указать в сообщении хеш оригинального коммита. Но сам гит про это ничего не знает, нигде не хранит и никак не показывает, в отличие, например, от меркуриала.

                                                                  • 0
                                                                    Мало кто использует гит в чистом виде.
                                                                    Пользуются гитхабом, битбакетом, герритом — а через них можно настроить дополнительные фичи, типа закрыть ветку.

                                                                    git mv file1 file2 — что не так?
                                                                    • +1
                                                                      можно настроить дополнительные фичи, типа закрыть ветку

                                                                      И как будет выглядеть закрытая ветка гита в моей локальной репе? И чему соответствовать в удаленной?


                                                                      git mv file1 file2 — что не так?

                                                                      Строго по документации: работает в точности как добавление файла на новом месте и удаление в старом. Никакого перемещения на уровне истории не добавляет.

                                                                      • 0
                                                                        И как будет выглядеть закрытая ветка гита в моей локальной репе? И чему соответствовать в удаленной?


                                                                        Вы не сможете ничего запушить в удаленную ветку.
                                                                        Соответствовать будет ветке с таким же именем. Собственно в чем проблема? Это активно используется.
                                                                        • 0
                                                                          Вы не сможете ничего запушить в удаленную ветку.

                                                                          Этого мало. Я не должен видеть эту ветку в списке тех, в которые пушить можно.
                                                                          И мне интересно, как это будет работать, если


                                                                          1. на сервере инструмент над гитом один,
                                                                          2. у меня локально — другой,
                                                                          3. вся связь между ними — только через гит
                                                                          4. сами инструменты друг о друге не в курсе.
                                                                          • 0
                                                                            Не совсем понимаю, почему у вас разные инструменты.
                                                                            Просто доступ к git репозиторию идет через gerrit, напрямую к git подключиться нельзя.
                                                                            Все.
                                                                            У меня есть чувство, что вы просто не пробовали.
                                                                            • 0

                                                                              а как сделать, чтобы напрямую к локальному репозиторию нельзя было подключиться?

                                                                              • 0
                                                                                Не делать локальный репозиторий, вынести его на сервер.

                                                                                Какой смысл локального репозитория, вы работаете один или в команде? Как вы синхронизируетесь?
                                                                                • +2
                                                                                  Какой смысл локального репозитория, вы работаете один или в команде?

                                                                                  • Не зависить от связи и при этом иметь возможность сохранять промежуточные состояния своей работы


                                                                                  • Это то, что поддерживают инструменты (как, например, настроить Visual Studio работать напрямую с удаленным git?)

                                                                                  Как вы синхронизируетесь?

                                                                                  git pull
                                                                                  git push

                                                                                  • –1
                                                                                    Не зависить от связи и при этом иметь возможность сохранять промежуточные состояния своей работы


                                                                                    Для этого в гите используют ветки и коммиты в локальном репозитории. Ограничивать к нему доступ — не git-way.

                                                                                    Ограничения должны накладываться при взаимодействии с другими пользователями.
                                                                • 0

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

                                                                  • +1
                                                                    Дело не в автоматике, которая, бесспорно, удобнее, а в том, может ли система контроля версий использовать эту информацию в будущем.
                                                                    • +1
                                                                      В других VCS необходимости нет точно так же: удаление и добавление файлов поддерживается везде.
                                                                      Зато есть возможность указать правильное переименование/перемещение (определив его в том числе автодетектом) и сохранить в истории.
                                                                      Гит же вынужден гадать всегда: у него в истории такой информации нет.
                                                                      • –1
                                                                        Вообще — то это файловая система тоже не хранит записи о переименовании того или иного файла. Во всех без исключения репозиториях эти детали являются частью протокола изменения имени/переноса файла, который создан человеком, и интерпретируется в свою очередь, графическим приложением-клиентом не из той или иной «команды», но из определенного набора шагов, с определенными комментариями или тегами, которые автоматически поддерживает графическое приложение.

                                                                        Что Гит не может вообще, это сделать древо из изменения имени одного файла. Ему нужно сделать древо из всего репозитория. И поэтому перед любым коммитом в группе разработчиков первое это «merge», которое может окончиться (не)известно чем. Поэтому «стандартный протокол» это

                                                                        1. создать резервную копию
                                                                        2. если повезет быстренько все что нужно закоммитить или продолжить к 3.
                                                                        3. восстанавливай резервную копию, выполняй пункт 2
                                                                • –4
                                                                  Помню давний разговор с админом «почему мы перешли на Гит». Говорит умные люди решили. Говорит: «Поиск текста в старых ревизиях медленно работает.»

                                                                  Спустя 5 лет выяснилось…

                                                                  Кстати, как — то проходил интервью в одной фирме, обслуживающей адвокатов. Они свои документы в какой — то момент в ГитХаб закачали. Вроде бы удобно. Особенно в командировках. А потом в один прекрасный день пришлось восстановить все с резервной копии. И потеряли все «папки» процесса, который был в суде. Кипишь был… Ну потом построили то, что надо, и считалочку «не бывает плохого ПО, бывают ленивые разработчики, которые не любят осваивать новые пакеты» в туалетах со стен вытерли.

                                                                  А так… вроде продукт есть. Вроде бы бесплатно… Ну и там в разных компаниях любят присылать вопрос «пришлите URL с вашим прортфолио на ГитХаб».

                                                                  Как Оби-Ван-Кенуби с лазерным мечиком. Индастрил Лит Унт Мазик. Хлоп — он есть, хлоп — его нету. Передовое общество воодушевлено иллюзией, пока одинокий интеллигентный человек не оказывается вечером на мосту, один на один с маленьким и очень фотогеничным мальчиком, предлагающим купить кирпич, или попрыгать на майдане.
                                                                  • +1
                                                                    Ну и как они умудрились их потерять в гите? Ваша история явно неполная без технических подробностей.
                                                                    • –3
                                                                      GPL перечитайте. Она начинается со слов «не несет никакой ответственности и не дает никаких гарантий».
                                                                      • –2
                                                                        И даже не в этом дело. Мы ведь здесь на хабре, отдела кадров у Вас нет. И я могу Вам сказать прямо, в чем проблема. Есть такое понятие, описываемое английским словом liability. По — русски его переводят «ответственность». В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт. От слова вообще.
                                                                        • +2
                                                                          В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт.

                                                                          GPL перечитайте. Она начинается со слов «не несет никакой ответственности и не дает никаких гарантий».


                                                                          git с ее GPL — это всего лишь программа.

                                                                          а ГитХаб — уже услуга.

                                                                          наверняка документы для судебного процесса размещались не в бесплатных открытых репах ГитХаба.
                                                                          а в оплачиваемых закрытых.

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

                                                                          уже кто кто, а адвокатская контора, о которой идет речь — уж смогла бы отсудить.

                                                                          так что что-то вы не договаривайте.

                                                                          но любая услуга по хранению должна быть обязательно дублирована в другом месте. бэкапы она не отменяет, да.
                                                                          • –6
                                                                            Я ничего не недоговариваю. Все как есть и как было. Гит не несет ответственности. Вообще ни за что. Кроме одного. Прибыль владельца. Единственная корпорация с полной ответственностью за все владения каждого человека в истории человечества была и будет СССР.

                                                                            У Вас иллюзия с лазерным мечиком, а не интеллект.
                                                                            • 0
                                                                              Кстати, как — то проходил интервью в одной фирме, обслуживающей адвокатов.

                                                                              насколько я понял в ситуации вы детально не разбирались, а просто услышали историю на интервью?

                                                                              • –4
                                                                                «История на интервью» или «дядя купи киприч».

                                                                                Бугая сзади нету, фотогеничный мальчик.
                                                                          • 0
                                                                            В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт. От слова вообще.

                                                                            Назовите мне компании, которые несут хоть какую-то ответственность. Практически везде прописан отказ от неё. Если винда угробит все файлы на ней, максимум, что вы можете получить, это возмещение её стоимости. С макос не знаю, не встречал случаев, уверен, что тоже самое. Linux тоже на GPL. По вашему, в общем, нигде нет гарантий. И так оно и есть, просто нужны бекапы. Всегда и везде. На независимые накопители, с историей, и шифрованным дубликатом в географически разделённое место, и проверкой его восстанавливаемости.
                                                                            • 0
                                                                              >Если винда угробит все файлы на ней, максимум, что вы можете получить, это возмещение её стоимости
                                                                              Вроде не стоимости, а пяти баксов максимум
                                                                              • 0
                                                                                Это указано в соглашении, в реале вроде как можно отсудить стоимость, зависит от страны.
                                                                              • 0
                                                                                С макос не знаю, не встречал случаев, уверен, что тоже самое.

                                                                                Да, то же самое: мы ни при чём и ни за что не отвечаем, пользуйтесь на свой страх и риск. В крайнем случае мы вам максимум $50 вернём.

                                                                                • –4
                                                                                  «Назовите мне...»
                                                                                  ***
                                                                                  Экий Вы п-п-п-п-простачек, от английского слова «новичок».
                                                                                  С такими п-п-п-простачками заикой стать можно. У компании Microsoft в контракте с пользователем записан «indemnification clause». Ищите перевод.

                                                                                  Господи, что делать с дилетантами. Они же все и всех убьют и скажут, что действовали во благо человечества. Чем они успешно и занимаются по всему миру.
                                                                                  • –1
                                                                                    Проблема в том, что заигрывая с санкциями США пытаются аннулировать материальную ответственность Microsoft в контрактных обязательствах, за которые фирма получила от России колоссальные деньги в твердой валюте. По сей причине России надо немедленно бежать от продуктов и Microsoft и Open Source. Поскольку не сегодняшний день заключенные ( и очень дорого оплаченные ) контракты не стоят бумаги на которой написаны.
                                                                          • +1
                                                                            Они свои документы в какой — то момент в ГитХаб закачали. Вроде бы удобно. Особенно в командировках. А потом в один прекрасный день пришлось восстановить все с резервной копии. И потеряли все «папки» процесса, который был в суде.

                                                                            Git — распределённая система. Неужели ни у кого не было рабочей копии? И причём тут гит? С таким же успехом Bitbucket мог бы откатить реп на меркуриале, а условный FossilHub откатил реп фоссила.

                                                                            • +2

                                                                              Если кто-то сумел утерять документы, хранимые в git'е (в то время как миллионы разработчиков его успешно используют), это не значит, что git плохой. Это скорее всего означает, что у кого-то руки кривые и растут не из плеч.


                                                                              Схема, когда кто-то несёт ответственность, по-своему хороша. Но в мире ПО вы не часто её встретите. Бэкапы никто не отменял.


                                                                              И вообще-то, git хранит полную историю изменений (все версии всех файлов) у каждого пользователя, кто клонировал и обновлял репозиторий. Это значит, что у вас обычно есть как минимум десяток бэкапов, даже если их не делать. Если контора не использовала стандартный, описанный в инструкции, процесс работы с git; или же после сбоя не смогла найти у себя файлы, это говорит о невысоком уровне компьютерной грамотности у её пользователей.

                                                                              • 0
                                                                                Скорее всего github использовался без локального клонирования вообще. Исключительно через веб-интерфейс (как оказалось — так тоже можно какой-то степени жить, интерфейс довольно много всего позволяет делать). Однажды такое видел — минут десять в себя приходил…
                                                                                • 0
                                                                                  Но через веб-интерфейс нельзя сделать никаких разрушительных изменений, вроде git push -f, так что все равно не понятно…
                                                                                • 0
                                                                                  Не знаю, как сейчас, но по крайней мере года 2 назад потерять коммит в гит можно было довольно просто:
                                                                                  1) Создать репозиторий
                                                                                  2) Подключить репозиторий как субмодуль к другому репозиторию
                                                                                  3) Зайти в этот субмодуль и внести изменения
                                                                                  4) Закоммитить
                                                                                  5) Где коммит???

                                                                                  Вроде такая была схема, но точно не помню.
                                                                                  Понятно, что скорее всего коммит где-нибудь сохранился, но искать его — это то еще удовольствие
                                                                                  • 0
                                                                                    5) Где коммит???

                                                                                    Там, куда его закоммитили в п.4 ?


                                                                                    В git есть много способов потерять данные, делая что-либо неправильно. Но базового понимания работы git и знания (и соблюдения) типичных последовательностей действий (типа commit-pull-push) достаточно, чтобы неправильно не делать. И тогда вы вряд ли что-либо потеряете.


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

                                                                                    • 0
                                                                                      А куда я его закоммитил? Я его закоммитил в субмодуль. Там он и должен быть.
                                                                                      Фишка в том, что если коммитить в обычный репозиторий, то гит даст закоммитить в reference HEAD, или как он там называется (то бишь, последний коммит в ветке). Но если переключиться git checkout-ом в определенный коммит, то гит закоммитить уже не даст. Но для субмодулей эта проверка почему-то не работает (по крайней мере, так было некоторое время назад), и если субмодуль смотрит не на последний коммит, а на какой-то промежуточный (что довольно часто при обновлении субмодулей и репозиториев), то есть возможность потерять коммит

                                                                                      Я уже в точности не помню всю последовательность действий, может я где-то и наврал, но сам я так несколько раз терял коммиты
                                                                                      • +1
                                                                                        Но ссылка на этот коммит остается во внешнем репозитории, и изменения все еще доступны из него…

                                                                                        PS лично я бы просто организационно запретил коммиты в сабмодули. Просто потому что разделяемый код не должен зависеть от тех проектов где он используется. Иначе получится как с нашим внутренним форком одной библиотеки, где большая часть коммитов — это добавления рандомных конфигураций в файлы проектов.
                                                                                        • 0

                                                                                          Ну да — есть такая "особенность": submodule update делает checkout ревизии, а не ветки. Поэтому перед коммитом в сабмодуль нужно переключаться в нём на ветку. Дико неудобно, но, если использовать gui-клиент, ошибки допустить сложнее.

                                                                          • +4
                                                                            Блин карикатура точно соответствует реальности, у меня оно так и получается. :-(
                                                                            • 0
                                                                              Лучше бы написали, почему Git не использует SQLite
                                                                              • 0

                                                                                Так и знал, что на самом деле SQLite не использует git, потому что git не использует SQLite. Fossil — использует.


                                                                                Но если копнуть глубже, то окажется, что реализации файловых систем (ext4, btrfs, xfs) используют git.
                                                                                Забавно.

                                                                              • 0
                                                                                Народ, а кто-то реально уже использует пихуль (pijul)?

                                                                                Автор так расписывают, так расписывают.

                                                                                Мол, основан на крутейших концепциях из хаскелевского darcs, но написан на быстром и безопасном Rust и пр. и пр.
                                                                                • +2

                                                                                  Похоже, Ваш коммент вызвал хабраэффект на сайте pijul :)

                                                                                  • 0

                                                                                    А даже и линка то не было. А вот, сайты SQLite и Fossil не упали. Это многое говорит насчет быстродействие Fossil.

                                                                                  • У самого руки не доходят пересесть с darcs на pijul, но на канале зашло обсуждение и ряд со-разработчиков darcs высказали положительные отзывы о pijul, назвав его модель более строгой и теоретически обоснованной.
                                                                                    • 0
                                                                                      Я слежу за их блогом и мне кажется, что они живут в каком-то отдельном мире: например, в рамках разработки pijul они разрабатывают свою реализацию ssh.
                                                                                      • +2
                                                                                        Полагаю они реализовали библиотеку на Rust для своих целей. Скажем, чтобы к тому же pijul-серверу подключаться чисто через клиентский бинарник, не используя внешних утилит.

                                                                                        А ssh-клиент — уже как почти бесплатная добавка к библиотеке, чисто ради фана.
                                                                                    • 0
                                                                                      В области отображения дерева коммитов, удобства интеграции и работы со сложными проектами мне очень нравилась ClearCase от Rational/IBM. Но она не распределенная (как минимум не была когда я работал) и требует выделенного специалиста для написания сценариев рабочего пространства.
                                                                                      Есть ли что-то подобное открытое — позволяющее собрать версию из разных компонент со своими репозиториями?
                                                                                      • +1
                                                                                        Все недостатки из статьи нивелируются хорошим GUI под Git, например GitExtensions. В нем можно делать даже интерактивный Rebase, не говоря уже о более простых вещах. Также он рисует наглядное и красивое представление.

                                                                                        После освобения, концепции гита выглядят очень логичными — сложностей практически нет, зато есть гибкость.
                                                                                        • 0
                                                                                          Статья вообще выглядит так, будто Fossil можно было бы реализовать как удобное расширение поверх гита.
                                                                                          • –1
                                                                                            Низя. У них все хорошо, пока смотрят на картинку графа дистрибуции. Кошмар начинается, когда заглядывают под капот. Монолитный протокол…
                                                                                            • 0
                                                                                              В головах разработчиков такая мысль есть, см. Fossil-NG.
                                                                                          • 0
                                                                                            Что касается самой SQLite, то порой в ней самой не хватает дифа или возможности загрузки данных в текстовом формате.
                                                                                            • +1
                                                                                              Что касается самой SQLite, то порой в ней самой не хватает дифа

                                                                                              Уже есть sqldiff и расширение Session, правда, с рядом ограничений.

                                                                                              возможности загрузки данных в текстовом формате

                                                                                              Есть CSV Virtual Table.
                                                                                            • 0

                                                                                              Обожаю Fossil, но это как Style Guide: везде используют Git, который стал стандартом де-факто.
                                                                                              Учите Git.

                                                                                            • 0

                                                                                              А как же Veracity?

                                                                                            • 0
                                                                                              2.4. Git требует дополнительной административной поддержки

                                                                                              В отличие от них, Fossil — это один отдельный бинарник, который устанавливается путём размещения в $PATH. Этот единственный бинарник содержит всю функциональность Git, а также и GitHub и/или GitLab. Он управляет сервером сообщества с вики и баг-трекером, обеспечивает пакетную загрузку для пользователей, управление авторизацией и прочее — без дополнительных программ.

                                                                                              Есть такие же реализации для Git, например Gitea
                                                                                              • 0

                                                                                                Кстати, fossil позволяет открыть несколько рабочих директорий (checkouts) и работать одновременно в них.


                                                                                                Поправьте если не прав, но мне кажется, что в git для этого надо клонировать репозиторий каждый раз отдельно.


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

                                                                                                  • 0

                                                                                                    Значит и в 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 test
                                                                                                    • 0
                                                                                                      Те же яйца, только в профиль. Тут само репозиторий, если я правильно понимаю, лежит в ~/repos/MySuperRepo.fossil. А в git внутри каталога главного рабочего дерева (main working tree).
                                                                                                      • 0
                                                                                                        А этот самый ~/repos/MySuperRepo.fossil у вас откуда взялся? Самозародился что ли?

                                                                                                        В гите точно так же можно создать репу без рабочей копии (git clone --bare), а потом добавлять ей рабочие копии через git worktree.
                                                                                                        • –1
                                                                                                          А этот самый ~/repos/MySuperRepo.fossil у вас откуда взялся? Самозародился что ли?

                                                                                                          Он появляется в результате клонирования или создания нового репозитория. Например:


                                                                                                          fossil clone https://asm32.info/fossil/repo/asmbb ~/repos/MySuperRepo.fossil

                                                                                                          Но клонирование репозитория, просто клонирует его. Рабочие директории к этому отношение не имеют. И мне кажется что это вполне естественно. Зачем учить и использовать разные опции (--bare) чтобы сделать то, что естественно?


                                                                                                          А в git почти всегда так – самые простые вещи делаются сложно и неинтуитивно.


                                                                                                          Кстати, заметили, что в мои примеры, нет ни одного символа "--"?

                                                                                                          • 0
                                                                                                            Т.е. по Вашему
                                                                                                            fossil clone xxx

                                                                                                            это нормально, а
                                                                                                            git clone xxx

                                                                                                            «сложно и неинтуитивно»?
                                                                                                            • –1

                                                                                                              Но


                                                                                                              git clone xxx --bare

                                                                                                              уже неинтуитивно. Ведь я хочу клонировать репозиторий, а не делать чекаут. Тем более на master бранч.

                                                                                                              • 0
                                                                                                                Если Вы хотите склонировать репозиторий то «git clone» это и делает.
                                                                                                                Никаких --bare Вам не надо.
                                                                                                                Не совсем понял что такое у Вас потом «fossil repo open»,
                                                                                                                но предполагаю, что это и есть «checkout».
                                                                                                                Вообщем мне кажется Вы «немного» преувеличили «сложность и неинтуитивность». Максимум я вижу «я так привык».
                                                                                                                • –1

                                                                                                                  open не checkout. fossil open REPO VERSION означает: Хочу чтобы здесь была рабочая директория проекта "REPO" и чтобы восстановилась из репозитория версия VERSION.


                                                                                                                  Потом, версию (checkin) можно менять через fossil co VERSION или синоним fossil update VERSION.


                                                                                                                  А VERSION может быть код версии, имя ветки, присвоенный tag и т.д.


                                                                                                                  P.S. И опять ни одной опции через '--'. :D Вообще опции в fossil очень мало и используются только чтобы сделать что-то противоестественное. Например переключить на другую версию, но не восстанавливать файлы из репозитория.

                                                                                                                  • 0
                                                                                                                    P.S. И опять ни одной опции через '--'. :D Вообще опции в fossil очень мало и используются только чтобы сделать что-то противоестественное

                                                                                                                    Иными словами, регламентирован один-единственный workflow разработки, а все остальные объявлены противоестественными :-)

                                                                                                                    • –2

                                                                                                                      Workflow может быть каким угодно, а опции используются только когда надо ломать обычный порядок. По моему так и должно быть. А ведь git (и все другие) тоже продвигает "правильный" workflow:


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

                                                                                                                      :-D

                                                                                                                    • 0
                                                                                                                      fossil 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 более многословный.

                                                                                                                      • –2
                                                                                                                        Принципиальной разницы нет, только Fossil более многословный.

                                                                                                                        Может быть, но просто посмотрите на команды. У fossil все команды совершенно ясные и прямолинейные. Там вопросы не возникают, даже у человека незнакомого с fossil. Точно можно сказать зачем та или иная команда пишется и что она делает.


                                                                                                                        А в git это не так. Человек должен знать что есть такую команду как worktree, а откуда он может узнать если рабочая директория создается автоматически. Держу пари, что 90% git потребителей просто клонируют репозиторий каждый раз.

                                                                                                                        • 0
                                                                                                                          90% git потребителей просто переключаются между ветками. Клонирование делается один раз для нового проекта.
                                                                                                                          • +1

                                                                                                                            Переключаться не всегда удобно, т.к. порой желательно еще и Clean Working Directory делать и перекомпилировать. А бывает удобно заниматься разными задачами в разных ветвях, например фиксить баги в релизе и заниматься какой-нибудь фичей.

                                                                                                                          • 0
                                                                                                                            Держу пари, что 90% git потребителей просто клонируют репозиторий каждый раз.

                                                                                                                            Каюсь, делал так. Однако заметил что в GitExtensions есть такая функция — теперь буду ее использовать.