LINUX.ORG.RU
ФорумTalks

git is really stupid and made by stupid

 


0

3

gcc можно собирать вмести с binutils, newlib и прочими библиотеками и инструментарием GNU (например gdb) в так называемом combined tree, тоесть из сведённого в одно дерево исходников. Например если вы распаковали исходники gcc-7.2.0 и binutils-2.29.1 вы можете свести их в одно дерево (одну директорию) командами:

rsync -au gcc-7.2.0/ combined-gcc-7.2.0/
rsync -au binutils-2.29.1/ combined-gcc-7.2.0/

Это работает благодаря тому, что оба проекта используют единую базу инфраструктурного кода gcc и периодически синхронизируются между собой. Но если вы попытаетесь точно так же добавить ещё и код newlib-2.5.0.20170922 вы испортите combined-gcc-7.2.0 и в частности файл include/dwarf2.h

Почему это происходит? Потому что git не умеет сохранять даты модификаций файлов. В итоге git выставляет текущую дату и время в качестве даты модификации файла всякий раз, когда изменяет его содержимое после таких команд как git clone или git checkout.

В git репозитории проекта newlib файл include/dwarf2.h последний раз модифицировался аж в 2016-06-23, но в тарбале newlib-2.5.0.20170922 дата его модификации 2017-09-19:

https://sourceware.org/git/?p=newlib-cygwin.git;a=history;f=include/dwarf2.h
ftp://sourceware.org/pub/newlib/newlib-2.5.0.20170922.tar.gz

В git репозитории проекта binutils, после 2016-06-23 и до создания тага релиза binutils-2_29_1.1, этот же файл модифицировался три раза, последний раз 2017-07-02. Одно из изменений, отсутствующее в newlib-2.5.0.20170922 - добавление внешней функции get_DW_IDX_name

https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=include/dwarf2.h;h...

Но поскольку дата модификации include/dwarf2.h в тарбале newlib-2.5.0.20170922 неверная и якобы новее, rsync оставляет именно её вместо действительно более новой версии из binutils.

Проблема не новая, с Линусом уже перетёртая и я далеко не первый, кто назвал его решение глупым. Кстати, в Mercurial такой проблемы нет. В старых системах управления версиями (CVS, SVN) её тоже не было. Линус решил, что он самый умный и вот результат. Ну чем не Поттеринг?

★★★★★

Ответ на: комментарий от bbk123

Костыль для твоей хероты:

$ git clone https://github.com/mirror/newlib-cygwin newlib-2.5.0.20170922
$ cd newlib-2.5.0.20170922/
$ git checkout newlib-snapshot-20170922
$ rev=HEAD; for f in $(git ls-tree -r -t --full-name --name-only "$rev") ; do echo "$f" ; touch -d $(git log --pretty=format:%cI -1 "$rev" -- "$f") "$f"; done;
$ rm -Rf .git*
$ cd ..
$ tar -czf newlib-2.5.0.20170922.tar.gz newlib-2.5.0.20170922/

Не знаю, как это сделать быстрее, не знаток UNIX-утилит и Shell-оболочек. Может спецы оптимизируют. Если лень ждать, вот тебе готовый tarball, который ты можешь попробовать заюзать с combined tree в этом GCC. Даты в нём выправлены «по Git'у».

http://esxi.z-lab.me:666/~exl_lab/software/newlib-2.5.0.20170922.tar.gz

По-хорошему, надо сделать баг-репорт команде разработчиков Newlib в RedHat, раз тебе интересна такая возможность сборки.

Git умеет менять даты файлов в генерируемых tarball'ах по DateTime создания тега. Проблема в самой Newlib и в её откровенно странном подходе к версионированию.

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

EXL ★★★★★ ()
Ответ на: комментарий от question4

Как можно следить за изменениями, не используя ни время правки, ни хеши? Сделать собственные копии? Это ещё дольше хешей. Держать запущенным демона, который отслеживает все операции записи?

Да. Можно через системные API, можно вообще притвориться ФС (какой-то из инструментов ClearCase так делал, tup из свободных).

