The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск системы управления исходными текстами Git 2.36

19.04.2022 09:06

После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.36. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.

По сравнению с прошлым выпуском в новую версию принято 717 изменений, подготовленные при участии 96 разработчиками, из которых 26 впервые приняли участие в разработке. Основные новшества:

  • В команды "git log" и "git show" добавлена опция "--remerge-diff", позволяющая показать отличия между общим результатом слияния и фактическими данными, отражёнными в коммите после обработки команды "merge", что позволяет наглядно оценить изменения, выполненные в результате разрешения конфликтов при слиянии. Обычная команда "git show" разделяет разные разрешения конфликтов отступом, что затрудняет понимание изменений. Например, на скриншоте ниже строки "+/-" без отступа показывает последнее разрешение конфликта, связанное с переименованием в первой ветке sha1 на oid в комментарии, а "+/-" с отступом - начальное разрешение конфликта, вызванное появлением во второй ветке дополнительного аргумента в функции dwim_ref().

    При использовании опции "--remerge-diff" различия между разрешениями конфликтов не разделяются для каждой родительской ветки, а показываются общие различия между файлом, имеющим конфликты слияния, и файлом, в котором конфликты решены.

  • Повышена гибкость настройки поведения по сбросу дисковых кэшей через вызов функции fsync(). Ранее доступный параметр core.fsyncObjectFiles разделён на две переменных конфигурации core.fsync и core.fsyncMethod, предоставляющих возможность применять fsync, не только к файлам с объектами (.git/objects), но и к другим структурам git, таким как ссылки (.git/refs), reflog и pack-файлы.

    Через переменную core.fsync можно указать список внутренних структур Git, после операции записи для которых дополнительно будет вызываться fsync. Переменная core.fsyncMethod позволяет выбрать метод для сброса кэша, например, можно выбрать fsync для применения одноимённого системного вызова или указать writeout-only для применения отложенной записи (pagecache writeback).

  • Для защиты от уязвимостей, манипулирующих подстановкой другими пользователями каталогов .git в совместно используемые разделы, усилена проверка владельца репозитория. Выполнение любых команд git теперь допускается только в своих каталогах ".git". Если каталог с репозиторием принадлежит другому пользователю, то по умолчанию будет выведена ошибка. Указанное поведение можно отключить при помощи настройки safe.directory.
  • В команду "git cat-file", предназначенную для вывода исходного содержимого Git-объектов, добавлена опция "--batch-command", дополняющая ранее доступные команды "--batch" и "--batch-check" возможностью адаптивного выбора типа вывода через указание "contents <объект>" для вывода содержимого или "info <объект>" для вывода информация об объекте. Дополнительно поддерживается команда "flush" для сброса буфера вывода.
  • В команду "git ls-tree", предназначенную для формирования списка содержимого дерева объектов, добавлена опция "--oid-only" ("--object-only"), по аналогии с "--name-only" выводящая только идентификаторы объектов для упрощения вызова из скриптов. Также реализована опция "--format" позволяющая определить собственный формат вывода, комбинируя информацию о режиме, типе, имени и размере.
  • В команде "git bisect run" реализовано определение невыставления для скрипта признака исполняемого файла и вывода в этом случае ошибок с кодами 126 или 127 (ранее, если скрипт невозможно было запустить, все ревизии помечались как имеющие проблемы).
  • В команду "git fetch" добавлена опция "--refetch" для извлечения всех объектов без информирования другой стороны о содержимом, уже имеющемся на локальной системе. Подобное поведение может быть полезным для восстановления состояния после сбоев, когда нет уверенности в целостности локальных данных.
  • В команды "git update-index", "git checkout-index", "git read-tree" и "git clean" добавлена поддержка частичных индексов (sparse index), позволяющих повысить производительность и сэкономить место в репозиториях, в которых выполняются операции частичного клонирования (sparse-checkout).
  • Изменено поведение команды "git clone --filter=... --recurse-submodules", которая теперь приводит к частичному клонированию субмодулей (ранее при выполнении подобных команд фильтр применялся только к основному содержимому, а субмодули клонировались полностью без учёта фильтра).
  • В команде "git bundle" добавлена поддержка указания фильтров для выборочного помещения содержимого по аналогии с операциями частичного клонирования.
  • В команду "git branch" добавлена опция "--recurse-submodules" для рекурсивного обхода субмодулей.
  • В userdiff предложен новый обработчик для языка Kotlin.


  1. Главная ссылка к новости (https://lore.kernel.org/all/xm...)
  2. OpenNews: Выпуск системы управления исходными текстами Git 2.35
  3. OpenNews: Две уязвимости в Git
  4. OpenNews: Атака на GitHub, приведшая к утечке приватных репозиториев и доступу к инфраструктуре NPM
  5. OpenNews: Выпуск системы управления исходными текстами Git 2.33
  6. OpenNews: Отчёт о компрометации git-репозитория и базы пользователей проекта PHP
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/57040-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (83) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:32, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.

    всегда было забавно на это смотреть - давайте создадим себе сложность и будем героически ее решать

     
     
  • 2.2, Аноним (2), 11:40, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но что здесь плохо?
     
     
  • 3.3, Аноним (3), 11:44, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    неявное хеширование ВСЕЙ предыдущей истории в КАЖДОМ коммите
     
     
  • 4.10, Аноним (10), 12:35, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >неявное хеширование ВСЕЙ предыдущей истории в КАЖДОМ коммите

    и как тут это укладывается - "неявное" и "всей"?

     
  • 4.11, fi (ok), 12:36, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так работает  любой блокчейн, тот же BTC
     
  • 4.31, Аноним (31), 13:51, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И это правильно.
     
  • 4.39, Z (??), 14:34, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теперь переведи на русский.
     
  • 4.57, Michael Shigorin (ok), 19:19, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И что здесь плохо?
     
  • 4.82, Анонимомус (?), 13:41, 20/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В каждом коммите указан хеш его родителя(или родителей для мерджа), кроме того там есть хеш дерева файлов, в котором хеши конкретных файлов. В общем в коммите нет явного списка всей истории, она берется по цепочке.
     
  • 3.4, Аноним (1), 11:47, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Keep it simple, stupid. не нужно было разрешать переписывать историю вовсе.
     
     
  • 4.5, А где же каменты (?), 12:08, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как это сделать без хеширования ? Интрудер просто вручную изменит Хистори и разрешения спрашивать не будет.
     
     
  • 5.14, Аноним (1), 12:39, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Как это сделать без хеширования ?

    это все детали реализации, понятно что нужен отпечаток в любом случае. но хэш всей истории по идее кажется не очень обязательным.
    >Интрудер просто вручную изменит Хистори и разрешения спрашивать не будет.

    в этом собсна и поинт - не должно быть простого способа(апи) это сделать

     
     
  • 6.18, Аноним (18), 12:50, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > это все детали реализации

    Анекдот про сову и мышей.

    > не должно быть простого способа(апи) это сделать

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

     
     
  • 7.25, Аноним (1), 13:25, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Почему не должно? Кто это сказал? Почему ты выносишь решение сразу для всех компаний и всех разработчиков, как им работать Правильно™?

    окей, возможно слишком резковато выразился. почитай ниже про плюсы и минусы.

     
  • 6.58, Michael Shigorin (ok), 19:20, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в этом собсна и поинт - не должно быть простого способа(апи) это сделать

    Вы серьёзно думаете, что грабителя остановит неудобство калитки?

    ...поколение подменяющих принципы "удобными API"...

     
  • 4.7, Аноним (18), 12:24, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > не нужно было разрешать переписывать историю вовсе

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

    > Keep it simple, stupid

    Если нужно еще проще, то для тебя есть "Новая папка (281)".

     
     
  • 5.9, Аноним (1), 12:33, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Запретить переписывать историю можно на уровне репозиториев (в гитлабе, -хабе и т. д.).

    это называется костыли. из-за их накопления потом ui и страдает кстати

    >Если нужно еще проще, то для тебя есть "Новая папка (281)".

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

     
     
  • 6.12, Аноним (18), 12:39, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > называется костыли

    почему костыли? то, можно ли перезаписывать историю -- явно относится к политике компании. Где-то можно, где-то нельзя. Почему VCS должен это как-то ограничивать -- не ясно.

    > если оочень зачем-то надо - такую фичу сделали

    ну раз тоже сделали -- то тоже молодцы. Пусть возьмут с полки пирожок.

     
     
  • 7.17, Аноним (1), 12:49, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >явно относится к политике компании. Где-то можно, где-то нельзя.

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

     
     
  • 8.22, Аноним (18), 13:10, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    в репе могут оказаться конфиденциальные данные или просто какой-то лишний крупны... текст свёрнут, показать
     
     
  • 9.24, Аноним (1), 13:22, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это хороший аргумент имхо в таком случае лучше явно репу удалить и переехать на... текст свёрнут, показать
     
     
  • 10.27, Аноним (18), 13:28, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чем это отличается от перезаписи истории Тоже принципиально новый набор коммито... текст свёрнут, показать
     
  • 9.32, Аноним (31), 13:54, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Значит, они уже утекли, а в случае секретов ещё и скомпрометированы ... текст свёрнут, показать
     
  • 6.59, Michael Shigorin (ok), 19:23, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > он не менее распределеннее

    Вы неграмотны, увы.

    Нет, дело не только в правописании.  А в полном непонимании того, _почему_ в распределённой системе линейно нумеруемые ревизии не годятся -- даже не затрагивая адресацию по содержимому и далее со всеми остановками.

    Пожалуйста, не лезьте в эти темы что-нить ляпнуть.

    Почитайте лучше матчасть.

    Сослужите себе как, надеюсь, в будущем специалисту хорошую службу.

     
  • 4.34, freehck (ok), 14:01, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не нужно было разрешать переписывать историю вовсе.

    Тут какое-то жёсткое недопонимание работы git. Вот чтобы не было возможности переписывать историю и нужно:

    >  неявное хеширование всей предыдущей истории в каждом коммите

    Где тут усмотрели героическое решение самосозданных проблем -- не понятно.

     
     
  • 5.41, Аноним (41), 15:02, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Разрешили менять историю(создали проблему) -> добавили проверку целостности (решили проблему). Про то что хеширование какое-то неявное хз, комент другого анонима
     
     
  • 6.42, freehck (ok), 15:04, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Разрешили менять историю

    Когда это вдруг разрешили менять историю?

     
     
  • 7.47, Аноним (1), 15:36, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://initialcommit.com/blog/4-git-commands-rewrite-commit-history
    когда впилили эти команды(и форс-пуш)
     
     
  • 8.49, freehck (ok), 15:54, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дорогой анон, когда мы говорим про изменение истории, мы прежде всего говорим о ... текст свёрнут, показать
     
     
  • 9.60, Michael Shigorin (ok), 19:25, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Он некомпетентен, но активен PS кому интересно понять немножко за гит , но н... текст свёрнут, показать
     
  • 4.51, Аноним (51), 17:05, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Опеннетчика хлебом не корми, дай позапрещать что-нибудь. Тебе как-то персонально жмёт в заду от того, что есть такая фича? Ты же понимаешь, что «запретить переписывать историю» невозможно в принципе. Да, можно усложнить этот процесс, но, как ты сам сказал, keep it simple. Это относится не только к созданию простых (но не проще, чем это необходимо!) решений, но и к созданию простых интерфейсов человек-компьютер. Что и реализовано в гите в данном случае — простой интерфейс к довольно сложной операции.
     
     
  • 5.61, Michael Shigorin (ok), 19:26, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Опеннетчика хлебом не корми, дай позапрещать что-нибудь.

    При чём здесь опеннетчики?  Cancel-культурка растёт самое позднее от иудейской верхушки времён 33 года н.э., решившей "отменить" воскресение Лазаря.

     
     
  • 6.72, YetAnotherOnanym (ok), 21:48, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, имя безумца Герострата и вправду забыли, а уж он-то пораньше Лазаря жил.
    Сработала cancel-культурка!
     
     
  • 7.87, Аноним (-), 01:25, 22/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    До "их" эры времени не было - громче всех держи cancel culture орет ее носитель...
     
  • 6.83, Аноним (10), 13:56, 20/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вы против иудеев?
     
  • 2.20, Аноним (20), 13:01, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если ты не решаешь ни каких проблем как объяснишь, то что тебе надо выделять финансирование?
     

  • 1.6, А где же каменты (?), 12:13, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Название нравится - взлетит.
     
     
  • 2.21, Аноним (20), 13:03, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гит свежо, хипстово.
     
     
  • 3.88, Аноним (-), 01:27, 22/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Торвальдс так то нормальный хипстер, годный.
     

  • 1.8, Аноним (10), 12:33, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На втором изображении:
    >index 75a248188a..7074bbdd53 10644

    разве правильно, что стоит значение "10644"?

     
     
  • 2.77, Аноним (77), 01:11, 20/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > разве правильно, что стоит значение "10644"?

    А что не так с 10644? Казалось бы, обычные права на обычный файл.

     

  • 1.13, ANANAS (ok), 12:39, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как там mercurial? Будут ли переписывать с питона?
     
     
  • 2.28, Аноним (1), 13:28, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/facebookexperimental/eden
    Какая-то движуха есть. Надо будет потыкать
     
  • 2.48, Аноним (48), 15:50, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    будут. на перл.
     
  • 2.89, Аноним (-), 01:28, 22/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос поставлен неверно. Будут ли помещать в инкубатор апача?
     

  • 1.16, Аноним (16), 12:46, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Слыхал где-то про какую-то darks, что тип круче Гита и тру хаскел пацаны только дарксом пользуются. Кто-нибудь слышал о ней что-нибудь, может прокомментировать?
     
     
  • 2.19, Аноним (1), 12:56, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ща Pijul на ржавом более хайповый
     
     
  • 3.23, Аноним (18), 13:13, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Pijul

    Как это произносится? Пижуль? Пихуль?

     
     
  • 4.26, Аноним (16), 13:27, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На Лоре пишут, что через х. Автор мексиканец вроде
     
  • 4.33, Вадим (??), 14:00, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    я бы сказал пи-юль :)
     
  • 3.29, Аноним (16), 13:30, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так важно не хайп, а трушность. Хаскел, скажем, не хайповый, но никто не станет спорить с тем, что Хаскел - тру
     
     
  • 4.35, freehck (ok), 14:05, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хаскел, скажем, не хайповый, но никто не станет спорить с тем, что Хаскел - тру

    Конечно никто не станет спорить, что он не "тру", пока ты это самое "тру" не определишь нормально.

    А так-то по минусам хаскеля можно сказать довольно много всего.

     
     
  • 5.63, Michael Shigorin (ok), 19:29, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нормально чему, кстати? :)

    (отвечать необязательно, 1.25.23 интересней, ага)

     
  • 4.38, Z (??), 14:33, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Хаскел - тру

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

     
     
  • 5.44, Аноним (44), 15:11, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Хоть один известный проект покажи. По моему это чисто маргинально-эксперементальный язык.

    Pandoc?


     
  • 5.52, Аноним (51), 17:06, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Shellcheck. Если ты пишешь портянки на шелле без шелчека, твой код ужасен. Инфа сотка.
     
  • 5.53, Аноним (53), 17:31, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Хоть один известный проект покажи.

    Xmonad. GHC

     
  • 2.62, Michael Shigorin (ok), 19:28, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У darcs есть интересная (и, кажется, уникальная) фича -- переносить "смысл" изменений, т.е. вместо приложения буквального diff'а выводить разницу вида "переменную ABC везде заменили на DEF".

    А так только хаскелятники знакомые ею и пользовались, да.

     
     
  • 3.76, DM (??), 23:57, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Был период где-то между появлениями GNU arch (tla) и GIT, когда не только хаскелятники использовали
    darcs.
     

  • 1.30, Аноним (30), 13:31, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что там с Conditional config includes based on remote URL ? Когда уже
     
     
  • 2.64, Michael Shigorin (ok), 19:30, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что, сами дырок навертеть не в состоянии?
     

  • 1.36, Андрей (??), 14:15, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Подобное поведение может быть полезным для восстановления состояния после сбоев, когда нет уверенности в целостности локальных данных.

    А что, git fsck не умеет однозначно сказать, целые данные или нет, и какие именно? Так чтобы если уж и пользоваться refetch, то тянуть только побитые.

     
  • 1.37, Z (??), 14:31, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Git не нужен. Он только усложняет процесс. Там официальное руководство  тянет на докторскую диссертацию и уместить в голове все эти команды просто нереально.
     
     
  • 2.43, ыы (?), 15:07, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это дает повод к появлению узких специалистов- тех кто знает например только git clone
    или только git push.

    И там где раньше был один чувачек на девопсе- теперь будет два профессионала...

    Хорошо же! Новые рабочие места, Инновации... :)

     
     
  • 3.45, ыы (?), 15:14, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Обучение опять же, сертификация... Многоуровневая сертификации.. Дипломированый "Git Cloner", Магистр "Git Pushing"...
     
     
  • 4.46, ыы (?), 15:15, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ухххх какие перспективы открываются...!!! :)
     
  • 2.54, Аноним (16), 17:37, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Какую DVCS посоветуете?
     
     
  • 3.55, Аноним (55), 18:10, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    mercurial
     
  • 3.67, Z (??), 20:07, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Какую DVCS посоветуете?

    newFolder -> oldNewFolder и т.д. для не_коммандной разработки бОльшее не_нужно, голова светлее будет, времени больше на девок (голосистых) 😏

     
     
  • 4.79, Аноним (16), 03:04, 20/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уже не хватает, даже при некомандной разработке. Слишком много действий для создания новых папок, да ещё и как дифф получить - не понятно
     
     
  • 5.81, Аноним (55), 12:52, 20/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    diff -urN oldFolder newFolder
     
  • 3.70, OpenEcho (?), 21:26, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >  Какую DVCS посоветуете?

    fossil-scm от авторов sqlite - делает тоже самое что и git но еще в прикуску имеет на борту встроенную вики, тикеты и даже форум (правда страшный как ад, но починить с CSS можно).

    В принципе, весь sqlite на нем и делается

     
  • 2.56, llolik (ok), 18:52, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > уместить в голове все эти команды просто нереально.

    Их и не надо полностью умещать в голове, надо просто знать что оно где-то там есть. Достаточно помнить самые попсовые и часто используемые в своём конкретном рабочем процессе. Для всего остального есть man (ну или вот это руководство).

     
     
  • 3.73, Аноним (73), 21:58, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Или всегда можно загуглить дикий однострочник на баше(по типу закрытая всех неактивных веток или подобного)
     
     
  • 4.74, Z (??), 23:55, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Или всегда можно загуглить дикий однострочник на баше(по типу закрытая всех неактивных
    > веток или подобного)

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

     
  • 4.80, llolik (ok), 08:46, 20/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Или всегда можно загуглить дикий однострочник на баше(по типу закрытая всех неактивных
    > веток или подобного)

    Или вообще существует такая замечательная вещь, как alias-ы. Позволяет забить длинную команду один раз и больше о ней не вспоминать.

     
  • 2.65, Michael Shigorin (ok), 19:31, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > уместить в голове все эти команды просто нереально

    Пожалуйста, немедленно прекратите пользоваться интернетом, браузером, операционной системой, компьютером.  Ну или "логику" поправьте.

     

  • 1.40, zog (??), 14:50, 19/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Переход на SHA256 уже никогда не состоится?
     
     
  • 2.69, Сушилин (?), 20:14, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да уже в пору на SHA3 переходить, хайпово, модно,быстро.
     
  • 2.71, OpenEcho (?), 21:31, 19/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://git-scm.com/docs/hash-function-transition/

    https://lwn.net/Articles/811068/

     
     
  • 3.86, zog (??), 12:25, 21/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я это всё уже давно прочитал. Переход на SHA256 так и не состоялся и его поддержка недоделана.
     

  • 1.78, Аноним (78), 02:31, 20/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Раздули этот Git. Mercurial по кайфу, но Bitbucket ещё в 2020 по моему перестал поддерживать, а больше ничего и нет
     
  • 1.84, Анонимомус (?), 13:58, 20/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чет незаметно подвижек в выпиливании perl и shell скриптов, давно уже пора выделить все в библиотеку или допилить libgit2.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру