Pull to refresh

Comments 192

UFO just landed and posted this here
Не думаю, что разработчики SQLite не смогли в гит

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

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

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

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

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

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

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

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

Иными я словами, я не понимаю что у них вызывает проблемы.

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


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


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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

А как ты к этому репозиторию получишь доступ извне?
Всё равно надо организовывать либо доступ, либо свой хостинг, либо использовать сторонние ресурсы.
UFO just landed and posted this here
Принципиальной разницы нет, разница в удобстве: fossil — это как швейцарский нож, он не заменяет инструменты по отдельности, но всегда под рукой.
Например, в ситуации, когда интернета/связности нет вообще, рабочее место не твой и выделено ненадолго, а хочется иметь привычную среду разработки, лучше всего подходит fossil.
Но это по моему опыту, your mileage may vary.
Ну так привычная это не означает лучшая.

Тем не менее, не вижу почему нельзя гит использовать в отсутствие интернета.
Я никогда не утверждал, что гит нельзя использовать. Просто гит делает хорошо только одно — управление версиями. Всё остальное делают другие инструменты.

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

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

Ближайшим аналогом того, что я хотел показать, это ситуация/спор про редакторы и IDE.
А как доступ извне получают в фоссиле, если без сервера? Все равно надо организовывать либо свой хостинг, либо доступ, либо сторонние ресурсы.

Я ж к тому, что автор статьи в этом пункте лукавит (как и во многих других)
Это было замечание к тому, что достаточно команды git init.
Этой команды недостаточно.
Это было замечание к хранению репозитория fossil в дропбоксе. Хранить его в дропбоксе недостаточно.
Ждем пост «Почему SQLite не использует Mercurial»
:))

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

Ну, если через интерактивный rebase допустимо, то Git Extensions тоже так умеют.
Клиент, умеющий в split commit — SouceTree, от Atlassian.
UFO just landed and posted this here
Вот почему-то у меня получилась полностью противоположная вкусовщина.

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

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

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

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


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

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


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

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


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

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


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

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

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

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

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


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

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

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


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

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


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

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

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

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

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


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

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

git pull
git push

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


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

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

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

UFO just landed and posted this here
В других VCS необходимости нет точно так же: удаление и добавление файлов поддерживается везде.
Зато есть возможность указать правильное переименование/перемещение (определив его в том числе автодетектом) и сохранить в истории.
Гит же вынужден гадать всегда: у него в истории такой информации нет.
Вообще — то это файловая система тоже не хранит записи о переименовании того или иного файла. Во всех без исключения репозиториях эти детали являются частью протокола изменения имени/переноса файла, который создан человеком, и интерпретируется в свою очередь, графическим приложением-клиентом не из той или иной «команды», но из определенного набора шагов, с определенными комментариями или тегами, которые автоматически поддерживает графическое приложение.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Бугая сзади нету, фотогеничный мальчик.
UFO just landed and posted this here
>Если винда угробит все файлы на ней, максимум, что вы можете получить, это возмещение её стоимости
Вроде не стоимости, а пяти баксов максимум
UFO just landed and posted this here
UFO just landed and posted this here
«Назовите мне...»
***
Экий Вы п-п-п-п-простачек, от английского слова «новичок».
С такими п-п-п-простачками заикой стать можно. У компании Microsoft в контракте с пользователем записан «indemnification clause». Ищите перевод.

Господи, что делать с дилетантами. Они же все и всех убьют и скажут, что действовали во благо человечества. Чем они успешно и занимаются по всему миру.
Проблема в том, что заигрывая с санкциями США пытаются аннулировать материальную ответственность Microsoft в контрактных обязательствах, за которые фирма получила от России колоссальные деньги в твердой валюте. По сей причине России надо немедленно бежать от продуктов и Microsoft и Open Source. Поскольку не сегодняшний день заключенные ( и очень дорого оплаченные ) контракты не стоят бумаги на которой написаны.
UFO just landed and posted this here

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


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


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

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

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

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


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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Есть CSV Virtual Table.

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

UFO just landed and posted this here
2.4. Git требует дополнительной административной поддержки

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

Есть такие же реализации для Git, например Gitea
Кстати да, но вестимо Gogs/Gitea слишком молоды и они не вписывались бы в контекст данной статьи
А я вообще не согласен, что гит требует дополнительной административной поддержки.
Не хочешь ставить сервер — не ставь, используй git локально.

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

Тоже самое касается staging area — не понимаю, зачем нужно держать это в голове. Не хочешь — не используй ни stash ни временные коммиты перед пушем.

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


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


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

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

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

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


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

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


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


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

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

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

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

Но


git clone xxx --bare

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

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

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


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


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


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

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

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

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


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

:-D

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

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

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


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

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

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

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

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

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

Держу пари, что 90% от этого и не страдают. Вы уверены, что это прям вот недостаток, если этим никто не заморачивается?

Безусловно, недостаток. Лишний расход памяти и машинного времени всегда недостаток и большой.


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