tailgunner ★★★★★ ()
Ответ на: комментарий от EXL

Из документации git archive

git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.


И действительно, если сделать

$ git archive --prefix=newlib-2.5.0/ -o newlib-2.5.0-20170922.tar.gz newlib-snapshot-20170922
$ tar -tvzf newlib-2.5.0-20170922.tar.gz | grep include/dwarf2.h
-rw-rw-r-- root/root     12666 2017-09-19 23:36 newlib-2.5.0/include/dwarf2.h

Та самая неверная дата 2017-09-19 действительно взятая из времени создания тага newlib-snapshot-20170922
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=f9b24fad...

Какой смысл выставлять дату модификации всех файлов на дату создания тага совершенно непонятно.

Видимо разработчики RedHat каким-то особенным образом делали эти TarBall'ы.

Нет, судя по всему они их делали так же.

bbk123 ★★★★★ ()
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от bbk123

Какой смысл выставлять дату модификации всех файлов на дату создания тага совершенно непонятно.

Да нет же, я вижу в этом определённую логику: библиотека релизнулась под датой «20170922», пусть тогда и все её файлы имеют дату 20170922. Это вполне себе объяснимый подход.

EXL ★★★★★ ()
Ответ на: комментарий от EXL

У Gradle есть watch-плагин, который может мониторить изменившиеся файлы и демон, который сильно сокращает время сборки.

https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:how_does_the...

По ссылке слово «watch» отсутствует, а текст о том, как сильно возрастает эффективность программы на джаве, если её после выполнения работы не убивать, а держать в памяти на случай повторного использования.

Как определяет, что файл надо перекомпилировать, не нашёл.

question4 ★★★★★ ()
Ответ на: комментарий от tailgunner

Да. Можно через системные API, можно вообще притвориться ФС (какой-то из инструментов ClearCase так делал, tup из свободных).

А между запусками демона они что делают? Или считают, что у всех пользователей демон запущен постоянно?

question4 ★★★★★ ()
Ответ на: комментарий от EXL

Спасибо конечно, но ты опоздал. Выше я уже написал аналогичный костыль.

По-хорошему, надо сделать баг-репорт команде разработчиков Newlib в RedHat, раз тебе интересна такая возможность сборки.

Да. Правда я не до конца уверен, что и этот костыль всегда работает правильно. Ведь если они синхронизируют изменения общего кода вручную, есть небольшая дельта по времени, когда изменение из gcc взято, но ещё не закомичено в newlib, а за это время в gcc или в binutils или в другом gdb этот же файл опять изменился. В итоге даже если смотреть на дату синхронизирующего коммита получим слегка старую ревизию файла как новее самой новой. Вероятность этого конечно низкая, но всё равно она есть. Хотя для релизов и даже снепшотов наверное будет работать правильно и так.

Блин, сколько приключений из-за одного лишь упёртого Бенедикта, который, мать его, не хочет сохранять mtime файлов, даже несмотря на то, что это делают другие VCS, включая дистрибутивные.

Git умеет менять даты файлов в генерируемых tarball'ах по DateTime создания тега.

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

Проблема в самой Newlib и в её откровенно странном подходе к версионированию.

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

Вполне возможно, что в git archive со временем добавят флажок, который будет запекать последние даты файлов.

Тоесть всунут кривой костыль, аналогичный нашим скриптам, вместо того, чтобы решить проблему изначально неправильной архитектуры git.

bbk123 ★★★★★ ()
Ответ на: комментарий от tailgunner

можно вообще притвориться ФС, какой-то из инструментов ClearCase так делал

Это сам ClearCase делал. По моему кроме ClearCase так больше никто не умеет.

bbk123 ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

я как раз занимаюсь тем

Это шиза типа тулкитофобии только ещё хуже.

pawnhearts ★★★★★ ()
Ответ на: комментарий от EXL

Да нет же, я вижу в этом определённую логику: библиотека релизнулась под датой «20170922», пусть тогда и все её файлы имеют дату 20170922. Это вполне себе объяснимый подход.

