Зато есть Draw. А насчет docx, ведь MSOffice так же плохо поддерживают ODF; А он кстати стандартизован и по ISO/IEC и по ГОСТ. А UI, это вопрос привычки, нарабатывается легко.
И какая же нейтральная территория для ПО останется после этого? Хостить гит самому?
А почему бы и нет? Это не так трудно и не так дорого как принято считать.
Я делаю именно это, правда, на fossil, там селф хостинг несколько легче. Но и с гитлаб например, должно быть не труднее.
А социальные функции GitHub можно сделать через федерализации сайтов, как делают в Mastodon.
Получится не хуже чем в GitHub и без паука в середине паутины.
Так я этого и не утверждал, с чем вы с таким упорством спорите?
А если не утверждаете, то зачем использовать эти аналогии к git и вообще к системах управления версиями. Как сделано в файловых системах и правильно или нет, не имеет никакое отношение к вопросу как правильно делать в системах управления версиями. Именно это я пытаюсь объяснить.
Ну а что, раз worktree это костыль потому что в Fossil она не нужна, значит и open тоже костыль, потому что в Git он не нужен.
Ну да, open определено костыль. Я даже и не знаю почему его ввели. К тому же, есть комманда close, но она практически используется только когда хочешь удалить рабочую директорию и только чтобы проверить нет ли не записанные изменения. А так, директорию можно просто удалить и с репозитория ничего не будет.
Я говорил что репозиторий аналог файла, лишь для упрощения. Конечно, все существующие системы управляют группы файлов, но это не меняет суть что в репозиторий отличается от checkout-а лишь наличием времени как измерение. А checkout, он имеет та же сущность как и репозиторий, только на измерение меньше. И поэтому все чекауты, равноправные и работа с них должна быть одинаковой, через одни и те же команды и опции. Это всегда увеличивает интуитивность интерфейса и соответствует правилу наименьшего удивления
Ничего не мешает файлу иметь несколько hardlink'ов одновременно и все они будут совершенно равноправными.
Ну и что? Как я уже говорил, хард линки не являются аналогией рабочих директориях и поэтому как это у них сделано и правильно ли оно или нет, совершенно ортогонально к обсуждаемым вопросом.
Конечно. Файловая система всего лишь БД. В SQL БД например файловые имена вообще нет.
Но какое отношение это имеет к git?
Если идеология git строилась как супер-аналогия файловой системы, где репозиторий это файл, а рабочая директория, это имя файла, то как я и говорил, это ошибочная аналогия. И эсли репозиторий можно считать за файла, у которого еще одно измерение – время, то рабочая директория совершенно не является имя этого файла. Она является просто срез, образец файла в некотором моменте времени. То есть рабочая директория то же самое что и репозиторий, только у нее на одно измерение меньше. Ничего не мешает иметь несколько срезов одновременно и все они будут совершенно равноправными. Что и следовало показать.
Пример неудачный. Жесткая ссылка (имя файла) обязательный атрибут файла.
Файлы с нулевым количеством ссылок перестают существовать для системы и, со временем, будут перезаписаны физически.
А вот, репозиторий с нулевым количеством рабочих директории вполне возможен и у меня встречается сплошь и рядом, например временно приостановленные проекты или мастер репозитории на сервере.
Исторически в git принято держать рабочую директорию и данные в одном каталоге.
Плохое решение, которое пришлось исправлять через лишние конструкции. Изначально симметричная ситуация (все рабочие директории равноправные), пришлось делать несимметричной – главная и дополнительные.
Так, это MS не поддерживает стандарты. И за это мы должны платить?
А кстати, это MSOffice замена для LibreOffice, а не наоборот.
Зато есть Draw. А насчет docx, ведь MSOffice так же плохо поддерживают ODF; А он кстати стандартизован и по ISO/IEC и по ГОСТ. А UI, это вопрос привычки, нарабатывается легко.
Это просто лейбл. Джинсы нонейм делают ту же работу как и "Levi Strauss & Co." а иногда и лучше.
Так что, MS Office в Linux есть. Называется LibreOffice.
Если "нет" возможно, хотя и маловероятно, то "не предвидится"… Давайте угадаю: дефрагментатор диска, что ли? Или оптимизатор реестра? :D
Я делаю именно это, правда, на fossil, там селф хостинг несколько легче. Но и с гитлаб например, должно быть не труднее.
А социальные функции GitHub можно сделать через федерализации сайтов, как делают в Mastodon.
Получится не хуже чем в GitHub и без паука в середине паутины.
не нравится = уменьшает прибыль
Так лучше?
А чего им станется? Правда slashdot так медленно работает, что иногда нельзя угадать жив все еще или уже нет.
Вот именно! И это им не нравится совершенно. И будут делать все, чтобы их не заставляли. М$ всегда работала так и никак иначе.
Это они так говорят?
Embrace, extend, and extinguish
Это конечно так, только инструменты тоже надо быть безопасными. Если наступы на лопате не отогнуты, учи не учи, а ботинки все равно порвешь.
А класика
(#ffffff и/или #ffff00) на #000080это светлая или темная?А если не утверждаете, то зачем использовать эти аналогии к git и вообще к системах управления версиями. Как сделано в файловых системах и правильно или нет, не имеет никакое отношение к вопросу как правильно делать в системах управления версиями. Именно это я пытаюсь объяснить.
Ну да, open определено костыль. Я даже и не знаю почему его ввели. К тому же, есть комманда close, но она практически используется только когда хочешь удалить рабочую директорию и только чтобы проверить нет ли не записанные изменения. А так, директорию можно просто удалить и с репозитория ничего не будет.
Я говорил что репозиторий аналог файла, лишь для упрощения. Конечно, все существующие системы управляют группы файлов, но это не меняет суть что в репозиторий отличается от checkout-а лишь наличием времени как измерение. А checkout, он имеет та же сущность как и репозиторий, только на измерение меньше. И поэтому все чекауты, равноправные и работа с них должна быть одинаковой, через одни и те же команды и опции. Это всегда увеличивает интуитивность интерфейса и соответствует правилу наименьшего удивления
Ну и что? Как я уже говорил, хард линки не являются аналогией рабочих директориях и поэтому как это у них сделано и правильно ли оно или нет, совершенно ортогонально к обсуждаемым вопросом.
Конечно. Файловая система всего лишь БД. В SQL БД например файловые имена вообще нет.
Но какое отношение это имеет к git?
Если идеология git строилась как супер-аналогия файловой системы, где репозиторий это файл, а рабочая директория, это имя файла, то как я и говорил, это ошибочная аналогия. И эсли репозиторий можно считать за файла, у которого еще одно измерение – время, то рабочая директория совершенно не является имя этого файла. Она является просто срез, образец файла в некотором моменте времени. То есть рабочая директория то же самое что и репозиторий, только у нее на одно измерение меньше. Ничего не мешает иметь несколько срезов одновременно и все они будут совершенно равноправными. Что и следовало показать.
Пример неудачный. Жесткая ссылка (имя файла) обязательный атрибут файла.
А вот, репозиторий с нулевым количеством рабочих директории вполне возможен и у меня встречается сплошь и рядом, например временно приостановленные проекты или мастер репозитории на сервере.
Не понял. Это в git что ли?
Плохое решение, которое пришлось исправлять через лишние конструкции. Изначально симметричная ситуация (все рабочие директории равноправные), пришлось делать несимметричной – главная и дополнительные.