Опять двадцать пять. Ну с какого перепугу костыль-то?

А как же? Чем различаются головная рабочая директория и эти вторичные? А ничем не отличаются. А почему, однa появляется как бы сама по себе, а другие надо через тайную команду "worktree"? А потому что костыль из за обратной совместимости.

Отличается тем, что содержит в себе то, что лежит в *.fossil файле. Исторически в git принято держать рабочую директорию и данные в одном каталоге. В fossil нет.
Но в git можно сделать подобное с помощью bare репозитория + worktree, а вот в fossil сделать как в git видимо нельзя.

fossil возможно более интуитивен, но это не делает реализацию worktree git костылём. Просто другое поведение по умолчанию.
Исторически в git принято держать рабочую директорию и данные в одном каталоге.

Плохое решение, которое пришлось исправлять через лишние конструкции. Изначально симметричная ситуация (все рабочие директории равноправные), пришлось делать несимметричной – главная и дополнительные.

Вообще-то она изначально была несимметричной. Потому что репозиторий один. Один репозиторий — один каталог, внутри репозитория ветки, всё логично.
А вот у вас команда open лишняя, в первом примере это видно. И вообще лишние конструкции надо писать постоянно. Ну а что, раз worktree это костыль потому что в Fossil она не нужна, значит и open тоже костыль, потому что в Git он не нужен.

Я вам больше скажу. Вам нужна куча рабочих директорий потому что в Fossil нет rebase и даже amend commit. Там нельзя исправить опечатку, добавить пропущенный файл, просто сохранить промежуточные результаты чтобы можно было на них откатиться или проверить где что менял. Любой коммит остается в истории, и удалить его непросто. Поэтому и нужны разные рабочие директории, просто чтобы не коммитить. Система контроля версий, которая ограничивает контроль версий.
Ну а что, раз worktree это костыль потому что в Fossil она не нужна, значит и open тоже костыль, потому что в Git он не нужен.

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

Интересно как в этой логике вы работу с файлами представляете, там hardlink тоже «тайной командой» делается. А надо было бы, видимо, сначала создать файл и получить object id, а потом его в директориях прописывать отдельной командой?

Пример неудачный. Жесткая ссылка (имя файла) обязательный атрибут файла.


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

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

Жесткая ссылка (имя файла) обязательный атрибут файла

Это только в текущей (кривой) реализации. Когда сделаем fossil OS и fossil FS это не сложно изменить

Конечно. Файловая система всего лишь БД. В SQL БД например файловые имена вообще нет.


Но какое отношение это имеет к git?


Если идеология git строилась как супер-аналогия файловой системы, где репозиторий это файл, а рабочая директория, это имя файла, то как я и говорил, это ошибочная аналогия. И эсли репозиторий можно считать за файла, у которого еще одно измерение – время, то рабочая директория совершенно не является имя этого файла. Она является просто срез, образец файла в некотором моменте времени. То есть рабочая директория то же самое что и репозиторий, только у нее на одно измерение меньше. Ничего не мешает иметь несколько срезов одновременно и все они будут совершенно равноправными. Что и следовало показать.

> Но какое отношение это имеет к git?

Никакого.

> Ничего не мешает иметь несколько срезов одновременно и все они будут совершенно равноправными. Что и следовало показать.

Ничего не мешает файлу иметь несколько hardlink'ов одновременно и все они будут совершенно равноправными. Что и следовало показать?
Ничего не мешает файлу иметь несколько hardlink'ов одновременно и все они будут совершенно равноправными.

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

> хард линки не являются аналогией рабочих директориях

Так я этого и не утверждал, с чем вы с таким упорством спорите?

> Ну и что?

Так это мой вопрос. Или «это следовало показать», или «это не следовало показать».

Ну или «it depends», но тогда и ваш вывод «Что и следовало показать» предыдущими сентенциями не аргументирован.
Так я этого и не утверждал, с чем вы с таким упорством спорите?

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

> А если не утверждаете, то зачем использовать эти аналогии к git и вообще к системах управления версиями.

А я и аналогии не использую. Я вопрос задал, а после ответа я сформулирую что я утверждаю про аналогии.

> Именно это я пытаюсь объяснить.

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

Надо примерно так: Там-то «это следовало показать» потому, что 1) 2) и 3), а тут не следовало потому, что 1) 2) и 3)

(И желательно, что бы пункты не совпадали.)
И в чем разница принципиальная разница, хранить один файл с репозиторием или хранить одну директорию с репозиторием?

Я говорил что репозиторий аналог файла, лишь для упрощения. Конечно, все существующие системы управляют группы файлов, но это не меняет суть что в репозиторий отличается от checkout-а лишь наличием времени как измерение. А checkout, он имеет та же сущность как и репозиторий, только на измерение меньше. И поэтому все чекауты, равноправные и работа с них должна быть одинаковой, через одни и те же команды и опции. Это всегда увеличивает интуитивность интерфейса и соответствует правилу наименьшего удивления