Что значит пусть? Это что DOS 6.22, что все её файлы имеют время модификации 6:22? Это ведь не для красоты нужно. Для красоты пусть лучше gitk перепишут во что-то человеческое.

bbk123 ★★★★★ ()
Ответ на: комментарий от question4

А между запусками демона они что делают? Или считают, что у всех пользователей демон запущен постоянно?

Про «всех пользователей» не понял. Как работает конкретно tup, просто не знаю. В Mercurial был плагин, ускорявший hg diff на больших репозиториях (за счет того, что отслеживал изменения) - он запускал демона при первом вызове.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Про «всех пользователей» не понял.

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

question4 ★★★★★ ()
Ответ на: комментарий от question4

Как определяет, что файл надо перекомпилировать, не нашёл.

Там скорее всего по хешу, далеко не залезал, на touch <file> Gradle внимание не обращает, а ссылка это как пример демона в системе сборки.

Watch плагин тут: https://plugins.gradle.org/plugin/com.bluepapa32.watch на изменения состояния файлов/дерева можно вешать всякие обработчики.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от question4

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

При использовании *notify? Нет.

Если это только один из методов, тогда всё нормально.

*notify - метод ускорения обычной работы: через хеши или даты модификации.

tailgunner ★★★★★ ()
Ответ на: комментарий от bbk123

Выше я уже написал аналогичный костыль.

А да, сорри, не заметил.

Блин, сколько приключений из-за одного лишь упёртого Бенедикта, который, мать его, не хочет сохранять mtime файлов, даже несмотря на то, что это делают другие VCS, включая дистрибутивные.

И столько же приключений из-за combined tree.

Кстати, а разве сам GCC не перешёл на GIT? Как он там строит tarball'ы сквозь него?

P.S. Как я понял, GCC ещё не перешёл, но они уже два года собираются:
https://gcc.gnu.org/ml/gcc/2015-08/msg00140.html
https://news.ycombinator.com/item?id=10097221
https://www.reddit.com/r/linux/comments/3hurzd/gcc_discusses_moving_to_git/

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

О каких страданиях всех остальных ты говоришь?

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

Тоесть всунут кривой костыль, аналогичный нашим скриптам, вместо того, чтобы решить проблему изначально неправильной архитектуры git.

Да нет, это у нас кривые и медленные костыли, потому что парсинг текстового лога и вызов внешних утилит. А там могут сделать намного быстрее это всё.

В любом случае, эта не та проблема в Git, которую кто-то и когда-то будет решать.

Отправь фич-реквест в сам Git, если тебе это так нужно.

EXL ★★★★★ ()
Ответ на: комментарий от bbk123

Кривая дата, например, из-за которой make точно так-же сломается.

P.S. Насколько я вижу, в hg эта фича идет third-party плугином.

P.P.S. И авторы HG против такой фичи: https://www.mercurial-scm.org/pipermail/mercurial/2015-August/048617.html

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от bbk123

Это ведь не для красоты нужно.

Для чего ещё, кроме Combined Tree это нужно?

EXL ★★★★★ ()
Ответ на: комментарий от EXL

Проще просто перейти на Mercurial. Проблема в том, что проекты вроде gcc, binutils, newlib и т.п. не перейдут. Причём вовсе не по техническим причинам, а лишь потому, что git моднее, а Бенедикт известнее.

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

А еще потому, что Mercurial их тоже не сохраняет. Откуда ты это вообще взял?

kirk_johnson ★☆ ()
Ответ на: комментарий от bbk123

Ха. Так в мире IT всегда выигрывает достаточно ущербненькое решение, когда нормальному отведено место вечного забвения.

Иначе популярность того же CMake и не объяснишь.

Ну и у Mercurial тоже есть недостаток: его ещё не переписали на Python 3.

EXL ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Хм, и правда.

hg clone — даты потеряны
hg archive — даты потеряны
hg checkout — даты потеряны

bbk123, ну что? Остаёмся на SVN?

EXL ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Из обсуждений этой проблемы в git на stackoverflow. Может быть они ввели меня в заблуждение, но эта проблема постоянно поднимается большим количеством людей. И для Mercurial таки есть расширения, добавляющие эту функциональность.

bbk123 ★★★★★ ()
Ответ на: комментарий от baka-kun

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

system-root ★★★★ ()
Ответ на: комментарий от bbk123

И для Mercurial таки есть расширения, добавляющие эту функциональность.

То есть, ни одна DVCS mtime не сохраняет (без сторонних плагинов). Теперь, попробуй понять почему.

kirk_johnson ★☆ ()
Ответ на: комментарий от Iron_Bug

«официально поддерживаемый» - это ещё не означает «реально работающий»

В квотезы

shatsky ★★ ()
Ответ на: комментарий от kirk_johnson

Ты мне расскажи почему, если такой умный.

bbk123 ★★★★★ ()
Ответ на: комментарий от a1batross

то у sh ровно та же самая проблема: каждый пишет его как хочет

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

и я пока не видела ни одной системы, где бы sh вызывал проблемы с make или автотулзами. бывает, что внешние утилиты типа grep или awk по-разному реализованы, а разработчик их запихнул в скрипты. но это не проблема шелла.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от system-root

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

Ты мне расскажи почему, если такой умный.

Потому что DVCS подразумевает нелинейную работу с коммитами.

kirk_johnson ★☆ ()
Ответ на: комментарий от bbk123

Всё сложно...

Как минимум: не понятно откуда именно нужно брать дату последней модификации файла. Во-первых, тот же гит сохраняет две даты: author date (когда автор создал коммит на своей машине) и commit date (когда коммит последний раз изменялся, сюда входят рибейзы, применения на другие ветки, git am и так далее). Во-вторых, нет никакой гарантии, что в ветке даты будут идти по порядку. В реальной жизни в более-менее сложных проектах и проектах с более чем одним разработчиком они будут перемешаны.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от question4

А почему Дженту вынуждено поддерживать 12 несовместимых версий автотулзхов?

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

Iron_Bug ★★★★ ()
Ответ на: комментарий от pawnhearts

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

Iron_Bug ★★★★ ()
Ответ на: комментарий от kirk_johnson

Потому что DVCS подразумевает нелинейную работу с коммитами.

DVCS подразумевает лишь отсутствие единого репозитория. Причём же тут mtime?

bbk123 ★★★★★ ()
Ответ на: комментарий от shatsky

ну дык! чай, не америку открыла. опыт разработки и сборки всякой всячины - это не теорию читать в книжечках. по факту, любую сборку надо максимально изолировать, чтобы не притянуть каких-то случайных линков и случайно не зохавать левые хэдеры. а идея сваливать код разных библиотек в один каталог - это дичь, даже если она «поддерживается».

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Ты собираешь под эмбеддед на самой железке? Держишь там все средства разработки, исходники?

pawnhearts ★★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

Iron_Bug ★★★★ ()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

Я видел твои резюме. Если это действительно высокие зарплаты в екб, это печально.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

ещё раз, для тех, кто в танке: моё резюме не менялось уже лет семь. да, мне лень. потому что я не ищу работу постоянно. а зарплата с тех пор выросла в разы. мне нет смысла писать требования в 200 тыщ. я просто договариваюсь об уровне конкретно с работодателем и не обсуждаю это публично. вообще, зарплата - это nda, причём по нашему же ТК. так что вопросы неуместны.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

С опытом работы в 20 лет? Это очень, очень грустно.

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

я ещё раз говорю: пистон - полное дерьмо. и это никак не зависит от моей зарплаты.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Как минимум, это очень медленно. И нет места под интерпретатор, который весит 30mb со всей стандартной библиотекой и прочем.

А вообще детский сад. Такой максимализм.

pawnhearts ★★★★★ ()
Последнее исправление: pawnhearts (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Главное, не нервничай. Твое мнение относительно пистона никак не отменяет того факта, что все крупные проекты его в той или иной мере используют (даже линуксовое ядро).

kirk_johnson ★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.