Ну так в git они и равноправные, переключаются командой git checkout. Можно переключиться хоть на master, хоть на develop, хоть на конкретный коммит, с помощью одной и той же команды. Зачем тут 2 разных директории?
> если назначение элемента или сочетания неясно, то его поведение должно быть наиболее ожидаемым со стороны пользователя.

> If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.

ох…

Давайте вы сначала аргументируете necessary ли worktree, если без него 10 лет жили

> In more practical terms, the principle aims to leverage the pre-existing knowledge of users to minimize the learning curve

Потом можно обсудить место worktree на learning curve, и не стоит ли его вообще выкинуть за несоответствие Правилу.
> Лишний расход памяти и машинного времени всегда недостаток и большой.

Лишний расход времени разработчика — это недостаток и большой.

А память — у меня давно SSD на пару порядков больше любой (нужной мне) репы, так что мне без разницы нулями там забито или второй репой.

Кому надо — worktree есть, обсуждать недостатки старых версий я не вижу смысла.
А вы никогда не замечали что первое что вы делаете после fossil clone — это fossil open? :-)

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


Ведь fossil не git и "fresh copy" никогда не приходится делать. :D

Наверное, вы над очень маленьким числом проектов работаете...

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


Или карикатура все таки права и clone это основная команда git?

Притом, что я вот git clone делал совсем недавно просто потому что новый проект вручили...


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

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

В fossil команда checkout (синонимы: checko, check, chec, che, co) тоже имеется и используется широко. Только я привык работать одновременно над нескольких задачах в рамках проекта и тогда гораздо более удобно иметь раздельные директории. Вообще я новые ветки создаю постоянно. Примерно 10 активные ветки не предел.

git clone тоже обычно делается один раз для проекта.

Это когда у репозитория один пользователь на проэкте.

Вообще, если взглянуть на Git как на классическую утилиту, то её главный выигрыш это замечательный алгоритм распознавания изменений. То есть если забыть о проэктах и вернуться к рациональному и непредвзятому мышлению удивляющегося и любопытного ребёнка, то Git это идеальное устройство, чтобы сделать копию какого ни — будь гигантского проэкта, потом наложить на его корневую директорию Git repository, после чего опять же скопировать поверх этого самого проэкта тот же самый проэкт, но, допустим, от другого автора. В тот момент, когда последний файл закончит копирование, Git будет готов ответить на запрос, «есть ли разница». Изощренный пользователь может создать ветвление и построить pull request, для наглядности.

На странице сравнения возможностей написано что Fossil помимо файлов поддерживает трекинг тикетов, вики, записок (видимо сниппетов). Интересно, как это сделано? На гитхабе и гитлабе можно использовать отдельные репозитории с вики, однако все же они получаются несколько оторванными друг от друга.


Было бы удобно видеть как единую историю непересекающихся репозиториев, так и историю по отдельности (фильтры). Так и историю тикетов можно было бы хранить. Т.е. это деревья, которые нелья мержить друг с другом, и которые можно отключать. Как лес с переплетенными ветвями :) Думаю что в гите такое не поддерживается.

Про ветки-сироты я знаю. Но можно ли их скрывать из истории?
Внутри самого репозитория — нет (разве что удалить). Еще не понятно зачем, ведь как раз для истории и пользуются =)
А для просмотра есть GUI, где можно фильтровать:
https://git-extensions-documentation.readthedocs.io/en/latest/browse_repository.html#search-or-filter-the-commit-history
Сравним отображение одной исторической ветки SQLite в GitHub и в Fossil.

Хотелось бы таки увидеть линк на GitHub, чтобы сравнить — приведен только на Fossil.

И не сказано одной из важнейших вещей — того, что в Fossil коммиты хранятся надежно, в соответствии с ACID. В то время как в Git-группе в Telegram я наблюдал жалобы человека, у которого то ли пропало питание во время git push, после чего его репозиторий, а не на сервере, стал поврежден! Да-да, делался именно push.

Еще лишь вскользь затронуто то, что Fossil self-contained — не требуется сервис, wiki/tickets хранятся прямо тут же в репозитории, синхронизируясь между разработчиками, и бинарник Fossil обеспечивает web-интерфейс браузеру на локальной машине.

По-идее, атомарность может (и должна в данном случае) обеспечиваться просто на файлах, без СУБД. Интересно, это git её не обеспечивает или в вашем случае (единичном, я так понимаю) имел место какой-то аппаратный сбой (или что-то подобное), при котором бы даже ACID-СУБД не справилась?

Это гит — был прецедент порчи локальной репы при блекауте во время пуша
ACID может обеспечиваться и без СУБД, но нужно обеспечивать. В ACID системах есть механизмы восстановления после креша. Git этим не заморачивается вообще. Буквально — если убить процесс СУБД, то после перезапуска она будет работать, а не прикидываться ветошью. Если убить процесс git, то следующая операция может тупо не пройти, потому что он не может восстановиться от промежуточного состояния. Никаких повреждений данных не нужно — нужно только прервать процесс в нужный момент.
Sign up to leave a comment.

Articles